Facet-driven telemetry search cuts query cost at petabyte scale

At a glance

What this is: This is a blog post about using facets to make large-scale telemetry search faster by indexing fields before data is queried.

Why it matters: It matters to practitioners because telemetry search speed affects detection, triage, and investigation workflows across cloud, identity, and SOC operations.

👉 Read Edge Delta's facet search blog for pipeline and query examples

Context

Observability search becomes expensive when teams treat richly enriched logs as if they were flat text. Once service names, pod IDs, regions, and status codes are buried inside unstructured records, every query has to work harder, which slows detection and increases compute consumption.

The article is fundamentally about telemetry indexing and search efficiency, but it also intersects with security operations because faster search changes how quickly teams can investigate identity events, cloud incidents, and workload abuse. That makes the control question one of data structure and retrieval design, not just logging volume.

Key questions

Q: How should security teams structure telemetry so searches stay fast at scale?

A: Teams should extract and normalise the fields they query most often before data is indexed. That keeps search anchored to structured attributes instead of raw text, which reduces read volume and improves incident triage. The key is to design telemetry around real investigation patterns, not around storage convenience.

Q: Why do unstructured logs slow down incident response?

A: Unstructured logs force queries to scan more data because the system cannot jump directly to the fields analysts need. As volumes rise, that increases latency, compute cost, and cognitive load during an investigation. Structured facets reduce that burden by making common filters direct and repeatable.

Q: What breaks when telemetry fields are inconsistent across sources?

A: Search becomes fragmented when equivalent fields are named differently or contain mismatched formats. Analysts end up writing extra filters, normalising output manually, or missing relationships across sources. Consistency matters because searchable telemetry depends on shared semantics as much as on indexing.

Q: How can teams decide which telemetry fields deserve facet treatment?

A: Use incident history and SOC workflows to identify the attributes that appear in repeated filters, correlation steps, and escalation decisions. Those fields are the best candidates for facets because they carry the most operational value. If a field rarely drives a question, it does not need to consume indexing priority.

Technical breakdown

Why raw-text telemetry search breaks at scale

Raw-text search scans records line by line, which is tolerable for small datasets but inefficient when logs reach petabyte scale. Facets change the model by indexing a field such as status, service, or region so the query engine can jump directly to matching values. That reduces read operations and improves search speed because the system no longer needs to inspect every message payload. In practice, the performance gain comes from pre-structured metadata, not from a smarter query string.

Practical implication: teams should identify the fields they repeatedly filter on and promote them to indexed facets before search latency becomes operational debt.

How telemetry pipelines create facets before indexing

Telemetry pipelines sit upstream of the observability platform and reshape data before it is stored. That is important because once records are indexed, they are harder to reorganise without reprocessing or duplication. The article describes two patterns: pre-built parsing packs for known log formats and custom OTTL statements for extracting a single attribute. Both approaches turn opaque records into structured telemetry that downstream search can use efficiently. This is a data engineering control, but it directly affects incident response readiness.

Practical implication: define facet creation in the ingestion pipeline, not as a downstream workaround after search performance degrades.

Why search filters become more useful when facets are consistent

Facet-based filtering only works well when the same attribute names and value formats are used consistently across sources. If one pipeline labels a field as source.ip and another uses src_ip, search quality drops and analysts lose time reconciling differences. The operational value of facets therefore depends on schema discipline, field normalisation, and repeatable enrichment logic. In security terms, this is the difference between searchable telemetry and fragmented data that cannot support fast investigation.

Practical implication: standardise field naming and normalisation rules across cloud, application, and security logs before relying on facet search for operations.

NHI Mgmt Group analysis

Facet design is a telemetry governance problem, not just a search feature. The article shows that downstream query performance depends on whether teams structure data at ingest time. That is a familiar control pattern in security operations: if metadata is inconsistent, analysts pay the cost later in slower investigations and noisier triage. For identity-adjacent telemetry such as authentication failures, service account activity, or workload access events, field consistency becomes part of operational resilience.

