observability-monitoring
Structured logging, metrics, distributed tracing, and alerting strategies
下記のコマンドをコピーしてターミナル(Mac/Linux)または PowerShell(Windows)に貼り付けてください。 ダウンロード → 解凍 → 配置まで全自動。
mkdir -p ~/.claude/skills && cd ~/.claude/skills && curl -L -o observability-monitoring.zip https://jpskill.com/download/17248.zip && unzip -o observability-monitoring.zip && rm observability-monitoring.zip
$d = "$env:USERPROFILE\.claude\skills"; ni -Force -ItemType Directory $d | Out-Null; iwr https://jpskill.com/download/17248.zip -OutFile "$d\observability-monitoring.zip"; Expand-Archive "$d\observability-monitoring.zip" -DestinationPath $d -Force; ri "$d\observability-monitoring.zip"
完了後、Claude Code を再起動 → 普通に「動画プロンプト作って」のように話しかけるだけで自動発動します。
💾 手動でダウンロードしたい(コマンドが難しい人向け)
- 1. 下の青いボタンを押して
observability-monitoring.zipをダウンロード - 2. ZIPファイルをダブルクリックで解凍 →
observability-monitoringフォルダができる - 3. そのフォルダを
C:\Users\あなたの名前\.claude\skills\(Win)または~/.claude/skills/(Mac)へ移動 - 4. Claude Code を再起動
⚠️ ダウンロード・利用は自己責任でお願いします。当サイトは内容・動作・安全性について責任を負いません。
🎯 このSkillでできること
下記の説明文を読むと、このSkillがあなたに何をしてくれるかが分かります。Claudeにこの分野の依頼をすると、自動で発動します。
📦 インストール方法 (3ステップ)
- 1. 上の「ダウンロード」ボタンを押して .skill ファイルを取得
- 2. ファイル名の拡張子を .skill から .zip に変えて展開(macは自動展開可)
- 3. 展開してできたフォルダを、ホームフォルダの
.claude/skills/に置く- · macOS / Linux:
~/.claude/skills/ - · Windows:
%USERPROFILE%\.claude\skills\
- · macOS / Linux:
Claude Code を再起動すれば完了。「このSkillを使って…」と話しかけなくても、関連する依頼で自動的に呼び出されます。
詳しい使い方ガイドを見る →- 最終更新
- 2026-05-18
- 取得日時
- 2026-05-18
- 同梱ファイル
- 1
📖 Skill本文(日本語訳)
※ 原文(英語/中国語)を Gemini で日本語化したものです。Claude 自身は原文を読みます。誤訳がある場合は原文をご確認ください。
Observability & Monitoring Skill
構造化ロギング、メトリクス、分散トレーシング、およびアラートを含む、オブザーバビリティを実装するための包括的なフレームワークです。
使用する場面
- アプリケーションの監視を設定する
- 構造化ロギングを実装する
- メトリクスとダッシュボードを追加する
- 分散トレーシングを構成する
- アラートルールを作成する
- 本番環境の問題をデバッグする
オブザーバビリティの3つの柱
┌─────────────────┬─────────────────┬─────────────────┐
│ LOGS │ METRICS │ TRACES │
├─────────────────┼─────────────────┼─────────────────┤
│ いつ、何が │ システムは │ リクエストは │
│ 起こったか │ 時間経過とともに │ どのように │
│ │ どのように │ サービスを │
│ │ 動作しているか │ 流れるか │
└─────────────────┴─────────────────┴─────────────────┘
構造化ロギング
ログレベル
| Level | ユースケース |
|---|---|
| ERROR | 処理されない例外、失敗した操作 |
| WARN | 非推奨の API、リトライの試み |
| INFO | ビジネスイベント、成功した操作 |
| DEBUG | 開発時のトラブルシューティング |
ベストプラクティス
// Good: コンテキスト付きの構造化
logger.info('User action completed', {
action: 'purchase',
userId: user.id,
orderId: order.id,
duration_ms: 150
});
// Bad: 文字列補間
logger.info(`User ${user.id} completed purchase`);
Winston のセットアップとリクエストミドルウェアについては、
templates/structured-logging.tsを参照してください。
メトリクスの収集
RED メソッド (Rate, Errors, Duration)
すべてのサービスに不可欠なメトリクス:
- Rate - 1秒あたりのリクエスト数
- Errors - 1秒あたりの失敗したリクエスト数
- Duration - リクエストのレイテンシ分布
Prometheus Buckets
// HTTP リクエストのレイテンシ
buckets: [0.01, 0.05, 0.1, 0.5, 1, 2, 5]
// データベースクエリのレイテンシ
buckets: [0.001, 0.01, 0.05, 0.1, 0.5, 1]
完全なメトリクス構成については、
templates/prometheus-metrics.tsを参照してください。
分散トレーシング
OpenTelemetry のセットアップ
一般的なライブラリを自動的にインストルメント:
- Express/HTTP
- PostgreSQL
- Redis
手動スパン
tracer.startActiveSpan('processOrder', async (span) => {
span.setAttribute('order.id', orderId);
// ... 処理
span.end();
});
完全なセットアップについては、
templates/opentelemetry-tracing.tsを参照してください。
アラート戦略
重要度レベル
| Level | 対応時間 | 例 |
|---|---|---|
| Critical (P1) | 15分未満 | サービス停止、データ損失 |
| High (P2) | 1時間未満 | 主要な機能の破損 |
| Medium (P3) | 4時間未満 | エラー率の増加 |
| Low (P4) | 翌日 | 警告 |
主要なアラート
| Alert | 条件 | 重要度 |
|---|---|---|
| ServiceDown | up == 0 が 1分間続く |
Critical |
| HighErrorRate | 5xx > 5% が 5分間続く | Critical |
| HighLatency | p95 > 2s が 5分間続く | High |
| LowCacheHitRate | < 70% が 10分間続く | Medium |
Prometheus のアラートルールについては、
templates/alerting-rules.ymlを参照してください。
ヘルスチェック
Kubernetes Probes
| Probe | 目的 | エンドポイント |
|---|---|---|
| Liveness | アプリは実行中か? | /health |
| Readiness | トラフィックを受け入れる準備はできているか? | /ready |
| Startup | 起動は完了したか? | /startup |
Readiness レスポンス
{
"status": "healthy|degraded|unhealthy",
"checks": {
"database": { "status": "pass", "latency_ms": 5 },
"redis": { "status": "pass", "latency_ms": 2 }
},
"version": "1.0.0",
"uptime": 3600
}
実装については、
templates/health-checks.tsを参照してください。
オブザーバビリティチェックリスト
実装
- [ ] JSON 構造化ロギング
- [ ] リクエスト相関 ID
- [ ] RED メトリクス (Rate, Errors, Duration)
- [ ] ビジネスメトリクス
- [ ] 分散トレーシング
- [ ] ヘルスチェックエンドポイント
アラート
- [ ] サービス停止アラート
- [ ] エラー率の閾値
- [ ] レイテンシの閾値
- [ ] リソース使用率のアラート
ダッシュボード
- [ ] サービス概要
- [ ] エラー分析
- [ ] パフォーマンスメトリクス
拡張思考トリガー
Opus 4.5 の拡張思考を以下に使用します:
- インシデント調査 - ログ、メトリクス、トレースの関連付け
- アラートの調整 - ノイズの削減、実際の問題の捕捉
- アーキテクチャの決定 - 監視ソリューションの選択
- パフォーマンスのデバッグ - サービス間のレイテンシ分析
テンプレートリファレンス
| Template | 目的 |
|---|---|
structured-logging.ts |
リクエストミドルウェアを備えた Winston ロガー |
prometheus-metrics.ts |
ミドルウェアを備えた HTTP、DB、キャッシュメトリクス |
opentelemetry-tracing.ts |
分散トレーシングのセットアップ |
alerting-rules.yml |
Prometheus のアラートルール |
health-checks.ts |
Liveness、readiness、startup プローブ |
📜 原文 SKILL.md(Claudeが読む英語/中国語)を展開
Observability & Monitoring Skill
Comprehensive frameworks for implementing observability including structured logging, metrics, distributed tracing, and alerting.
When to Use
- Setting up application monitoring
- Implementing structured logging
- Adding metrics and dashboards
- Configuring distributed tracing
- Creating alerting rules
- Debugging production issues
Three Pillars of Observability
┌─────────────────┬─────────────────┬─────────────────┐
│ LOGS │ METRICS │ TRACES │
├─────────────────┼─────────────────┼─────────────────┤
│ What happened │ How is system │ How do requests │
│ at specific │ performing │ flow through │
│ point in time │ over time │ services │
└─────────────────┴─────────────────┴─────────────────┘
Structured Logging
Log Levels
| Level | Use Case |
|---|---|
| ERROR | Unhandled exceptions, failed operations |
| WARN | Deprecated API, retry attempts |
| INFO | Business events, successful operations |
| DEBUG | Development troubleshooting |
Best Practice
// Good: Structured with context
logger.info('User action completed', {
action: 'purchase',
userId: user.id,
orderId: order.id,
duration_ms: 150
});
// Bad: String interpolation
logger.info(`User ${user.id} completed purchase`);
See
templates/structured-logging.tsfor Winston setup and request middleware
Metrics Collection
RED Method (Rate, Errors, Duration)
Essential metrics for any service:
- Rate - Requests per second
- Errors - Failed requests per second
- Duration - Request latency distribution
Prometheus Buckets
// HTTP request latency
buckets: [0.01, 0.05, 0.1, 0.5, 1, 2, 5]
// Database query latency
buckets: [0.001, 0.01, 0.05, 0.1, 0.5, 1]
See
templates/prometheus-metrics.tsfor full metrics configuration
Distributed Tracing
OpenTelemetry Setup
Auto-instrument common libraries:
- Express/HTTP
- PostgreSQL
- Redis
Manual Spans
tracer.startActiveSpan('processOrder', async (span) => {
span.setAttribute('order.id', orderId);
// ... work
span.end();
});
See
templates/opentelemetry-tracing.tsfor full setup
Alerting Strategy
Severity Levels
| Level | Response Time | Examples |
|---|---|---|
| Critical (P1) | < 15 min | Service down, data loss |
| High (P2) | < 1 hour | Major feature broken |
| Medium (P3) | < 4 hours | Increased error rate |
| Low (P4) | Next day | Warnings |
Key Alerts
| Alert | Condition | Severity |
|---|---|---|
| ServiceDown | up == 0 for 1m |
Critical |
| HighErrorRate | 5xx > 5% for 5m | Critical |
| HighLatency | p95 > 2s for 5m | High |
| LowCacheHitRate | < 70% for 10m | Medium |
See
templates/alerting-rules.ymlfor Prometheus alerting rules
Health Checks
Kubernetes Probes
| Probe | Purpose | Endpoint |
|---|---|---|
| Liveness | Is app running? | /health |
| Readiness | Ready for traffic? | /ready |
| Startup | Finished starting? | /startup |
Readiness Response
{
"status": "healthy|degraded|unhealthy",
"checks": {
"database": { "status": "pass", "latency_ms": 5 },
"redis": { "status": "pass", "latency_ms": 2 }
},
"version": "1.0.0",
"uptime": 3600
}
See
templates/health-checks.tsfor implementation
Observability Checklist
Implementation
- [ ] JSON structured logging
- [ ] Request correlation IDs
- [ ] RED metrics (Rate, Errors, Duration)
- [ ] Business metrics
- [ ] Distributed tracing
- [ ] Health check endpoints
Alerting
- [ ] Service outage alerts
- [ ] Error rate thresholds
- [ ] Latency thresholds
- [ ] Resource utilization alerts
Dashboards
- [ ] Service overview
- [ ] Error analysis
- [ ] Performance metrics
Extended Thinking Triggers
Use Opus 4.5 extended thinking for:
- Incident investigation - Correlating logs, metrics, traces
- Alert tuning - Reducing noise, catching real issues
- Architecture decisions - Choosing monitoring solutions
- Performance debugging - Cross-service latency analysis
Templates Reference
| Template | Purpose |
|---|---|
structured-logging.ts |
Winston logger with request middleware |
prometheus-metrics.ts |
HTTP, DB, cache metrics with middleware |
opentelemetry-tracing.ts |
Distributed tracing setup |
alerting-rules.yml |
Prometheus alerting rules |
health-checks.ts |
Liveness, readiness, startup probes |