Observability Event Payload Prompt Template

This prompt is designed for platform engineers and SREs who need to convert raw telemetry signals, unstructured logs, or incident narratives into a single, validated event record conforming to the OpenTelemetry (OTel) event data model. The primary job-to-be-done is bridging the gap between human-readable incident descriptions and the structured payloads required by downstream observability pipelines, such as OpenTelemetry collectors, tracing systems (e.g., Jaeger, Tempo), and monitoring dashboards. The ideal user is someone integrating an AI step into an observability pipeline who cannot tolerate transformation errors or schema violations that would cause data rejection at the collector level.

Use this prompt when you have a clear source of event data—such as an alert description, a log line, or an incident narrative—and you need a single, validated JSON output that includes required span context (traceId, spanId), resource attributes (service.name, service.version), and a normalized severity field (SeverityNumber and SeverityText). It is appropriate for low-to-medium throughput scenarios where each generation is an independent event. Do not use this prompt for bulk log parsing or high-throughput stream processing where a single model call per event is cost-prohibitive; instead, use a deterministic parser for known formats and reserve this prompt for unstructured or novel inputs. It is also not a replacement for an SDK—use it to generate payloads that your application code then validates and dispatches.

Before implementing, ensure your pipeline can handle the required inputs: you must provide the raw event narrative and the current active span context. The prompt is designed to be stateless, so each call must include the full context. The output is a single JSON object, not an array of events. If you need to process a batch of events, call this prompt for each one individually or pair it with a separate extraction prompt to split a narrative into multiple events first. The next step after reading this section is to review the prompt template and adapt its placeholders to your specific observability backend's schema requirements.

This prompt template is designed to be integrated directly into your observability pipeline. It instructs the model to act as a structured data generator, consuming raw incident context and producing a single, valid JSON object that conforms to the OpenTelemetry event data model. The primary goal is to eliminate manual log formatting and ensure that AI-generated events are immediately ingestible by collectors like the OpenTelemetry Collector, Jaeger, or Grafana without post-processing scripts.

textCopy
Generate a single OpenTelemetry-compatible event payload in JSON format from the following inputs. Follow the OTel event data model specification strictly. Return only the JSON object, enclosed in a markdown code block with language `json`.

[INPUT]

[CONTEXT]

[OUTPUT_SCHEMA]

[CONSTRAINTS]

[EXAMPLES]

[TOOLS]

[RISK_LEVEL]

To adapt this template, replace the placeholders with concrete values for your specific use case. [INPUT] should contain the raw incident text or signal. [CONTEXT] should provide static resource attributes like service.name and service.version. [OUTPUT_SCHEMA] must define the exact JSON structure, including required fields like name, body, time_unix_nano, and attributes. Use [CONSTRAINTS] to enforce rules like controlled vocabularies for severity_text or valid trace ID formats. [EXAMPLES] should include a few-shot demonstration of a correct payload. [TOOLS] is optional but can be used to instruct the model to call a validation function. [RISK_LEVEL] should be set to HIGH for security or compliance events, triggering a mandatory human review step in the implementation harness before the event is emitted.

Wiring this prompt into an observability pipeline requires treating the model output as an untrusted event source until it passes structural and semantic validation. The prompt is designed to produce OpenTelemetry-compatible payloads, but in production you must assume that any field can be missing, malformed, or outside the expected enum. The implementation harness wraps the model call in a validation layer that checks required fields (traceId, spanId, timestamp, severityNumber, body), verifies timestamp format against RFC 3339, confirms severityNumber maps to a valid OTel severity level (1-24), and ensures traceId and spanId are 32-character and 16-character hex strings respectively. If validation fails, the harness should log the raw output, the validation errors, and the input context before retrying or routing to a dead-letter queue.

A concrete implementation pattern uses a three-stage pipeline: generate, validate, repair-or-escalate. Stage one calls the model with the prompt template, injecting the raw incident context, current trace context, and the expected output schema. Stage two runs a JSON Schema validator against the OTel event data model, plus custom checks for field correlation (e.g., timestamp must not be in the future, severityText must match severityNumber). If validation passes, the event is forwarded to your collector or SIEM. If it fails, stage three invokes a repair prompt that receives the original input, the invalid output, and the specific validation errors, asking the model to fix only the failing fields. After one repair attempt, if the output still fails validation, the harness logs the failure with full context and alerts a human operator rather than silently dropping the event. For high-throughput environments, add a circuit breaker that stops retries if the failure rate exceeds 5% in a rolling window.

Model choice matters here. Use a model with strong JSON mode or structured output support (e.g., GPT-4o with response_format, Claude with tool-use forcing). Avoid models that cannot guarantee valid JSON under load. For latency-sensitive SRE workflows, consider a smaller fine-tuned model that has been trained on your specific event schema. Always log the model_id, prompt_version, trace_id, and latency_ms alongside every generation attempt so you can correlate prompt performance with production incidents. Never send raw model outputs directly to your observability backend without validation—one malformed severityNumber can break downstream alerting rules or dashboards.