Flag categorize labels on streams response #10419

salvacorts · 2023-09-01T09:57:12Z

We recently introduced support for ingesting and querying structured metadata in Loki. This adds a new dimension to Loki's labels since now we arguably have three categories of labels: stream, structured metadata, and parsed labels.

Depending on the origin of the labels, they should be used in LogQL expressions differently to achieve optimal performance. stream labels should be added to stream matchers, structured metadata labels should be used in a filter expression before any parsing expression, and parsed labels should be placed after the parser expression extracting them.

The Grafana UI has a hard time dealing with this same problem. Before grafana/grafana#73955, the filtering functionality in Grafana was broken since it was not able to distinguish between stream and structured metadata labels. Also, as soon as a parser expression was added to the query, filters added by Grafana would be appended to the end of the query regardless of the label category. The PR above implements a workaround for this problem but needs a better API on Loki's end to mitigate all corner cases.

Loki currently returns the following JSON for log queries:

...
{
	"stream": {
	  "cluster": "us-central",
	  "container": "query-frontend",
	  "namespace": "loki",
	  "level": "info",
	  "traceID": "68810cf0c94bfcca"
	},
	 "values": [
                    [
                        "1693996529000222496",
                        "1693996529000222496 aaaaaaaaa.....\n"
                    ],
          ...
},
{
	"stream": {
	  "cluster": "us-central",
	  "container": "query-frontend",
	  "namespace": "loki",
	  "level": "debug",
	  "traceID": "a7116cj54c4bjz8s"
	},
	 "values": [
                    [
                        "1693996529000222497",
                        "1693996529000222497 bbbbbbbbb.....\n"
                    ],
          ...
},
...

As can be seen, there is no way we can distinguish the category of each label.

This PR introduces a new flag X-Loki-Response-Encoding-Flags: categorize-labels that makes Loki return categorized labels as follows:

...
{
        "stream": {
	  "cluster": "us-central",
	  "container": "query-frontend",
	  "namespace": "loki",
	},
	"values": [
                    [
                        "1693996529000222496",
                        "1693996529000222496 aaaaaaaaa.....\n",
                       {
                           "structuredMetadata": {
                                "traceID": "68810cf0c94bfcca"
                           },
                          "parsed": {
                                 "level": "info"
                          }
                       }
                    ],
                    [
                        "1693996529000222497",
                        "1693996529000222497 bbbbbbbbb.....\n",
                       {
                           "structuredMetadata": {
                                "traceID": "a7116cj54c4bjz8s"
                           },
                          "parsed": {
                                 "level": "debug"
                          }
                       }
                    ],
    ...
},
...

Note that this PR only supports log queries, not metric queries. From a UX perspective, being able to categorize labels in metric queries doesn't have any benefit yet. Having said that, supporting this for metric queries would require some minor refactoring on top of what has been implemented here. If we decide to do that, I think we should do it on a separate PR to avoid making this PR even larger.

I also decided to leave out support for Tail queries to avoid making this PR even larger. Once this one gets merged, we can work to support tailing.

Note to reviewers

This PR is huge since we need to forward categorized all over the codebase (from parsing logs all the way to marshaling), fortunately, many of the changes come from updating tests and refactoring iterators.

Tested out in a dev cell with query '{stream="stdout"} | label_format new="text".

Without the new flag:

$ http http://127.0.0.1:3100/loki/api/v1/query_range\?direction\=BACKWARD\&end\=1693996529322486000\&limit\=30\&query\=%7Bstream%3D%22stdout%22%7D+%7C+label_format+new%3D%22text%22\&start\=1693992929322486000 X-Scope-Orgid:REDACTED
{
    "data": {
        "result": [
            {
                "stream": {
                    "new": "text",
                    "pod": "loki-canary-986bd6f4b-xqmb7",
                    "stream": "stdout"
                },
                "values": [
                    [
                        "1693996529000222496",
                        "1693996529000222496 pppppppppppp...\n"
                    ],
                    [
                        "1693996528499160852",
                        "1693996528499160852 pppppppppppp...\n"
                    ],
...

With the new flag

$ http http://127.0.0.1:3100/loki/api/v1/query_range\?direction\=BACKWARD\&end\=1693996529322486000\&limit\=30\&query\=%7Bstream%3D%22stdout%22%7D+%7C+label_format+new%3D%22text%22\&start\=1693992929322486000 X-Scope-Orgid:REDACTED X-Loki-Response-Encoding-Flags:categorize-labels
{
    "data": {
        "encodingFlags": [
            "categorize-labels"
        ],
        "result": [
            {
                "stream": {
                    "pod": "loki-canary-986bd6f4b-xqmb7",
                    "stream": "stdout"
                },
                "values": [
                    [
                        "1693996529000222496",
                        "1693996529000222496 pppppppppppp...\n",
                        {
                            "parsed": {
                                "new": "text"
                            }
                        }
                    ],
                    [
                        "1693996528499160852",
                        "1693996528499160852 pppppppppppp...\n",
                        {
                            "parsed": {
                                "new": "text"
                            }
                        }
                    ],
...

vlad-diachenko

Looks brilliant 💎 . great job @salvacorts

vlad-diachenko · 2023-09-07T12:27:08Z

integration/loki_micro_services_test.go

@@ -710,6 +711,272 @@ func TestQueryTSDB_WithCachedPostings(t *testing.T) {

 }

+func TestCategorizedLabels(t *testing.T) {
+	clu := cluster.New(nil, cluster.SchemaWithTDSBAndNonIndexedLabels)


let's rename it to SchemaWithTDSBAndStructuredMetadata

owen-d

I like the idea, but I'd personally prefer something that's not a header to determine version (version parameter in query string|body, different api version prefix in path), but that's a nit.

I also think it makes more sense and will be more efficient for us to not treat each stream distinct based on (labels, structuredMetadata, parsed), but rather labels alone. It also feels more semantically correct as different log lines with separate structuredMetadata or parsed labels are still part of the same stream.

For instance:

{
  "stream": {
    "labels": {
      "cluster": "us-central",
      "namespace": "loki",
      "container": "query-frontend",
    },
    "structuredMetadata": {
        "traceID": "68810cf0c94bfcca"
    },
    "parsed": {
         "level": "info"
     }
  },
  "values": [...]
}

should become

{
  "stream": {
    "cluster": "us-central",
    "namespace": "loki",
    "container": "query-frontend",
  },
  "values": [
    {
      "ts": 0,
      "entry": "entry0",
      "structuredMetadata": {
        "traceID": "68810cf0c94bfcca"
      },
      "parsed": {
        "level": "info"
      }
    },
    ...
  ]
}

There are a few places in codecs, response merging (iirc) that will benefit from the reduced number of streams this will produces. Since it also feels more semantically correct, I think it's the way to go.

…in entry

sandeepsukhani · 2023-10-03T11:00:58Z

I also think it makes more sense and will be more efficient for us to not treat each stream distinct based on (labels, structuredMetadata, parsed), but rather labels alone. It also feels more semantically correct as different log lines with separate structuredMetadata or parsed labels are still part of the same stream.

Would it not mean a difference in behaviour between metric and log queries? I can't think of a way to do a similar categorization of labels in metric queries. I think stream should have all the labels merged together.

sandeepsukhani

nice work Salva! I have left some minor suggestions. I would like to do another review once those are taken care of.

sandeepsukhani · 2023-10-03T06:18:27Z

integration/cluster/schema.go

+	tsdbShipperSchemaWithStructuredMetadataConfigTemplate = `
+schema_config:
+  configs:
+    - from: {{.curPeriodStart}}
+      store: tsdb
+      object_store: filesystem
+      schema: v13
+      index:
+        prefix: index_
+        period: 24h
 `


we need not add this, you can just do:

clu := cluster.New(nil, cluster.SchemaWithTSDB, func(c *cluster.Cluster) { c.SetSchemaVer("v13") })

Done thank you!

sandeepsukhani · 2023-10-03T06:24:37Z

integration/loki_micro_services_test.go

+	now = time.Now()
+	require.NoError(t, cliDistributor.PushLogLineWithTimestamp("lineA", now.Add(-1*time.Second), map[string]string{"job": "fake"}))
+	require.NoError(t, cliDistributor.PushLogLineWithTimestampAndStructuredMetadata("lineB", now.Add(-2*time.Second), map[string]string{"traceID": "123", "user": "a"}, map[string]string{"job": "fake"}))
+	require.NoError(t, tIngester.Restart())


if you are restarting ingester to test your changes with data served from queriers, I think you need to disable WAL as well. You can do it by setting "-ingester.wal-enabled=false" flag on the ingesters.

Done thank you!

pkg/loghttp/entry.go

sandeepsukhani · 2023-10-03T10:33:49Z

pkg/logql/log/labels.go

+		return cached
+	}
+
+	return NewLabelsResult(b.buf.String(), hash, stream, structuredMetadata, parsed)


we are not filling back the cache here, is it intentional?

Good catch. Thank you!

sandeepsukhani · 2023-10-03T10:51:22Z

pkg/logql/log/labels_test.go

 	// cached.
-	assertLabelResult(t, expected, b.LabelsResult())
+	assertLabelResult(t, expected, actual)


doesn't look like it would test the cache

You are right, thank you.

sandeepsukhani · 2023-10-03T11:03:43Z

pkg/push/push.proto

+  repeated LabelPairAdapter parsed = 4 [
+    (gogoproto.nullable) = false,
+    (gogoproto.jsontag) = "parsed,omitempty"
+  ];


I would love to avoid doing this change since it adds an unexpected field to the push payload. I know it is hard but maybe leave a todo and let us try fixing it in a separate PR to avoid overcomplicating this one.

I would love to avoid doing this chang

Likewise! The problem is this is the object we move around everywhere an throughout our components so we need to send it around somewhere.

it adds an unexpected field to the push payload

I don't think that's a problem. Protobuf is extensible and backwards compatible when adding fields to the end of an object definition. So in this case, it's still backwards compatible.

I am not worried about backwards compatibility, my ony concern is having an unwanted field on the proto definitions on the write path. I understand it is hard to do it so maybe leave a todo for now.

sandeepsukhani · 2023-10-03T11:11:49Z

pkg/util/marshal/query.go

@@ -310,16 +346,30 @@ func encodeStream(stream logproto.Stream, s *jsoniter.Stream) error {
 		s.WriteRaw(`"`)
 		s.WriteMore()
 		s.WriteStringWithHTMLEscaped(e.Line)
-		if len(e.StructuredMetadata) > 0 {
+
+		if categorizeLabels && (len(e.StructuredMetadata) > 0 || len(e.Parsed) > 0) {


I think for consistency we should write empty object({}) instead of skipping it when we have not structured metadata and parsed labels.

Do you mean always serializing:

{ "structuredMetadata": {}, "parsed": {} }

If so, I think it's better not to do it. It will add a lot of overhead to the response.

Reviving this conversation due to @svennergr expecting {} to be returned here.

I'll create a follow-up PR to return a third item {} when there is no structured metadata nor parsed labels.

sandeepsukhani

the changes look great. Left just a minor comments and then we are good to merge it.

sandeepsukhani · 2023-10-20T11:13:54Z

pkg/loghttp/entry.go

 			if err := jsonparser.ObjectEach(value, func(key []byte, value []byte, dataType jsonparser.ValueType, _ int) error {
-				if dataType != jsonparser.String {
-					return jsonparser.MalformedStringError
+				if dataType == jsonparser.Object {


can you please leave a comment saying we parse both push request and query response json here to make it clear for others?

sandeepsukhani · 2023-10-20T11:26:13Z

pkg/logql/engine.go

+				builder := labels.NewBuilder(lbls)
+				for _, label := range entry.StructuredMetadata {
+					builder.Del(label.Name)
+				}
+				for _, label := range entry.Parsed {
+					builder.Del(label.Name)
+				}


Since this is on a hot path, it would be good to avoid doing this and try building the final response in the iterators. Maybe leave a todo and try doing it in a separate PR.

Added a todo

sandeepsukhani · 2023-10-20T11:28:06Z

pkg/push/push.proto

+  repeated LabelPairAdapter parsed = 4 [
+    (gogoproto.nullable) = false,
+    (gogoproto.jsontag) = "parsed,omitempty"
+  ];


I am not worried about backwards compatibility, my ony concern is having an unwanted field on the proto definitions on the write path. I understand it is hard to do it so maybe leave a todo for now.

sandeepsukhani · 2023-10-20T11:31:59Z

pkg/logql/log/labels.go

 	hash := b.hasher.Hash(buf)
 	if cached, ok := b.resultCache[hash]; ok {
 		return cached
 	}
-	res := NewLabelsResult(buf.Copy(), hash)
+
+	res := NewLabelsResult(buf.String(), hash, buf, nil, nil)


I think we should be doing a copy of the buf since it is reused?

Good catch, done

sandeepsukhani

LGTM

**What this PR does / why we need it**: This is a follow-up PR for #10419 adding support for tailing. I tested it on a dev cell and works fine. <img width="1296" alt="image" src="https://github.com/grafana/loki/assets/8354290/6177e0ca-02ce-48cd-a17f-0739dc3caa0a"> **Note**: With these changes, the JSON marshal unmarshal functions for the tail are no longer used ([example][1]) so I think we can remove them. Also, the new Tail response is no longer used, so we can also make it an alias to the _legacy_ one. Let's do it on a follow-up PR to avoid making this one bigger. [1]: https://github.com/grafana/loki/blob/52a3f16039dd5ff655fc3681257d99794f620ec4/pkg/loghttp/entry.go#L210-L238

…red metadata labels (#11325) This is a followup PR for #10419 wrt this comment #10419 (comment). If there is no parsed nor structured-metadata labels in a given entry, and the categorize-labels header is set, add an empty object to the entry array. For example, we currently return: ```json { "data": { "encodingFlags": [ "categorize-labels" ], "result": [ { "stream": { "agent": "promtail", "filename": "/var/log/nginx/json_access.log", "host": "appfelstrudel", "job": "nginx_access_log" }, "values": [ [ "1701096036028751750", "example line" ] ] } ] } } ``` But we want: ```json { "data": { "encodingFlags": [ "categorize-labels" ], "result": [ { "stream": { "agent": "promtail", "filename": "/var/log/nginx/json_access.log", "host": "appfelstrudel", "job": "nginx_access_log" }, "values": [ [ "1701096036028751750", "example line", {} <<<--- WE WANT THIS ] ] } ] } } ```

…red metadata labels (#11325) This is a followup PR for #10419 wrt this comment #10419 (comment). If there is no parsed nor structured-metadata labels in a given entry, and the categorize-labels header is set, add an empty object to the entry array. For example, we currently return: ```json { "data": { "encodingFlags": [ "categorize-labels" ], "result": [ { "stream": { "agent": "promtail", "filename": "/var/log/nginx/json_access.log", "host": "appfelstrudel", "job": "nginx_access_log" }, "values": [ [ "1701096036028751750", "example line" ] ] } ] } } ``` But we want: ```json { "data": { "encodingFlags": [ "categorize-labels" ], "result": [ { "stream": { "agent": "promtail", "filename": "/var/log/nginx/json_access.log", "host": "appfelstrudel", "job": "nginx_access_log" }, "values": [ [ "1701096036028751750", "example line", {} <<<--- WE WANT THIS ] ] } ] } } ``` (cherry picked from commit 10210b8)

…structured metadata labels (#11331) Backport 10210b8 from #11325 --- This is a followup PR for #10419 wrt this comment #10419 (comment). If there is no parsed nor structured-metadata labels in a given entry, and the categorize-labels header is set, add an empty object to the entry array. For example, we currently return: ```json { "data": { "encodingFlags": [ "categorize-labels" ], "result": [ { "stream": { "agent": "promtail", "filename": "/var/log/nginx/json_access.log", "host": "appfelstrudel", "job": "nginx_access_log" }, "values": [ [ "1701096036028751750", "example line" ] ] } ] } } ``` But we want: ```json { "data": { "encodingFlags": [ "categorize-labels" ], "result": [ { "stream": { "agent": "promtail", "filename": "/var/log/nginx/json_access.log", "host": "appfelstrudel", "job": "nginx_access_log" }, "values": [ [ "1701096036028751750", "example line", {} <<<--- WE WANT THIS ] ] } ] } } ``` Co-authored-by: Salva Corts <salva.corts@grafana.com>

We recently introduced support for ingesting and querying structured metadata in Loki. This adds a new dimension to Loki's labels since now we arguably have three categories of labels: _stream_, _structured metadata_, and _parsed_ labels. Depending on the origin of the labels, they should be used in LogQL expressions differently to achieve optimal performance. _stream_ labels should be added to stream matchers, _structured metadata_ labels should be used in a filter expression before any parsing expression, and _parsed_ labels should be placed after the parser expression extracting them. The Grafana UI has a hard time dealing with this same problem. Before grafana/grafana#73955, the filtering functionality in Grafana was broken since it was not able to distinguish between _stream_ and _structured metadata_ labels. Also, as soon as a parser expression was added to the query, filters added by Grafana would be appended to the end of the query regardless of the label category. The PR above implements a workaround for this problem but needs a better API on Loki's end to mitigate all corner cases. Loki currently returns the following JSON for log queries: ```json ... { "stream": { "cluster": "us-central", "container": "query-frontend", "namespace": "loki", "level": "info", "traceID": "68810cf0c94bfcca" }, "values": [ [ "1693996529000222496", "1693996529000222496 aaaaaaaaa.....\n" ], ... }, { "stream": { "cluster": "us-central", "container": "query-frontend", "namespace": "loki", "level": "debug", "traceID": "a7116cj54c4bjz8s" }, "values": [ [ "1693996529000222497", "1693996529000222497 bbbbbbbbb.....\n" ], ... }, ... ``` As can be seen, there is no way we can distinguish the category of each label. This PR introduces a new flag `X-Loki-Response-Encoding-Flags: categorize-labels` that makes Loki return categorized labels as follows: ```json ... { "stream": { "cluster": "us-central", "container": "query-frontend", "namespace": "loki", }, "values": [ [ "1693996529000222496", "1693996529000222496 aaaaaaaaa.....\n", { "structuredMetadata": { "traceID": "68810cf0c94bfcca" }, "parsed": { "level": "info" } } ], [ "1693996529000222497", "1693996529000222497 bbbbbbbbb.....\n", { "structuredMetadata": { "traceID": "a7116cj54c4bjz8s" }, "parsed": { "level": "debug" } } ], ... }, ... ``` Note that this PR only supports log queries, not metric queries. From a UX perspective, being able to categorize labels in metric queries doesn't have any benefit yet. Having said that, supporting this for metric queries would require some minor refactoring on top of what has been implemented here. If we decide to do that, I think we should do it on a separate PR to avoid making this PR even larger. I also decided to leave out support for Tail queries to avoid making this PR even larger. Once this one gets merged, we can work to support tailing. --- **Note to reviewers** This PR is huge since we need to forward categorized all over the codebase (from parsing logs all the way to marshaling), fortunately, many of the changes come from updating tests and refactoring iterators. Tested out in a dev cell with query `'{stream="stdout"} | label_format new="text"`. - Without the new flag: ``` $ http http://127.0.0.1:3100/loki/api/v1/query_range\?direction\=BACKWARD\&end\=1693996529322486000\&limit\=30\&query\=%7Bstream%3D%22stdout%22%7D+%7C+label_format+new%3D%22text%22\&start\=1693992929322486000 X-Scope-Orgid:REDACTED { "data": { "result": [ { "stream": { "new": "text", "pod": "loki-canary-986bd6f4b-xqmb7", "stream": "stdout" }, "values": [ [ "1693996529000222496", "1693996529000222496 pppppppppppp...\n" ], [ "1693996528499160852", "1693996528499160852 pppppppppppp...\n" ], ... ``` - With the new flag ``` $ http http://127.0.0.1:3100/loki/api/v1/query_range\?direction\=BACKWARD\&end\=1693996529322486000\&limit\=30\&query\=%7Bstream%3D%22stdout%22%7D+%7C+label_format+new%3D%22text%22\&start\=1693992929322486000 X-Scope-Orgid:REDACTED X-Loki-Response-Encoding-Flags:categorize-labels { "data": { "encodingFlags": [ "categorize-labels" ], "result": [ { "stream": { "pod": "loki-canary-986bd6f4b-xqmb7", "stream": "stdout" }, "values": [ [ "1693996529000222496", "1693996529000222496 pppppppppppp...\n", { "parsed": { "new": "text" } } ], [ "1693996528499160852", "1693996528499160852 pppppppppppp...\n", { "parsed": { "new": "text" } } ], ... ```

**What this PR does / why we need it**: This is a follow-up PR for grafana#10419 adding support for tailing. I tested it on a dev cell and works fine. <img width="1296" alt="image" src="https://github.com/grafana/loki/assets/8354290/6177e0ca-02ce-48cd-a17f-0739dc3caa0a"> **Note**: With these changes, the JSON marshal unmarshal functions for the tail are no longer used ([example][1]) so I think we can remove them. Also, the new Tail response is no longer used, so we can also make it an alias to the _legacy_ one. Let's do it on a follow-up PR to avoid making this one bigger. [1]: https://github.com/grafana/loki/blob/52a3f16039dd5ff655fc3681257d99794f620ec4/pkg/loghttp/entry.go#L210-L238

…red metadata labels (grafana#11325) This is a followup PR for grafana#10419 wrt this comment grafana#10419 (comment). If there is no parsed nor structured-metadata labels in a given entry, and the categorize-labels header is set, add an empty object to the entry array. For example, we currently return: ```json { "data": { "encodingFlags": [ "categorize-labels" ], "result": [ { "stream": { "agent": "promtail", "filename": "/var/log/nginx/json_access.log", "host": "appfelstrudel", "job": "nginx_access_log" }, "values": [ [ "1701096036028751750", "example line" ] ] } ] } } ``` But we want: ```json { "data": { "encodingFlags": [ "categorize-labels" ], "result": [ { "stream": { "agent": "promtail", "filename": "/var/log/nginx/json_access.log", "host": "appfelstrudel", "job": "nginx_access_log" }, "values": [ [ "1701096036028751750", "example line", {} <<<--- WE WANT THIS ] ] } ] } } ```

salvacorts added 4 commits August 31, 2023 10:22

(WIP) refactor to use grouped labels

e391e63

Merge branch 'main' into salvacorts/flag-group-labels-response

5f6cdaf

Rename groupedLabels to categorizedLabels

9abf0a1

Merge branch 'main' into salvacorts/flag-group-labels-response

8872b87

pull-request-size bot added the size/XXL label Sep 1, 2023

salvacorts added 8 commits September 1, 2023 17:52

Add integration test

59ee8d1

Simplify lables code by using a map

5212782

Extract flag from header

d278a20

Use array instead of map

42980dc

Renamings and test improvements

0284d2b

Merge branch 'main' into salvacorts/flag-group-labels-response

a759ca6

Regen protos after merge

f750451

Fix compile after merge

b3cff8a

salvacorts force-pushed the salvacorts/flag-group-labels-response branch from d67e257 to b3cff8a Compare September 5, 2023 10:53

salvacorts added 7 commits September 5, 2023 15:09

Return nil instead of empty labels. Simplifies testing

a7169bf

Fix format issues

e16185b

Update go.sum

657b8d3

Remove some unintended changes

3b000d2

LabelsResult is categorized right away

c0b3ba4

Update push pkg

f5e3361

Update go.sum

c843deb

salvacorts marked this pull request as ready for review September 7, 2023 06:55

salvacorts requested a review from a team as a code owner September 7, 2023 06:55

Return encodingFlags in response

c2ad556

vlad-diachenko approved these changes Sep 7, 2023

View reviewed changes

owen-d reviewed Sep 12, 2023

View reviewed changes

salvacorts added 4 commits September 13, 2023 11:09

Rename test schema with tsdb and structured metadata

9d25565

Encode flags as map

3816276

Instead of categories in stream, return structured and parsed labels …

ac099bd

…in entry

Update generated files

ec194cb

sandeepsukhani reviewed Oct 3, 2023

View reviewed changes

svennergr mentioned this pull request Oct 11, 2023

Loki: Add backend functionality to parse structured metadata from Loki grafana/grafana#76350

Closed

salvacorts added 6 commits October 13, 2023 16:28

PR feedback

658a2f1

Merge branch 'main' into salvacorts/flag-group-labels-response

a876f2a

Merge branch 'main' into salvacorts/flag-group-labels-response

a2b2c92

Remove encflags from tail response

ffcabbc

Fixes after merge

bd62f62

fix fmt

5127227

sandeepsukhani requested changes Oct 20, 2023

View reviewed changes

salvacorts added 4 commits October 24, 2023 10:33

CR feedback

f136d25

Merge branch 'main' into salvacorts/flag-group-labels-response

88516bd

Fix after merge

addf9da

Update generated and vendor files

0a83c15

sandeepsukhani approved these changes Oct 25, 2023

View reviewed changes

sandeepsukhani merged commit 52a3f16 into main Oct 25, 2023
4 checks passed

sandeepsukhani deleted the salvacorts/flag-group-labels-response branch October 25, 2023 10:16

svennergr mentioned this pull request Oct 30, 2023

Loki: Add backend functionality to parse structured metadata from Loki grafana/grafana#77361

Merged

salvacorts mentioned this pull request Oct 30, 2023

Support categorized labels in Tailing #11079

Merged

salvacorts mentioned this pull request Nov 27, 2023

Categorized Labels: Return empty JSON object if no parsed nor structured metadata labels #11325

Merged

grafanabot mentioned this pull request Nov 28, 2023

[k178] Categorized Labels: Return empty JSON object if no parsed nor structured metadata labels #11331

Merged

svennergr mentioned this pull request Feb 28, 2024

UI: Loki metadata is considered as labels. grafana/grafana#80893

Closed

svennergr mentioned this pull request Apr 24, 2024

Loki: Unable to filter for structured metadata labels grafana/grafana#82323

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Flag categorize labels on streams response #10419

Flag categorize labels on streams response #10419

salvacorts commented Sep 1, 2023 •

edited

Loading

vlad-diachenko left a comment

vlad-diachenko Sep 7, 2023

salvacorts Sep 14, 2023

owen-d left a comment

sandeepsukhani commented Oct 3, 2023 •

edited

Loading

sandeepsukhani left a comment

sandeepsukhani Oct 3, 2023

salvacorts Oct 13, 2023

sandeepsukhani Oct 3, 2023

salvacorts Oct 13, 2023

sandeepsukhani Oct 3, 2023

salvacorts Oct 13, 2023

sandeepsukhani Oct 3, 2023

salvacorts Oct 13, 2023

sandeepsukhani Oct 3, 2023

salvacorts Oct 13, 2023

sandeepsukhani Oct 20, 2023

sandeepsukhani Oct 3, 2023

salvacorts Oct 13, 2023

salvacorts Nov 27, 2023

salvacorts Nov 27, 2023

sandeepsukhani left a comment

sandeepsukhani Oct 20, 2023

salvacorts Oct 24, 2023

sandeepsukhani Oct 20, 2023

salvacorts Oct 24, 2023

sandeepsukhani Oct 20, 2023

sandeepsukhani Oct 20, 2023

salvacorts Oct 24, 2023

sandeepsukhani left a comment

Flag categorize labels on streams response #10419

Flag categorize labels on streams response #10419

Conversation

salvacorts commented Sep 1, 2023 • edited Loading

vlad-diachenko left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

owen-d left a comment

Choose a reason for hiding this comment

sandeepsukhani commented Oct 3, 2023 • edited Loading

sandeepsukhani left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

sandeepsukhani left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

sandeepsukhani left a comment

Choose a reason for hiding this comment

salvacorts commented Sep 1, 2023 •

edited

Loading

sandeepsukhani commented Oct 3, 2023 •

edited

Loading