Standardmäßig ist der Prompt ausgewählt, der zuerst die Quelle prüft. Sie können zu einem direkten Befehl wechseln oder eine lokale Kopie herunterladen.
Quelldateien prüfen
Lesen Sie SKILL.md und alle von SkillsMP angezeigten Begleitdateien, bevor Sie sich für eine Installation entscheiden.
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Ein direkter Befehl überspringt den Prüf-Prompt. Prüfen Sie die Quelle, bevor Sie ihn ausführen.
Version: 1.0.0
Last Updated: 2026-06-19
Applicability: Claude Code Skills
Core Standard: This skill implements Observability Standards. For the authoritative methodology (full Metrics/Traces detail, sampling, OTel integration), refer to the core standard.
Guide observability implementation across the three pillars: Logs, Metrics, and Traces.
引導三支柱可觀測性實作:Logs、Metrics、Traces。
Capabilities | 功能
Capability
Description
說明
Instrumentation Check
Pre-launch observability checklist
上線前可觀測性檢查表
Maturity Assessment
L0-L4 maturity self-evaluation
L0-L4 成熟度自評
Metric Design
Help design metrics (type, naming, labels)
協助設計 Metrics
Alert Design
Design SLO-based alerts with noise reduction
設計 SLO-based 告警
Golden Signals
Verify 4 golden signals coverage
驗證四大黃金信號覆蓋
Usage | 使用方式
/observability # Show observability guide
/observability --checklist # Run instrumentation checklist
/observability --maturity # Maturity assessment (L0-L4)
/observability --alerting # Alert design guide
/observability "payment-service"# Guide for specific service
Three Pillars Framework | 三支柱框架
Each pillar gives a different lens; their power is in correlation.
Pillar
What It Captures
When to Use
Granularity
Logs
Discrete events with context
Debugging, audit trails, error details
High (per-event)
Metrics
Numerical measurements over time
Dashboards, alerting, capacity planning
Low (aggregated)
Traces
Request flow across services
Latency analysis, dependency mapping
Medium (per-request)
Correlation fields: trace_id links Logs ↔ Traces ↔ Metrics (via Exemplars);
service.name filters all three pillars. Workflow: metric anomaly → exemplar →
trace → trace_id in logs.
Golden Signals | 四大黃金信號
Based on Google SRE. Every service SHOULD monitor all four before production.
Signal
Measure
Example Metric
Alert (SLO-based)
Latency
P50/P95/P99 via Histogram, split success/error
http.server.request.duration.seconds
P99 > X ms for 5 min
Traffic
Requests/sec, by route/method
http.server.request.total (rate)
drop > 50% or spike > 200%
Errors
errors / total requests
...request.total{status=~"5.."} ÷ total
error rate > X% for 5 min
Saturation
CPU/mem/pool/disk utilization
system.cpu.utilization (Gauge)
resource > 80% for 10 min
Metric Types | Metric 型別
Type
Behavior
Use When
Counter
Only goes up (resets on restart)
request count, error count, bytes sent
Gauge
Point-in-time, up/down
queue depth, active connections, memory
Histogram
Distribution across buckets
request duration, response size
Summary
Client-computed percentiles
legacy, no server-side aggregation
Naming: <domain>.<entity>.<action>.<unit> in snake_case (e.g.
db.client.query.duration.seconds). Label cardinality: keep labels under
~1000 unique values — never use user_id / request_id / raw url / ip as
labels; record those in Logs or Traces instead.
Maturity Model (L0–L4) | 成熟度模型
Level
Name
Characteristics
Upgrade Action
L0
No Observability
only stdout/stderr; debug via SSH + tail -f
structured logging; centralize collection
L1
Basic Logging
structured JSON logs, centralized, searchable
add business metrics; first dashboard
L2
Metrics-Driven
Logs + Metrics, dashboards, threshold alerts
enable tracing; SLO-based alerting
L3
Full Observability
three pillars + correlation + SLO alerts + Golden Signals