Pre-index enrichment is the real control point. Once logs are indexed, the opportunity to create efficient search paths narrows sharply. That means teams should treat pipeline parsing, field extraction, and schema normalisation as first-class operational controls, not optional tuning. The practical conclusion is simple: if a field matters for investigation, it should be shaped before storage, not after analysts are already under pressure.

Named concept: telemetry retrieval debt. This is the cost that accumulates when searchable fields are not designed into the ingestion path and investigators must compensate with slower queries, broader scans, and manual filtering. The article is a clear example of how retrieval debt grows out of data architecture choices. For practitioners, the lesson is to align pipeline design with the questions incident responders actually need to answer.

Observability efficiency and security efficiency increasingly converge. Faster access to structured telemetry shortens the loop between anomaly detection, identity investigation, and containment decisions. That matters in environments where authentication, workload, and application events all intersect. Practitioners should therefore evaluate search performance as part of the control environment, not as a separate platform metric.

What this signals

Search performance is increasingly part of operational security design because the ability to query the right telemetry quickly affects how fast teams can validate alerts and scope incidents. In environments that mix cloud, identity, and workload events, structured data is what makes investigation practical rather than theoretical.

Telemetry retrieval debt: organisations accumulate this when they delay schema design, field normalisation, and facet creation until after data has already been indexed. Once that happens, analysts compensate with slower searches and broader scans, which undermines both SOC efficiency and broader resilience planning.

For practitioners, the signal is that observability platforms should be evaluated on ingest-time structuring as much as on dashboard usability. Faster search is not a nice-to-have when incident response depends on correlating authentication, service, and infrastructure evidence under pressure.

For practitioners

• Define high-value facet fields Identify the fields analysts repeatedly use during triage, such as service, region, status code, source IP, and workload identifiers, then promote those fields to indexed facets in the ingest path.
• Normalise field names across pipelines Create a shared schema for telemetry sources so equivalent attributes use the same field names, reducing fragmentation between cloud, application, and security logs.
• Use pipeline parsing before indexing Apply pre-built packs or custom OTTL statements before data reaches the observability store, because post-index restructuring is slower and often incomplete.
• Test query cost against real incident patterns Benchmark search latency and read volume using the questions your SOC, IAM, and cloud teams actually ask during incidents, then adjust facet design accordingly.

Key takeaways

• Facet-based search improves observability performance by indexing the fields analysts actually use during investigation.
• The bottleneck is usually data structure at ingest time, not the search query itself.
• Teams that normalise telemetry early will investigate faster, spend less on avoidable query load, and reduce retrieval debt.

Key terms

• Facet: A facet is a structured field used to filter, group, or aggregate telemetry data efficiently. Instead of searching raw log text, analysts query indexed attributes such as service name, region, or status code, which reduces read operations and speeds investigation.
• Telemetry pipeline: A telemetry pipeline is the path security data follows from collection to analysis and retention. In mature environments it must preserve context, maintain throughput, and avoid introducing blind spots as sources, formats, and volumes change over time.
• Telemetry Context Debt: Telemetry context debt is the growing gap between raw data volume and the contextual information needed to interpret it correctly. When source lineage, ordering, firmware state, and cohort data are missing, analysis becomes slower, less trustworthy, and harder to reproduce across teams.

What's in the full article

Edge Delta's full blog post covers the operational detail this post intentionally leaves for the source:

• Step-by-step facet creation examples using pipeline packs for structured log parsing.
• Custom OTTL field extraction details for building a facet from a single attribute.
• Interface walkthroughs showing how custom facet filters appear in the observability platform.
• Examples of using facets against AWS, Docker, and Kubernetes log sources.

👉 The full Edge Delta post shows how to build and use facets in the telemetry pipeline and observability platform.

Deepen your knowledge

NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course, the industry's only accredited NHI security programme. It is suitable for practitioners building stronger access, lifecycle, and governance controls across identity programmes.