菜单
Explains observability patterns for web applications including logs, metrics, traces, client error reporting, correlation IDs, SLOs, and alert design. Use when debugging production issues, designing telemetry, or deciding what signals to collect from frontend and backend systems.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Explains design system patterns including design tokens, component layers, API design, accessibility defaults, theming, documentation, and governance. Use when structuring a reusable component system, defining tokens and variants, or deciding how teams should build and evolve shared UI.
Explains browser storage patterns including cookies, localStorage, sessionStorage, and when to use each. Use when deciding how to persist client-side data, handle auth/session concerns, or choose safe storage patterns for preferences, drafts, and browser state.
Explains error handling patterns in web applications including error boundaries, retries, recovery UX, normalized error shapes, graceful degradation, and observability hooks. Use when designing how applications should fail, recover, and communicate problems to users.
Explains web performance patterns including Core Web Vitals, network and JavaScript cost, rendering and hydration work, lazy loading, caching, and performance budgets. Use when diagnosing slow pages, improving user-perceived speed, or deciding which optimization strategy matters most.
Explains testing strategy for modern web applications including unit, integration, component, end-to-end, contract, accessibility, visual, and performance testing. Use when deciding what to test at each layer, choosing modern testing tools, designing CI quality gates, or improving confidence without creating a slow and brittle test suite.
[TODO: Complete and informative explanation of what the skill does and when to use it. Include WHEN to use this skill - specific scenarios, file types, or tasks that trigger it.]
| name | observability-patterns |
| description | Explains observability patterns for web applications including logs, metrics, traces, client error reporting, correlation IDs, SLOs, and alert design. Use when debugging production issues, designing telemetry, or deciding what signals to collect from frontend and backend systems. |
Observability is how you understand what a system is doing in production.
It answers questions like:
Observability is not just logging. It is the combined use of:
| Signal | Best For | Weakness |
|---|---|---|
| Logs | Detailed event context | High volume, harder to aggregate |
| Metrics | Trends, rates, latency, alerting | Lose per-event detail |
| Traces | Following one request across services | More setup and sampling tradeoffs |
| Error reporting | Grouping crashes and exceptions | Misses non-crash degradation |
Good observability uses all of them together instead of expecting one signal to answer every question.
Logs record discrete events with contextual fields.
Useful examples:
{
"level": "error",
"message": "Payment authorization failed",
"requestId": "req_123",
"userId": "user_42",
"route": "/checkout",
"statusCode": 502
}
Structured logs are better than free-form text because they can be filtered, grouped, and correlated reliably.
Metrics show how the system behaves over time.
Common metric families:
Averages often hide user pain.
Example:
That usually means many users are fine while a meaningful minority are having a bad experience.
Tracing follows one request or user action across system boundaries.
This is especially useful when:
User click
-> browser request
-> edge middleware
-> app server
-> database query
-> cache lookup
-> third-party API
Traces help answer not just "what failed?" but "where in the chain did time or failure accumulate?"
Error reporting is a specialized signal for exceptions, crashes, and grouped failures.
For web applications, useful sources include:
Error reporting is strongest when each event includes:
Frontend systems need observability too, not just backend services.
Important client-side signals:
Important backend signals:
Backend telemetry should make it easy to distinguish:
Correlation IDs connect signals across layers.
Examples:
Without correlation IDs:
With them, you can move from:
Instrument user flows and system boundaries first.
Good starting points:
Avoid starting with hyper-granular internal events that generate noise without helping diagnosis.
A practical baseline is to watch these:
Examples:
These are often the fastest path to spotting active incidents.
Observability is most useful when tied to user experience, not just system internals.
Examples:
This helps separate:
Alerts should be actionable, not just noisy.
If an alert does not tell someone what to investigate next, it is probably not a good alert.
Dashboards are for fast situational awareness.
Useful dashboard slices:
Dashboards should help answer:
Telemetry is not free.
Common tradeoffs:
Avoid unbounded metric labels like:
Those are usually better as log fields, not metric dimensions.
| Anti-Pattern | Why It Hurts |
|---|---|
| Logging everything | Expensive and hard to query |
| Metrics without labels or ownership | Hard to act on |
| Alerts on raw noise | Pager fatigue |
| Error events without release/version | Hard to connect to deployments |
| Frontend blind spots | Backend looks healthy while users are failing |
| No correlation IDs | Investigation becomes guesswork |
A practical workflow:
Good observability shortens this loop.
Use this rough mapping:
performance-patterns for user-perceived speed and Core Web Vitalsmiddleware-patterns for request logging and cross-cutting server instrumentationtesting-strategies-patterns for catching failures before productionrealtime-patterns for connection health and delivery guarantees