Skip to main content
Solved

Access specific repeated UDM labels in Dashboards (UDM Search)

  • February 12, 2026
  • 5 replies
  • 110 views

pranay_mak
Forum|alt.badge.img+2

I’m struggling with a use case involving repeated fields in UDM and was wondering if anyone has found a viable workaround or if this should be flagged as a bug/feature gap.

The Use Case

I want to create a UDM Dashboard with a pie chart showing the distribution of values for a specific label key (e.g., source_name).

The Data Structure

My ingested events contain multiple entries in the metadata.source_labels array. For example:

  • key: "source_name", value: "Kaspersky"

  • key: "source_score", value: "100"

  • key: "source_name", value: "Symantec"

  • key: "source_score", value: "200"

  • ... (and 10 other unrelated labels)

The Problem

When I try to write the query for the dashboard, I encounter two main issues:

  1. Over Counting: If I use graph.metadata.source_labels.key = "source_name" in event section and then count(graph.metadata.source_labels.value) in the outcome section, the system flattens the entire array. Instead of counting "Kaspersky" and "Symantec", it returns a count of 12 because it counts every value present in the labels array for that event.

  2. Indexing Limitation: If I try to access the key directly using graph.metadata.source_labels["source_name"] syntax, it only retrieves the first instance of that key. In the example above, it sees "Kaspersky" but completely ignores "Symantec," leading to inaccurate data in my pie chart.

Questions

  1. Is there a way in UDM Search or Dashboards to filter repeated keys so the count only applies to values where the key matches a specific string?

  2. Has anyone successfully used a any logic in Dashboard queries to handle multiple instances of the same key within one event?

This is a frequent requirement for threat intel and multi source telemetry. If this isn't currently possible, I’d like to understand if this is a known limitation or if a bug should be raised.

Thanks in advance!

Best answer by jstoner

I’ve put out some additional questions internally as I have not come up with a specific solution during my testing. I would suggest opening a ticket on this in the meantime and if there isn’t a specific solution a bug/feature request can be opened to help address this topic. I wish I had a better solution but to date I can’t identify one.

5 replies

jstoner
Community Manager
Forum|alt.badge.img+23
  • Community Manager
  • February 12, 2026

I don’t have multiple source_names keys to attempt to replicate exactly what you have. However I do have graph.entity.asset.attribute.labels both with a key of ancestors.

 

For your first question, I wonder if you should use count_distinct to get a better count?

I tested this in search and got an expected result. I will say that I opened a ticket around dashboards because that isn’t consistent and I need someone to run down why that is.

$b = count_distinct(graph.entity.asset.attribute.labels["ancestors"])

 

 

Regarding the second question, I could not get to that second value directly using the key/value notation because once it finds the first one it moves on. A way to solve that is to add criteria like what I have below and specify exactly the key and value as two pieces of logic in the search or dashboard.

 

graph.entity.asset.attribute.labels.value = "organizations/123445677"

graph.entity.asset.attribute.labels.key = "ancestors"

 

 


pranay_mak
Forum|alt.badge.img+2
  • Author
  • New Member
  • February 13, 2026

Thanks for the response! I’ve tested the count_distinct approach, but unfortunately, it doesn't solve the core issue of "Label Leakage."


The problem is that count_distinct on a repeated field evaluates the entire array. Here is a specific example of why the current syntax fails for multi-value keys:

The Data Scenario

Imagine a single UDM entity with these labels:

  1. graph.entity.asset.attribute.labels.key: "ancestors", value: "A"

  2. graph.entity.asset.attribute.labels.key: "ancestors", value: "B"

  3. graph.entity.asset.attribute.labels.key: "ancestors", value: "C"

  4. graph.entity.asset.attribute.labels.key: "other_key", value: "Z"

  5. graph.entity.asset.attribute.labels.key: "other_key", value: "Y"

The Failed Logic

If I write a query intended to count only "ancestors":

graph.entity.asset.attribute.labels.key = "ancestors"
outcome:
   $count = count_distinct(graph.entity.asset.attribute.labels.value)

  • Expected Result: 3 (A, B, C)

  • Actual Result: 5 (A, B, C, Z, Y)

Why? Because the UDM engine sees that the event has a key called "ancestors," so it proceeds to count all distinct values within the graph.entity.asset.attribute.labels.valueobject for that event, regardless of which key they belong to.

 

Why labels["key"] notation doesn't work

As mentioned in the previous reply, using graph.entity.asset.attribute.labels["ancestors"] only grabs the index[0] (the first occurrence). If an event has three different ancestors, the dashboard will only ever "see" the first one, making the pie chart or bar graph statistically incorrect.
 

Refined Question:

Since hardcoding values is not an option (I need to discover and count all unique values dynamically), is there any way to scope the count_distinct function so it only looks at the value where the key=”ancestors” ?


pranay_mak
Forum|alt.badge.img+2
  • Author
  • New Member
  • February 16, 2026

Hi ​@jstoner - Could you please check this once, we are stuck on this due to this issue?


Asura
Forum|alt.badge.img+3
  • February 16, 2026

Hello ​@pranay_mak,

I once had a similar issue when needing to count on all emails of a user.

Did you try to assign graph.entity.asset.attribute.labels["ancestors"] to a variable?

$ancestors = graph.entity.asset.attribute.labels["ancestors"]

You can then count_distinct($ancestors) in your outcome section.

 

Hopefully it helps


jstoner
Community Manager
Forum|alt.badge.img+23
  • Community Manager
  • Answer
  • February 17, 2026

I’ve put out some additional questions internally as I have not come up with a specific solution during my testing. I would suggest opening a ticket on this in the meantime and if there isn’t a specific solution a bug/feature request can be opened to help address this topic. I wish I had a better solution but to date I can’t identify one.