hyperdxio/hyperdx @hyperdx/common-utils@0.31.0

on GitHub

Minor Changes

• 6873416: feat: Add a series mode to builder heatmaps

• ff5befa: Support "Minimum auto granularity" on PromQL sources. It floors the step of charts on auto granularity, as it does for metric sources, and $__rate_interval now uses it as the source's scrape interval (still 15s when unset) instead of always assuming 15s. A granularity picked on a tile is never changed.

• d8b1cdf: feat: Attribute PromQL queries to the dashboard, tile or search that issued them, through both the prometheusQuery/prometheusQueryRange table functions and ClickHouse's Prometheus HTTP API

• ab70324: feat: attribute ClickHouse queries to the dashboard, tile, search or alert that
  issued them

  A row in system.query_log previously couldn't be attributed to the part of
  HyperDX that produced it. Now every query HyperDX runs has a small JSON
  log_comment, plus a query_id starting with hdx-.

  Attribute load after the fact:

  SELECT
      JSONExtractString(log_comment, 'surface') AS surface,
      JSONExtractString(log_comment, 'dashboard') AS dashboard,
      JSONExtractString(log_comment, 'tile') AS tile,
      count(),
      sum(read_rows)
  FROM system.query_log
  WHERE type = 'QueryFinish' AND log_comment != '' AND query_id like 'hdx-%'
  GROUP BY ALL
  ORDER BY sum(read_rows) DESC

  Or spot a query while it is still running, in system.processes, where the
  query_id names the surface with no JSON parsing needed.

  The payload records which part of the product asked (a dashboard, a search, an
  alert, an MCP tool, the chart explorer, session replay, field lookups, and so
  on), the dashboard and tile or saved search id, the source id, and on the server
  the trace id of the request. Field lookups and autocomplete are labelled too, so
  they can be told apart from a user's chart queries.

  The exception is queries that skip settings processing: the system.settings,
  server version and Cloud-detection probes, and the onboarding connection check.
  They get a query_id but an empty log_comment.

• 68082b6: feat: add stacked line (stacked area) time-series display type

Patch Changes

• 07c9365: fix: cast FixedString columns before implicit hasToken search

  A bare search term against a FixedString column such as OTel TraceId compiled to
  hasToken(lower(TraceId), ...), which ClickHouse rejects. Those haystacks are now
  CAST to String first.

• 0b85553: fix: fall back to the Map key scan when the text index read fails

  getMapKeys returned an empty list whenever its mergeTreeTextIndex query
  failed, so the rollup and bounded mapKeys scan paths never ran. ClickHouse
  refuses mergeTreeTextIndex with ACCESS_DENIED on any table with a row
  policy, which left search autocomplete with no Map keys on those tables. A
  failed text index read now falls through to the next strategy. After a row
  policy denial it skips the key rollup table, which the policy doesn't cover,
  and reads keys only from the policy-filtered source table.

• 0846f3b: Include the requested Map-key limit in metadata cache keys so MCP discovery and AI field discovery cannot reuse each other's differently limited results.

• e61461b: feat: auto-detect a PromQL source during onboarding

  When PromQL is enabled (NEXT_PUBLIC_ENABLE_PROMQL=true), onboarding source auto-detection now also creates a PromQL source for a ClickHouse TimeSeries engine table. It prefers prometheus.metrics (the table the ClickHouse Prometheus docs suggest), then a table named metrics_ts, and otherwise picks the only TimeSeries table on the connection. A service with only a TimeSeries table is no longer sent to manual source setup.

• 1be9de8: feat: Add a promql variable format that escapes based on single/multi-select

• 0d2425d: feat: Allow configuring dashboard filters as single-select

• 1ce8b88: fix: rank Map keys by frequency when a text index serves key discovery

  The two mergeTreeTextIndex paths in getMapKeys grouped keys and applied
  LIMIT maxKeys with no ORDER BY, so on a column with more keys than the
  limit the filter sidebar showed an arbitrary subset. They now order by
  sum(cardinality) DESC, key, which keeps the most frequent keys, as the key
  rollup path already does with sum(count) DESC.