go-observability — скилл для Claude Code: логи, трейсы, метрики Go
Скилл для Go-сервисов: помогает настроить структурные логи на log/slog, трейсы и метрики через OpenTelemetry, а также алерты по SLO. Пригодится, когда сервис уже в проде и нужно видеть, что в нём происходит.
npx skills add eduardo-sl/go-agent-skills --skill go-observability -a claude-codeЧто делает go-observability
Скилл задаёт правила для четырёх сигналов наблюдаемости. Логи пишутся парами ключ-значение через log/slog, логгер передаётся как зависимость, а не берётся из глобальной переменной. Для трейсов — спаны на каждую операцию, ctx протягивается по всей цепочке, ошибки помечаются через span.RecordError и span.SetStatus. Метрики именуются по схеме <namespace>_<subsystem>_<name>_<unit>, метки держат в узких рамках: ID пользователя или сырой путь в лейблах быстро раздувают число временных рядов.
Внутри — основной файл SKILL.md и четыре справочника, которые подгружаются по необходимости: references/slog.md про хендлеры и редактирование чувствительных полей, references/tracing.md про провайдер и сэмплирование, references/metrics.md про определения и HTTP-инструментацию, references/alerting.md про RED/USE и burn-rate. Отдельный раздел про связку сигналов: обёртка хендлера добавляет trace_id и span_id в каждую запись, иначе лог не склеить с запросом.
Для работы нужен тулчейн Go: скилл вызывает go и gofmt. По умолчанию он уступает правилу проекта или конфигу агента, которое явно его переопределяет. Профилирование через pprof, обработка ошибок и health-эндпоинты сюда не входят — под них в наборе есть отдельные скиллы.
Какие задачи решает
- перевести логи с форматированных строк на структурные пары ключ-значение
- протянуть trace context через все вызовы и не потерять родительский спан
- выбрать между histogram и summary для метрики задержки
- настроить алерты по burn rate вместо порогов на отдельные метрики
- убрать пароли и персональные данные из логов через
slog.LogValuer
Примеры запросов агенту
- Добавь структурные логи в этот Go-сервис через
log/slog, логгер передавай как зависимость - Расставь спаны OpenTelemetry на входящие запросы и вызовы базы
- Заведи метрику задержки HTTP-запросов и подскажи, какие бакеты поставить вокруг порога SLO
Как установить go-observability
1Через Skills CLI (Vercel)
npx skills add eduardo-sl/go-agent-skills --skill go-observability -a claude-code2Вручную: положить файлы
~/.claude/skills/go-observability/SKILL.mdПапка скилла целиком; для одного проекта — .claude/skills/go-observability/
1Через Skills CLI (Vercel)
npx skills add eduardo-sl/go-agent-skills --skill go-observability -a codex2Вручную: положить файлы
.agents/skills/go-observability/SKILL.mdДля всех проектов — ~/.agents/skills/
1Через Skills CLI (Vercel)
npx skills add eduardo-sl/go-agent-skills --skill go-observability -a cursor2Вручную: положить файлы
.cursor/skills/go-observability/SKILL.mdCursor читает и .agents/skills/, и .claude/skills/
1GitHub CLI
gh skill install eduardo-sl/go-agent-skills go-observability2Вручную: положить файлы
.github/skills/go-observability/SKILL.md1Через Skills CLI (Vercel)
npx skills add eduardo-sl/go-agent-skills --skill go-observability -a gemini-cli2Командой платформы
gemini skills install https://github.com/eduardo-sl/go-agent-skills --path 'skills/(safety)/go-observability'Вручную: положить файлы
.devin/skills/go-observability/SKILL.mdСтарый путь .windsurf/skills/ тоже читается
Через Skills CLI (Vercel)
npx skills add eduardo-sl/go-agent-skills --skill go-observability -a opencodeClaude.ai
Упакуйте папку в zip и загрузите в Settings → Capabilities → Skills
По шагам, с командами для каждой платформы: Как установить скилл в Claude Code: пять способов
Вопросы о go-observability
Как установить go-observability в Claude Code?
Выполните npx skills add eduardo-sl/go-agent-skills --skill go-observability -a claude-code. Скилл появится в ~/.claude/skills/go-observability/SKILL.md.
Что делает go-observability?
Описывает, как в Go-сервисе настроить структурные логи, распределённые трейсы, метрики и алерты по SLO. Отдельно объясняет, как связать логи с трейсами через trace_id.
Чем go-observability отличается от go-performance-review?
Этот скилл про логи, трейсы, метрики и алерты. Профилирование через pprof, обработка ошибок и health-эндпоинты вынесены в другие скиллы набора.
Исходный текст
SKILL.md · MIT
---
name: go-observability
description: >
Structured logging, distributed tracing, metrics, and health checks for Go
services. Covers slog, OpenTelemetry, Prometheus, and observability best
practices. Use when: "add logging", "structured logs", "add tracing",
"OpenTelemetry", "add metrics", "Prometheus", "observability", "instrument
this code".
Not for: pprof profiling (go-performance-review), error handling
(go-error-handling), health endpoints (go-api-design).
user-invocable: true
license: MIT
compatibility: Designed for Claude Code or similar AI coding agents working on Go projects. Requires the Go toolchain.
allowed-tools: Read Edit Write Glob Grep Bash(go:*) Bash(gofmt:*)
metadata:
author: eduardo-sl
version: "1.5.1"
---
# Go Observability
Observability is not optional for production services. Every service must produce
structured logs, expose metrics, and propagate trace context. Use the stdlib
`log/slog` for logging and OpenTelemetry for tracing and metrics.
> Community default. A project skill or agent-config rule that explicitly
> supersedes `go-observability` takes precedence over this one.
Detailed reference material, loaded on demand:
- `references/slog.md` — handler setup, logger injection, child loggers,
`LogValuer` redaction, trace-ID handler, hot paths, runtime levels.
- `references/tracing.md` — tracer provider, spans, propagation, sampling,
profile labels, shutdown.
- `references/metrics.md` — metric definitions, HTTP instrumentation.
- `references/alerting.md` — RED/USE, histograms vs summaries, burn-rate
alerts, alert hygiene, exemplars.
Read a reference file only when the section below is not enough.
## 1. Structured Logging with slog
Use `log/slog` (Go 1.21+) with a JSON handler in production. Every line is
key-value pairs, never a formatted sentence:
```go
// ✅ Good — structured, leveled
logger.Info("user created", slog.String("user_id", user.ID), slog.Duration("latency", elapsed))
// ❌ Bad — unparseable in production
log.Printf("user %s created in %v", user.ID, elapsed)
```
Inject the logger as a dependency; never reach for a package-level global.
Derive child loggers with `logger.With(...)` so component, method and request
ID are attached once instead of at every call site. See `references/slog.md`.
### Log levels — use them consistently
| Level | Use for |
|---|---|
| `Debug` | Verbose diagnostic info, disabled in production |
| `Info` | Normal operations: request received, job completed |
| `Warn` | Recoverable issues: retry succeeded, deprecated usage |
| `Error` | Failures requiring attention: DB down, external call failed |
NEVER log at Error level for expected conditions (user not found → Info or Warn).
### Sensitive data — NEVER log
- Passwords, tokens, API keys
- Full credit card numbers, SSNs
- Personal identifiers: email addresses, phone numbers, IP addresses
where they identify a person
- Raw request bodies containing PII
```go
// ✅ Good — an opaque internal ID, no personal data
logger.Info("auth attempt", slog.String("user_id", userID), slog.Bool("success", ok))
// ❌ Bad — leaks a credential and a personal identifier
logger.Info("auth attempt", slog.String("password", password))
logger.Info("auth attempt", slog.String("user", email))
```
Log the stable internal ID and join to personal data in the system that is
allowed to hold it. Log retention, search access and third-party log sinks
rarely meet the bar that applies to the user table.
Make redaction a property of the type: implement `slog.LogValuer` on
secrets and on structs that hold personal data, so `slog.Any(user)` logs
only the safe fields everywhere.
### Cost and control
- Hot paths use `logger.LogAttrs` and guard expensive attributes with
`logger.Enabled`.
- A `slog.LevelVar` in `HandlerOptions` lets the level change at run time
without a deploy.
- `slog.NewMultiHandler` (Go 1.26+) fans out to several handlers.
## 2. Distributed Tracing with OpenTelemetry
Start a span for every operation worth seeing on a waterfall — inbound
requests, DB calls, outbound HTTP, meaningful business steps — and always
`defer span.End()`.
Rules the reference examples follow:
- Name the span after the operation (`GetUser`, `db.query`), never after the
fully-qualified function, and never `doStuff`.
- On failure call `span.RecordError(err)` and `span.SetStatus(codes.Error, ...)`,
or the trace shows a green span for a failed request.
- Pass `ctx` down the whole chain. A `context.Background()` mid-chain silently
starts a new trace and breaks the parent link.
- Sample with `ParentBased(TraceIDRatioBased(r))` so services agree on a
trace; keep errors and slow requests with tail sampling in the collector.
- Profiles are the fourth signal: continuous profiling in production, with
bounded `pprof.Labels` (route, tenant tier) to split a hot function.
Setup and examples in `references/tracing.md`.
## 3. Metrics with OpenTelemetry / Prometheus
| Type | Use for | Example |
|---|---|---|
| Counter | Monotonically increasing values | Requests total, errors total |
| Gauge | Values that go up and down | Active connections, queue depth |
| Histogram | Distribution of values | Request latency, response size |
Naming is `<namespace>_<subsystem>_<name>_<unit>`:
```text
http_request_duration_seconds ✅ (unit in name)
http_requests_total ✅ (counter with _total suffix)
db_connections_active ✅ (gauge, no suffix needed)
user_signups ❌ (missing _total for counter)
requestLatency ❌ (camelCase, no unit)
```
Keep cardinality bounded. Label with the route pattern, method and status —
never a user ID, request ID or raw `r.URL.Path`, each of which mints a new
time series per value and eventually takes the metrics backend down.
Definitions and middleware in `references/metrics.md`.
## 4. Connecting Logs, Traces, and Metrics
A log line without a trace ID cannot be joined to the request that produced
it. Wrap the handler once so every `*Context` log call adds `trace_id` and
`span_id` from `ctx` — the wrapper must also override `WithAttrs` and
`WithGroup`, or child loggers lose it. Attach exemplars (trace IDs) to
latency histograms to jump from a p99 spike to an offending trace.
## 5. Alerting and SLOs
- Measure RED (rate, errors, duration) per route for services and USE
(utilization, saturation, errors) for pools and queues.
- Latency is a **Histogram**, never a Summary — summary quantiles cannot be
aggregated across instances. Put buckets around the SLO threshold.
- Page on SLO **burn rate** over a long and a short window together; send
slower burns to a ticket.
- Alert on symptoms, not causes; `rate()` not `irate()`; `absent()` for
series that must exist; a runbook link on every page.
Queries and exemplar wiring: `references/alerting.md`.
## 6. Graceful Shutdown of Telemetry
The batch span processor holds spans in memory. Call `tp.Shutdown(ctx)` with
its own timeout on the way out, or the last seconds before a crash — the
interesting ones — never reach the collector.
Both examples in `references/tracing.md`.
## Verification Checklist
1. All logging uses `log/slog` with structured key-value pairs, not `fmt.Printf` or `log.Printf`
2. Logger is injected as a dependency, not used as a global
3. No sensitive data (passwords, tokens, PII) in log output
4. Trace context is propagated through all function calls via `context.Context`
5. Spans are created for significant operations (DB calls, HTTP requests, business logic)
6. Spans record errors with `span.RecordError(err)` and set error status
7. Metrics follow naming conventions: `_seconds`, `_total`, `_bytes`
8. No high-cardinality labels (user IDs, request IDs) in metrics
9. Telemetry providers are shut down gracefully on service exit
10. Trace IDs are included in log entries for correlation
11. Latency recorded as histograms; paging alerts are SLO burn-rate alerts with runbooks
© eduardo-sl · MIT · eduardo-sl/go-agent-skills