What this prompt does
This prompt makes the model wire full observability into a Spring Boot 3 service, returning copy-ready config and code rather than pseudocode. It covers all three pillars — metrics, traces, and logs — and, most importantly, correlates them so a log line carries the trace and span IDs that join it to the matching trace. That correlation is the single biggest debugging win when the first incident hits and you need to pivot from a log entry to the full request.
The [app_name] variable tags the service across all telemetry. [metrics_backend] is where Micrometer metrics are scraped or stored, [trace_backend] is where OpenTelemetry spans are exported, and [log_backend] is where structured logs ship. Naming each one lets the model wire the right exporters and registries instead of a generic setup. The output enables Prometheus metrics with useful tags, OTel tracing with sampling guidance, JSON logging that injects traceId and spanId, and a sample instrumented controller showing a custom Timer or Counter and a manually started span.
When to use it
- Standing up a new Spring Boot 3 service that needs metrics, traces, and logs from the start.
- Adding correlated logs-to-traces so you can jump from a log line to its trace.
- Configuring Micrometer with a Prometheus registry and consistent service/env/version tags.
- Wiring OpenTelemetry span export with sane production sampling.
- Bootstrapping starter dashboards and alerts for latency p95, error rate, and JVM heap.
- Instrumenting a hot endpoint with a custom metric and a manual span.
Example output
You get the full application.yaml plus an annotated controller and any dependency snippets. The yaml enables Micrometer metrics with a Prometheus registry and tags for service, env, and version; configures OTel tracing exporting to [trace_backend] with prod sampling guidance; and sets up structured JSON logging injecting traceId and spanId into every line. The sample @RestController shows a custom Timer/Counter and a manually started span. A short dashboard/alert starter list covering p95 latency, error rate, and heap rounds it out. It's a runnable observability setup, not fragments.
Pro tips
- Never skip the correlated logging (deliverable 3) — joining logs to traces via traceId/spanId is the single biggest debugging win when an incident hits.
- Set sampling low in production or the trace volume — and bill — quietly explodes; the prompt's sampling guidance is there for a reason.
- Name
[trace_backend],[metrics_backend], and[log_backend]precisely so the exporters target the right systems instead of placeholders. - Keep the service/env/version tags consistent across services so dashboards can filter and compare cleanly.
- Use a clear
[app_name]since it tags every metric, trace, and log line and becomes your primary filter dimension. - Start from the suggested p95-latency, error-rate, and heap alerts rather than inventing dashboards from scratch.
