Daily Driver Transformations for Decision-Ready Panels | CodeSignal Learn

Daily Driver Transformations for Decision-Ready Panels | CodeSignal Learn

Introduction: Turning “Correct Data” into “Decision-Ready Data”

At this point in the course, you already know how to get Grafana-ready time series, how to enrich them with joins, and how to keep dashboards reusable with clean field organization. This unit is about the last mile: shaping results into something a human can scan in five seconds and confidently act on. In practice, that usually means taking a dataset that’s technically correct and making it smaller, clearer, and ranked. The transformations you’ll use constantly for that are: Filter data by values Group by Reduce Rename by regex And one honorable mention that shows up everywhere operational dashboards exist: Sort by Grafana transformations run sequentially (top to bottom) . Each transformation modifies the dataset that the next transformation receives, so the order is part of the logic. For example, Reduce \to Sort by creates a meaningful “Top offenders” ranking, while Sort by \to Reduce usually just rearranges raw datapoints before collapsing them.

Part 1: Filter Data by Values (Make the Panel Stop Yelling)

Filter data by values is a noise-reduction transformation that lets you hide data that isn’t actionable, without changing the underlying query. This keeps your SQL reusable and shifts “what matters right now” decisions into the panel itself. It’s especially useful for dashboards where normal behavior should fade into the background and only problematic states should draw attention. Imagine a table of API request metrics with fields like endpoint, latency_ms, and error_rate . Most endpoints respond quickly and have no errors, but occasionally one endpoint becomes slow or unstable. Rather than showing everything, you can filter the data so the panel only displays rows where latency_ms is high or the error rate crosses a threshold. The result is a quieter dashboard that highlights issues instead of normal traffic. To do this, it helps to understand the key controls: Filter type (Include / Exclude): Include keeps rows that match your condition (for example, keep requests with latency \geq 500 ms), while Exclude removes matching rows (for example, hide rows where status is 200). Match all / Match any: determines how multiple conditions work together. Match all means every condition must be true (latency \geq 500 and error_rate \geq 1%), while Match any means a row is kept if at least one condition is true. Field: the column you are filtering on, such as latency_ms or error_rate . Transformations work on table fields, not on the visual series names in the chart. Match condition: defines how the comparison is done, such as greater than, equal to, or is null. This panel filters out normal API traffic and only shows latency values above 500 ms, making performance issues immediately visible without changing the underlying query. Used together, these options let you shape attention rather than data: the query defines what exists, and Filter data by values defines what deserves to be seen.

Sign up

Join the 1M+ learners on CodeSignal

Be a part of our community of 1M+ users who develop and demonstrate their skills on CodeSignal

Part 2: Group By (Rollups Without Rewriting SQL)

Group by is the transformation you use when raw, detailed data is technically correct but operationally overwhelming. It’s how you move from individual data points to category-level understanding — without touching the original SQL. This is especially useful when someone asks for a summary by a meaningful dimension such as team, service, region, cluster, or endpoint, and you want an answer you can read at a glance. For example, consider this query, which returns API latency over time for every endpoint: SQL SELECT $__time(ts), endpoint AS metric, latency_ms AS value FROM public.metrics_api_latency WHERE $__timeFilter(ts) ORDER BY 1; By default, this produces many rows per endpoint and per timestamp. That’s great for debugging a single endpoint, but noisy when the real question is: “Which endpoint is performing the worst?” Applying a Group by transformation on endpoint and calculating Max for value collapses all those rows into a compact rollup: one row per endpoint, showing its highest observed latency in the selected time range. You get the operational answer without rewriting the query or duplicating logic in SQL. Two practical guidelines help keep Group by panels clean and useful. First, group on stable, human-recognizable labels (like endpoint, service, or team), not high-cardinality or unique identifiers that explode the table. Second, choose one clear aggregation per numeric field — max when you care about spikes, mean for typical behavior, or last for current state. If you aggregate everything in every possible way, the panel stops being a dashboard and turns into a spreadsheet.

Part 3: Reduce (Turn Time Series into a Single “Headline” Value)

Reduce is the transformation that converts many points over time into one value that represents the selected time range. You use it when a panel should stop telling a story and start answering a question, such as “What’s happening right now?”, “Did we spike during this window?”, or “What was typical behavior recently?”. Different Reduce calculations support different intents: Last is used for current-state panels, Max is useful for incident analysis (“did it spike?”), and Mean helps describe typical behavior over a time window. For example, consider a query that returns API latency over time per endpoint: SQL SELECT $__time(ts), endpoint AS metric, latency_ms AS value FROM public.metrics_api_latency WHERE $__timeFilter(ts) ORDER BY 1; On its own, this is great for a graph, but not for comparison. Applying Reduce with the Max calculation collapses each endpoint’s time series into a single value: the highest latency observed in the selected time range. That makes it easy to identify the slowest endpoint or build a “top offenders” panel. In practice, you’ll also see Last and Last * used frequently for “right now” views. Last literally returns the final value in the time range — which means if the most recent datapoint is null (for example, due to missing scrapes, delayed ingestion, an endpoint that reports intermittently, or a time bucket with no events), your “current value” will show up as blank even if there was a valid value a minute earlier. Last * skips nulls and returns the most recent non-null value instead. This is usually safer for sparse or event-driven data (like “errors in the last minute” or “jobs completed”) where gaps are normal and you still want a meaningful “latest known value.” Reduce is foundational because it turns behavior over time into a single, comparable number—exactly what most operational dashboards need.