/beacon

Dashboard Design Reference

RED/USE methods and Grafana dashboard-as-code reference.

Dashboard Frameworks

RED Method (Request-driven services)

USE Method (Resource-oriented)

Four Golden Signals (Google SRE)

Profiles — The Fourth OpenTelemetry Signal (2026)

OpenTelemetry Profiles reached Alpha in March 2026, joining logs, metrics, and traces as a first-class signal. Dashboards in 2026 should reserve a panel for continuous CPU / allocation profiles anchored to the same time window as the RED panels above — the profile answers "where did the latency or saturation come from in code", which traces and metrics together cannot.

Recommended wiring:

A "Service Detail" dashboard should hand the on-call engineer a flame graph that auto-scopes to the failing span when they click an outlier on the latency panel. Without that integration, profiling exists but does not change incident response time.

Dashboard Hierarchy

Level 1: Executive Overview (SLO status, budget remaining)
    └── Level 2: Service Overview (RED per service)
        └── Level 3: Service Detail (endpoints, dependencies)
            └── Level 4: Debug (traces, logs, resource detail)

Dashboard Types

Grafana Dashboard-as-Code

Jsonnet Pattern

local grafana = import 'grafonnet/grafana.libsonnet';
local dashboard = grafana.dashboard;
local row = grafana.row;
local prometheus = grafana.prometheus;
local graphPanel = grafana.graphPanel;

local serviceDashboard(service) =
  dashboard.new(
    title='%s Service Overview' % service,
    tags=['generated', 'service'],
    refresh='30s',
    time_from='now-1h',
  )
  .addRow(
    row.new(title='RED Metrics')
    .addPanel(
      graphPanel.new(
        title='Request Rate',
        datasource='Prometheus',
      ).addTarget(
        prometheus.target(
          'sum(rate(http_requests_total{service="%s"}[5m]))' % service,
          legendFormat='{{method}} {{status_code}}',
        )
      )
    )
  );

{
  'payment-service.json': serviceDashboard('payment-service'),
  'user-service.json': serviceDashboard('user-service'),
}

Terraform Provisioning

resource "grafana_dashboard" "service_overview" {
  for_each = toset(var.services)

  config_json = templatefile("${path.module}/templates/service-dashboard.json.tpl", {
    service_name = each.key
    slo_target   = var.slo_targets[each.key]
  })

  folder = grafana_folder.services.id
}

Panel Design Guidelines

Common Panel Patterns

Dashboard Sprawl Prevention

Anti-patterns:
  x  L2-level detail in on-call dashboards (too much noise)
  x  Each team creating custom-format dashboards (no single source of truth)
  x  20+ panels per dashboard (cognitive overload)
  x  Graphs without context (unclear what "normal" looks like)

Countermeasures:
  - Enforce L0/L1/L2 hierarchy for all new dashboards
  - Use shared templates (Jsonnet/Terraform) for consistency
  - Require level designation (L0/L1/L2) at creation time
  - Max 8-12 panels per dashboard
  - Include "what is normal" annotations on every graph
  - Quarterly dashboard audit: remove unused, consolidate duplicates