Observability taste — промпт для ChatGPT: правила инструментирования
Набор правил для ИИ-ассистента: как расставлять трейсы, метрики и логи в сервисе, чтобы потом не гадать по дашбордам. Пригодится, когда просите модель написать код с телеметрией.
Открыть на GitHubЧто делает Observability taste
Промпт задаёт ассистенту позицию по observability. Инструментировать предлагается через OpenTelemetry, а вендорские SDK держать как экспортёры, а не как API, который вы вызываете в коде. Логи — структурный JSON со стабильной схемой: level, msg, service, trace_id. Свободные строки отпадают.
Дальше идут правила по сигналам. trace_id и span_id попадают в каждую строку лога, поэтому логи и трейсы сходятся сами. Для сервисов берутся RED-метрики (rate, errors, duration), для ресурсов — USE (utilization, saturation, errors). Кардинальность держат под контролем: идентификаторы пользователей и сырые URL в метки не идут. Спаны называют по единице работы — http.server, db.query, queue.publish, а не по именам внутренних функций.
Есть и то, что легко упустить. Секреты, токены, пароли и тела запросов с персональными данными в логи не пишутся — это повод проверить свою текущую схему логирования. SLO описываются с error budget, алерты вешаются на burn rate, а не на каждый скачок CPU. Трейсы в продакшене сэмплируются head-based, но ошибки и медленные запросы сохраняются всегда. В CI добавляется smoke-запрос, который проверяет, что спан и строка лога действительно появились. Промпт текстовый, работает в диалоге с ChatGPT или Claude.ai — ничего ставить не нужно.
Какие задачи решает
- свести логи и трейсы по общему идентификатору
- выбрать метрики для сервиса и для ресурсов
- удержать кардинальность меток от взрыва
- настроить алерты на burn rate вместо сырых порогов
- проверить в CI, что инструментирование живо
Примеры запросов агенту
- Настрой observability в этом сервисе по правилам: OpenTelemetry, структурные JSON-логи, trace_id в каждой строке.
- Проверь мой код логирования — не утекают ли туда токены и тела запросов с персональными данными.
- Предложи SLO с error budget и алерты на burn rate для этого API.
Как установить Observability taste
Как использовать
Вставьте текст в начало диалога или в инструкции проекта
Вручную: положить файлы
.claude/commands/prompts.csv.mdИз того же набора73
Весь набор →Похожие
Рядом в теме «DevOps и инфраструктура»
Все промпты по теме «DevOps и инфраструктура» →Вопросы о Observability taste
Как установить Observability taste в ChatGPT?
Отдельной установки нет: это текстовый промпт, его вставляют в начало диалога или в системную инструкцию.
Что делает Observability taste?
Задаёт ассистенту набор правил по трейсам, метрикам и логам: OpenTelemetry как основа, структурный JSON, RED и USE метрики, контроль кардинальности, SLO с error budget.
Чем это отличается от обычной просьбы «добавь логи»?
Промпт фиксирует конкретные требования: схему полей лога, имена спанов по единице работы, сэмплирование с сохранением ошибок и медленных запросов, smoke-проверку инструментирования в CI.
Исходный текст
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
