Skip to main content
affpapa.org
RU EN
prompt GP ChatGPT

Observability taste — ChatGPT prompt: tracing and logging rules

A prompt that tells an AI assistant how to wire traces, metrics and logs into a service. Handy when you ask a model to write instrumented code.

Open on GitHub

What Observability taste does

The prompt sets a stance on observability. Instrument with OpenTelemetry first, and treat vendor SDKs as exporters rather than the API you call from application code. Logs are structured JSON on a stable schema: level, msg, service, trace_id. Free-form strings are out.

Then come the signal rules. trace_id and span_id go into every log line, so logs and traces join on their own. Services get RED metrics (rate, errors, duration), resources get USE (utilization, saturation, errors). Cardinality stays under control: user IDs and raw URLs never become metric labels. Spans are named after the work unit — http.server, db.query, queue.publish — not after internal function names.

Some of it is easy to miss. Secrets, tokens, passwords and request bodies with PII stay out of logs, which is a good reason to re-check your current logging setup. SLOs come with error budgets, and alerts fire on burn rate instead of every CPU spike. Production traces are sampled head-based, but errors and slow requests are always kept. A smoke request in CI asserts that a span and a log line actually exist. It is plain text, so it runs in a ChatGPT or Claude.ai conversation with nothing to install.

What it helps with

  • join logs and traces on a shared identifier
  • pick metrics for services and for resources
  • keep metric label cardinality from exploding
  • alert on burn rate instead of raw thresholds
  • assert in CI that instrumentation still works

Example prompts for the agent

  • Instrument this service following the observability rules: OpenTelemetry, structured JSON logs, trace_id on every line.
  • Review my logging code — are tokens or request bodies with PII leaking into it?
  • Propose SLOs with error budgets and burn-rate alerts for this API.

How to install Observability taste

How to use

Paste the text at the start of a chat or into project instructions

From the same set77

The whole set →
Git Workflow taste A prompt that gives an AI assistant trunk-based habits: short-lived branches, Conventional Commits, squash-merge and a protected main. GP ChatGPT ★ 174,597repo stars Monorepo taste A prompt that hands the agent a fixed set of monorepo conventions: pnpm workspaces, Turborepo, package boundaries and shared configs. Useful when repo structure keeps drifting. GP ChatGPT ★ 174,597repo stars Rust CLI taste A prompt that tells the model how to write a Rust command-line tool: argument parsing, error handling, output streams, tests. GP ChatGPT ★ 174,597repo stars React State Management taste A ruleset for picking React state tools: when to use useState, Zustand, Context and TanStack Query. Helps avoid overbuilt global stores and duplicated state. GP ChatGPT ★ 174,597repo stars Python Packaging taste A prompt that hands the model a fixed set of Python packaging rules: pyproject.toml, src/, uv, Ruff. Useful when a new package needs one consistent style. GP ChatGPT ★ 174,597repo stars Open Source Release Checklist Builder (YAML) This prompt turns an upcoming open-source release into a YAML checklist for versions, tests, artifacts, security notes, rollback, and announcements. GP ChatGPT ★ 174,597repo stars Dockerfile and CI taste A prompt that lists rules for Dockerfiles and CI: multi-stage builds, non-root user, image scanning. Useful when you ask an AI to write or review a build config. GP ChatGPT ★ 174,597repo stars Senior Code Reviewer (severity-ranked) A code review prompt that ranks findings from blockers down to nits and closes with a verdict. Useful when you need to know what in a patch actually breaks. GP ChatGPT ★ 174,597repo stars

Similar

