Dashboard-Ready Metric Extraction Prompt Template

This prompt is designed for platform engineers and AI SREs who need to convert raw, unstructured trace spans into structured, time-series data points suitable for dashboards like Grafana or Datadog. The core job-to-be-done is reliable, repeatable metric extraction and normalization. Use it when you have a batch of trace spans and need to produce a consistent set of metrics, aggregation windows, and dimension labels that conform to a predefined naming convention. The ideal user has a solid understanding of their observability data and a clear target schema for their metrics.

Before using this prompt, you must have a defined [OUTPUT_SCHEMA] that specifies the exact metric names, types (gauge, counter, histogram), and label dimensions you expect. The prompt enforces this schema, rejecting extractions that don't conform. This is not a prompt for ad-hoc data exploration or real-time alert evaluation. It will not perform threshold checks or anomaly detection; its sole purpose is extraction and normalization. For real-time alerting, pair this prompt's output with a separate rules engine or use a dedicated alert condition prompt. Do not use this prompt if your trace data contains sensitive user information that hasn't been redacted, as the prompt processes the raw text directly.

To get started, gather a representative sample of your raw trace spans and your target metric schema. The next section provides the copy-ready prompt template. After integrating it, you will need to build a validation harness to check the output against your schema before sending data to your dashboarding system. Avoid the temptation to add alerting logic directly into this prompt; keeping its responsibility narrow ensures predictable, testable behavior in your monitoring pipeline.

This template converts unstructured or semi-structured trace data into a strict time-series metric format. It is designed for platform engineers who need to pipe production observability data into dashboards without writing brittle parsing code. The prompt enforces metric naming conventions, aggregation windows, and dimension labels so the output can be directly consumed by a metrics API or collector. Use this when you have raw span JSON and need consistent, validated metric points. Do not use it for real-time alerting logic—that belongs in the alert condition definition prompts.

textCopy
You are a production metrics extraction engine. Your task is to convert raw trace spans into structured time-series metric points suitable for dashboard ingestion.

INPUT TRACE SPANS:
[RAW_TRACE_SPANS]

METRIC DEFINITIONS TO EXTRACT:
[METRIC_DEFINITIONS]

AGGREGATION WINDOW:
[AGGREGATION_WINDOW_SECONDS]

DIMENSION LABELS TO INCLUDE:
[DIMENSION_LABELS]

OUTPUT SCHEMA (strict JSON array):
[
  {
    "metric_name": "string (must match [METRIC_NAMING_CONVENTION])",
    "timestamp": "ISO 8601 UTC",
    "value": number,
    "aggregation": "sum | avg | p50 | p95 | p99 | count | rate",
    "window_start": "ISO 8601 UTC",
    "window_end": "ISO 8601 UTC",
    "dimensions": {
      "[DIMENSION_LABELS]": "string"
    },
    "source_span_ids": ["string"],
    "confidence": 0.0-1.0
  }
]

CONSTRAINTS:
[CONSTRAINTS]

EXAMPLES:
[FEW_SHOT_EXAMPLES]

Before outputting, validate:
1. Every metric_name matches the [METRIC_NAMING_CONVENTION] pattern.
2. Timestamps fall within the aggregation window.
3. Aggregation method matches the metric definition.
4. All required dimension labels are present and non-empty.
5. source_span_ids reference spans present in the input.
6. confidence reflects data completeness (1.0 = all expected spans present, <1.0 = gaps).

If validation fails for any metric point, exclude it and include it in a separate "rejected_points" array with a "rejection_reason" field.

Adapt this template by replacing each square-bracket placeholder with your production data. [RAW_TRACE_SPANS] should contain the JSON array of span objects from your tracing system. [METRIC_DEFINITIONS] specifies which metrics to extract—for example, latency_ms from span duration, token_count from span attributes, or tool_call_error from span status. [AGGREGATION_WINDOW_SECONDS] defines the time bucket (e.g., 60 for per-minute metrics). [DIMENSION_LABELS] lists the span attributes to preserve as dimensions, such as model_version, prompt_id, or session_id. [CONSTRAINTS] can include value ranges, required label combinations, or exclusion rules. [FEW_SHOT_EXAMPLES] should show 2-3 correct input-output pairs covering normal spans, error spans, and edge cases like missing attributes. Wire the output into your metrics pipeline with a JSON Schema validator that rejects any point violating the naming convention or missing required dimensions before ingestion.

This prompt is designed to be called by an automated pipeline, not a human chat interface. The primary integration point is a scheduled job or a webhook that fires after trace ingestion. The harness must supply the raw trace span data as [INPUT], the target metric schema as [OUTPUT_SCHEMA], and the aggregation window as [CONSTRAINTS]. The model's response should be treated as a structured payload that requires validation before it reaches any time-series database or dashboard.

The implementation harness should follow a strict validate-then-ingest pattern. After receiving the model's JSON output, apply a schema validator that checks for required fields (metric_name, value, timestamp, dimensions), enforces the snake_case naming convention defined in [OUTPUT_SCHEMA], and rejects any metric name that does not match the allowed prefix list. If validation fails, the harness should retry the prompt once with the validation error message appended to [CONSTRAINTS]. If the second attempt also fails, log the raw trace span, the model's malformed output, and the validation errors to a dead-letter queue for manual review. Never ingest unvalidated metrics into Grafana or Datadog.

For model choice, prefer a model with strong JSON mode and low latency, such as gpt-4o-mini or claude-3-haiku, since this prompt runs on a high-volume trace stream. Set temperature=0 to maximize output determinism. The harness should also implement idempotency keys based on trace_id and aggregation_window to prevent duplicate metric points if the pipeline retries a batch. Finally, expose a prompt_version label on every emitted metric so dashboard queries can isolate regressions caused by prompt changes. Do not use this prompt for real-time alerting thresholds; it is designed for near-real-time dashboard population where a 60-second processing delay is acceptable.