一键导入
observability-and-monitoring
Design logging, metrics, tracing, and alerting that make systems debuggable in production
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
菜单
Design logging, metrics, tracing, and alerting that make systems debuggable in production
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Build UIs that work for all users including keyboard navigation, screen readers, and WCAG 2.2
Design multi-agent systems with robust tool interfaces, state management, and failure handling
Build ML systems with disciplined training, evaluation, deployment, and safety practices
Design APIs that are stable, ergonomic, and evolvable
Design systems at the right scale with explicit trade-off documentation
Design services that are reliable, observable, secure, and maintainable
| name | observability-and-monitoring |
| description | Design logging, metrics, tracing, and alerting that make systems debuggable in production |
| difficulty | senior |
| domains | ["general"] |
A system you cannot observe is a system you cannot debug. Observability is not a dashboard — it is the ability to answer any question about system behavior using existing data, without deploying new code. This skill implements the three pillars (logs, metrics, traces) and the alerts that page you before users notice.
/ship workflowSLI (Service Level Indicator): what you measure — latency, error rate, availability, throughput. SLO (Service Level Objective): the target — "p99 latency < 500ms," "error rate < 0.1%."
Without SLOs, you don't know when to alert.
Implement the four golden signals for every service:
Add business metrics: active users, signups, payments, key conversions.
/healthz — is the service alive?/readyz — is the service ready to accept traffic?Alert on symptoms (user impact), not causes (CPU high):
Do NOT alert on:
Every alert must have a runbook.
Build one dashboard per service with:
For each alert: what does it mean, what is the likely cause, what are the first 3 debugging steps, what is the escalation path?
"We'll add monitoring after we know what's important to monitor" By the time you know what's important to monitor, you've already had the incident that taught you.
"Logs are enough — we don't need metrics" Logs tell you what happened. Metrics tell you what is happening right now at scale.