Kubernetes Event Log Prompt for Cluster Observability

This prompt is for platform engineers and SREs who need to convert raw Kubernetes cluster observations—such as error messages, kubectl describe output, or alert payloads—into structured, machine-readable event records. The primary job-to-be-done is standardizing heterogeneous signals into a consistent schema (namespace, resource kind, reason, involved object) that can be ingested by observability platforms, SIEMs, or custom controllers. The ideal user is an engineer building an AI-assisted triage or logging pipeline who needs every output to survive automated validation before it lands in a time-series database or event router.

Use this prompt when you have a stream of unstructured or semi-structured cluster telemetry and you need to normalize it against the core Kubernetes Event schema (apiVersion: v1, kind: Event, involvedObject, reason, message, source, metadata). It is appropriate for post-processing alerts from tools like Prometheus Alertmanager, parsing kubectl output in a chatbot, or enriching incident timelines. Do not use this prompt for generating raw metrics, for real-time control-loop decisions where latency is critical, or for creating audit logs that require cryptographic non-repudiation. It is a normalization and structuring tool, not a replacement for an admission controller or audit sink.

Before using this prompt, ensure you have the raw input text and any available context such as the cluster name, source component, or a trace ID. The prompt is designed to be wired into a validation harness that checks for required fields (namespace, name, kind, reason), valid timestamps, and controlled vocabularies for type (Normal/Warning) and reason. If the validation fails, the harness should retry with a repair prompt or escalate for human review. Start by testing with a small set of known Kubernetes events to calibrate the model's field extraction accuracy before scaling to production traffic.

This prompt template is designed to convert raw Kubernetes event data—whether extracted from kubectl get events, monitoring tools, or incident narratives—into a structured, machine-readable format. It enforces the standard Kubernetes Event schema, including fields like namespace, involvedObject, reason, and type, ensuring the output is immediately ingestible by observability platforms, custom controllers, or audit systems. The template uses square-bracket placeholders for all variable components, allowing you to swap in your specific event source, desired output format, and any additional constraints without altering the core instruction logic.

textCopy
You are an expert Kubernetes event formatter. Your task is to convert the provided raw event data into a single, valid JSON object that strictly conforms to the Kubernetes Event schema.

## Input Data
[RAW_EVENT_DATA]

## Output Schema
You must produce a JSON object with the following fields. Do not include any additional fields.
- `apiVersion`: String, always "v1"
- `kind`: String, always "Event"
- `metadata`: Object containing:
  - `name`: String, a unique name for the event, typically in the format "[resource-name].[event-hash]"
  - `namespace`: String, the namespace of the involved object
  - `uid`: String, a generated UUID for the event
  - `creationTimestamp`: String, an RFC 3339 timestamp for when the event occurred
- `involvedObject`: Object containing:
  - `kind`: String, the kind of the involved resource (e.g., "Pod", "Deployment")
  - `namespace`: String, the namespace of the involved resource
  - `name`: String, the name of the involved resource
  - `uid`: String, the UID of the involved resource, if known
  - `apiVersion`: String, the API version of the involved resource
  - `resourceVersion`: String, the resource version of the involved resource, if known
- `reason`: String, a short, machine-readable reason for the event (e.g., "Started", "FailedScheduling", "Unhealthy")
- `message`: String, a human-readable description of the event
- `source`: Object containing:
  - `component`: String, the component that generated the event (e.g., "kubelet", "default-scheduler")
  - `host`: String, the hostname of the node where the event originated, if known
- `firstTimestamp`: String, an RFC 3339 timestamp for the first occurrence of this event
- `lastTimestamp`: String, an RFC 3339 timestamp for the last occurrence of this event
- `count`: Integer, the number of times this event has occurred
- `type`: String, must be one of "Normal" or "Warning"
- `eventTime`: String or null, an RFC 3339 timestamp for the event in the new events API
- `reportingComponent`: String or null, the component that reported the event in the new events API
- `reportingInstance`: String or null, the instance of the reporting component

## Constraints
[CONSTRAINTS]
- All timestamps must be in RFC 3339 format (e.g., "2023-10-26T10:30:00Z").
- The `type` field must be exactly "Normal" or "Warning".
- If a piece of information is not available in the [RAW_EVENT_DATA], use `null` for optional fields or generate a reasonable default for required fields like `metadata.name` and `metadata.uid`.
- Do not invent event details. Base your output strictly on the provided input.
- Ensure the output is a single, valid JSON object with no surrounding text or markdown fences.

## Examples
[EXAMPLES]

## Risk Level
[RISK_LEVEL]

To adapt this template, replace the placeholders with your specific context. [RAW_EVENT_DATA] should contain the unstructured or semi-structured event information. [CONSTRAINTS] can be used to add domain-specific rules, such as requiring a specific source.component or enforcing a controlled vocabulary for reason. The [EXAMPLES] placeholder is critical for few-shot learning; provide 1-3 examples of raw input paired with the correct JSON output to guide the model's behavior. The [RISK_LEVEL] placeholder allows you to inject a directive for high-stakes environments, such as "If the event type cannot be reliably determined from the input, output a JSON object with an error field instead of guessing." After generating the output, you must validate it against the Kubernetes Event schema using a JSON Schema validator in your application harness before ingestion.

This prompt is designed to be called by an automated controller, not directly by a human operator. The typical integration point is a Kubernetes operator, a webhook receiver, or an observability pipeline stage that receives raw or semi-structured events (e.g., from kubectl get events -o json, a notification webhook, or a log shipper) and needs to normalize them into a strict, validated schema before writing to a central log store. The application harness should treat the LLM call as a normalization and enrichment step, not as a primary event source. The input to the prompt should be a single raw event object or a small batch of events, and the output must be validated against the Kubernetes Event schema conventions before any downstream ingestion.

A robust harness starts with a schema validator. After the model returns the structured JSON, the application must check: (1) metadata.namespace and metadata.name are present and non-empty; (2) involvedObject.kind and involvedObject.name are present; (3) type is one of Normal or Warning; (4) reason is a non-empty string matching the expected PascalCase convention; (5) firstTimestamp and lastTimestamp are valid RFC3339 strings; and (6) the count field is a positive integer. If validation fails, implement a retry loop with a repair prompt (see the Output Repair and Validation Prompts pillar) that feeds the raw event and the specific validation error back to the model for correction. Limit retries to 2 attempts before logging the failure and routing the raw event to a dead-letter queue for manual review. For model choice, a low-latency model like claude-3-haiku or gpt-4o-mini is sufficient for this structured normalization task; reserve larger models for complex enrichment scenarios where the raw message field requires deep reasoning to extract the correct reason and action fields.

Logging and observability of the harness itself are critical. Every LLM call should emit a span with the prompt version, model used, input event UID, output event UID, validation status, and latency. If the output passes validation, write the normalized event to the target sink (e.g., Elasticsearch, Loki, or a cloud SIEM) with the source field set to ai-normalizer and a trace ID that links back to the original raw event. Never allow unvalidated model output to bypass the validator and land directly in the observability store. For high-severity clusters, consider adding a human approval gate for Warning events that match critical resource kinds (e.g., Node, PersistentVolume) before they trigger automated alerts. This prevents a model hallucination from paging an on-call engineer.