observability-and-instrumentation addyosmani Instruments code with structured logs, RED and USE metrics, and distributed tracing. Use it when shipping features to production so issues are diagnosable. CX Codex +1 54,800installs otel-instrumentation dash0 Gives your agent a rulebook for OpenTelemetry spans, metrics and logs, so telemetry answers questions instead of burning budget. CX Codex +1 972installs python-observability Seth Hobson A skill that gives your agent Python observability patterns: structured logging, Prometheus metrics, distributed tracing. Useful when production breaks and the logs don't tell you where. CX Codex 11,547installs golang-observability-opentelemetry Claude MPM Team A skill for instrumenting Go services: OpenTelemetry for distributed tracing, Prometheus for metrics, slog for structured logging. CX Codex +1 409installs cloudflare-workers-observability secondsky A skill for Cloudflare Workers observability: structured logging, Analytics Engine, Tail Workers, metrics and alerting. Useful when a worker fails in production and you can't see why. CX Codex +1 302installs opentelemetry grafana A skill that walks you through instrumenting an app with OpenTelemetry and sending metrics, logs and traces to Grafana Cloud or self-hosted Mimir, Loki and Tempo. CX Codex +1 6,100installs service-mesh-observability Seth Hobson This skill covers service mesh metrics, distributed tracing, and dependency visualization. Use it when setting up mesh monitoring or investigating latency and errors. CX Codex 10,300installs distributed-tracing Seth Hobson This skill sets up distributed tracing with Jaeger and Tempo. Use it to inspect request paths and find latency or failure points across microservices. CX Codex 10,700installs

Nearby in DevOps and infrastructure

All prompts for DevOps and infrastructure →

Questions about Observability taste

How do I install Observability taste in Claude?

There is nothing to install: it is a text prompt you paste at the start of a conversation or into the system instructions.

What does Observability taste do?

It gives the assistant a rule set for traces, metrics and logs: OpenTelemetry as the base, structured JSON, RED and USE metrics, cardinality limits, SLOs with error budgets.

How is it different from just asking to add logging?

The prompt pins down specifics: the log field schema, span names taken from the work unit, head-based sampling that keeps errors and slow requests, and a CI smoke check for instrumentation.

Source text

prompts.csv · CC0-1.0 
# Observability taste
- Instrument with OpenTelemetry first and treat vendor SDKs as exporters, not the API you call. Confidence: 0.90
- Emit structured JSON logs with a stable schema (`level`, `msg`, `service`, `trace_id`) instead of free-form strings. Confidence: 0.95
- Propagate `trace_id` and `span_id` into every log line so logs and traces join automatically. Confidence: 0.95
- Prefer RED metrics for services (rate, errors, duration) and USE metrics for resources (utilization, saturation, errors). Confidence: 0.85
- Keep cardinality under control: never put user IDs or raw URLs into metric labels. Confidence: 0.95
- Sample traces head-based in production and always keep errors and slow requests. Confidence: 0.85
- Name spans after the work unit (`http.server`, `db.query`, `queue.publish`), not after internal function names. Confidence: 0.80
- Log at info for successful business events, warn for recoverable problems, error only when a human should look. Confidence: 0.85
- Never log secrets, tokens, passwords or full request bodies with PII. Confidence: 0.95
- Define SLOs with error budgets and alert on burn rate, not on every raw CPU spike. Confidence: 0.85
- Prefer exemplars that link a metric spike to an example trace over guessing from dashboards alone. Confidence: 0.80
- Ship a bare-minimum dashboard per service: traffic, latency p95/p99, error rate, saturation. Confidence: 0.85
- Include `deployment.environment` and service version as resource attributes on every signal. Confidence: 0.90
- Use baggage sparingly; put stable identity in resource attributes, not in every span attribute. Confidence: 0.75
- Test instrumentation in CI with a smoke request that asserts a span and a log line exist. Confidence: 0.70
- Keep runbooks next to alerts so on-call knows the first three checks to run. Confidence: 0.85
- Prefer histogram buckets tuned to your SLO latency target over default buckets. Confidence: 0.80

© f · CC0-1.0 · f/prompts.chat

See also

Project sponsors

Companies that keep this analytics open
Gold sponsor
Nutra.Club

Impressions, clicks and code copies — open statistics. We keep the numbers public for the same reason NeBlask itself is public. Become a sponsor