Using Datadog Log Facets to Speed Up High‑Cardinality Log Queries

Problem: Slow log searches when you need to filter by unique identifiers

When you troubleshoot a production issue, you often want to narrow logs down to a specific user ID, request ID, or tenant token. These fields can have thousands or millions of distinct values. In Datadog Log Explorer, relying on free‑text search or wildcard matches for such high‑cardinality attributes forces the system to scan large portions of the ingested log stream, which adds latency and can hit query‑rate limits.

Thesis: Enabling a log facet on a selected attribute creates a separate, lightweight index that returns matching logs instantly, while keeping ingest cost unchanged.

What are Datadog Log Facets?

A facet is an indexed attribute that Datadog stores in a dedicated structure alongside the raw log data. Once an attribute is added as a facet, the Log Explorer shows it in the filter sidebar and can apply the filter without scanning the full log set. The facet index grows proportionally to the number of unique values retained for that attribute, but there is no extra ingest charge beyond the standard log volume.

Worked example: Adding a facet for http.method

1. Where to run: In the Datadog app, navigate to Logs → Configuration → Facets. You need the logs_config_read and logs_config_write permissions.
2. Action: Click Add facet, enter the attribute name exactly as it appears in your logs (e.g., http.method), and save.
3. Verification via UI: After a few logs containing http.method have been ingested, open the Log Explorer. The filter sidebar should now list http.method with checkboxes for values like GET, POST, PUT, etc. Selecting a value returns matching logs instantly.
4. Verification via API: Run GET https://api.datadoghq.com/api/v1/logs/config/facets with your API and application keys. The response JSON will include an entry for http.method in the facets array. Adding the facet through the API (POST to the same endpoint with a JSON body {"attribute":"http.method"}) will produce the same result.
5. Performance check: In the Log Explorer, run two queries that return the same set of logs:
   • Free‑text search: http.method:GET (this triggers a full‑text scan).
   • Facet filter: open the sidebar, check GET under http.method.
   • Observe the response time shown in the query bar; the facet filter should return results noticeably faster, especially as log volume increases.

Trade‑off and limitation: Index size grows with cardinality

While facets add no ingest cost, each unique facet value consumes storage in the facet index. If you enable a facet on an extremely high‑cardinality field such as a raw UUID or a timestamp with millisecond precision, the index can grow large enough to hit account‑level facet limits or increase storage costs due to longer retention. To mitigate this, you can:

• Sample the attribute (e.g., log only 1 in 100 requests) before it becomes a facet.
• Hash the value to reduce the number of distinct keys while preserving equality checks for a subset of use cases.
• Combine the attribute with a lower‑cardinality prefix (e.g., service name + short request ID) to keep the index manageable.

Datadog provides a facet usage metric under Logs → Usage → Facets that shows the current number of unique values and the trend over time, allowing you to stay within limits.

Actionable closing: Review, enable, monitor

Start by identifying the high‑cardinality fields you query most often in Log Explorer (look for filters you repeatedly type or paste). For each candidate, test the facet enablement steps above on a low‑traffic subset of logs, verify the speed improvement, and check the facet usage metric. If the index size stays acceptable, roll the facet out to the relevant log sources. Periodically revisit the usage dashboard to ensure that new services or changes haven’t pushed a facet beyond its safe cardinality threshold.