메뉴
ロギング、メトリクス、分散トレーシングのオブザーバビリティパターン。以下の場合に使用: - 構造化ロギングの実装 - メトリクスとモニタリングのセットアップ - 分散トレーシングの追加 - ヘルスチェック（liveness、readiness）の実装 - アラートや SLO ベースのモニタリングの設計 Trigger phrases: logging, metrics, tracing, monitoring, health check, alerting, SLO, structured logs, observability
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
設定ファイルとソースコードからプロジェクトの技術スタックを自動検出。 Use when: 新規コードベースでの作業開始、言語/フレームワーク/ツールの特定。 Trigger phrases: detect stack, what framework, identify technology, project setup
REST、GraphQL、gRPC の API 設計パターン。 Use when: API の新規設計、OpenAPI 仕様作成、バージョニング/ページネーション設計。 Trigger phrases: API design, REST endpoint, GraphQL schema, OpenAPI, gRPC, pagination
エバリュエーター・オプティマイザーのフィードバックループによる反復改善。 Use when: 出力品質の反復改善、明確な評価基準がある複雑な出力の最適化。 Trigger phrases: iterate, refine, improve quality, feedback loop, evaluate and optimize
ルール遵守と創造的な問題解決のバランスを取るためのフレームワーク。 Anthropic のエージェント設計に関する研究に基づく。 使用場面: - 複数の有効なアプローチがある複雑な判断に直面した場合 - 状況に対して指示が過度に規範的に感じられる場合 - ガイドラインを特定のコンテキストに適応させる必要がある場合 - 精度要件と革新的なソリューションのバランスを取る場合 Trigger phrases: think creatively, use judgment, adapt approach, better solution, flexibility
曖昧なリクエストを明確にするための構造化された要件インタビューフレームワーク。使用場面: - ユーザー要件が不明確または不完全な場合 - 新機能を開始し要件を収集する必要がある場合 - ユーザーのニーズ、制約、優先順位を理解する必要がある場合 - ビジネスリクエストを技術仕様に変換する場合 - ユーザーが詳細なしに「～したい」「～を追加して」と言う場合 Trigger phrases: gather requirements, clarify request, what do you need, interview user, requirements gathering, unclear request
すべてのユーザー向けコンテンツに日本語出力を強制する。 使用場面: - エージェント出力を日本語にする必要がある場合 - レスポンス全体の言語の一貫性を検証する場合 - 仕様書やドキュメントを日本語で生成する場合 Trigger phrases: Japanese, 日本語, language mode, output language
| name | observability |
| description | ロギング、メトリクス、分散トレーシングのオブザーバビリティパターン。以下の場合に使用: - 構造化ロギングの実装 - メトリクスとモニタリングのセットアップ - 分散トレーシングの追加 - ヘルスチェック（liveness、readiness）の実装 - アラートや SLO ベースのモニタリングの設計 Trigger phrases: logging, metrics, tracing, monitoring, health check, alerting, SLO, structured logs, observability |
| allowed-tools | Read, Glob, Grep, Write, Edit, Bash, WebSearch, WebFetch |
| model | sonnet |
| user-invocable | true |
ロギング、メトリクス、トレーシングを通じてオブザーバブルなシステムを構築するためのスタック非依存パターン。このスキルはコンセプトとパターンを定義するものであり、特定のライブラリ実装を定義するものではない。
デバッグと監査のための構造化されたコンテキスト付きログ。
モニタリングとアラートのための数値測定。
サービス間の分散リクエスト追跡。
適切に構造化されたログエントリは以下を含むべき:
{
"timestamp": "ISO 8601 形式",
"level": "INFO/WARN/ERROR/DEBUG",
"service": "サービス識別子",
"trace_id": "リクエスト追跡用の相関 ID",
"message": "人間が読める説明",
"context": {
"relevant": "コンテキストデータ"
}
}
| レベル | 使用場面 | 例 |
|---|---|---|
| DEBUG | 開発の詳細 | クエリパラメータ、キャッシュヒット |
| INFO | 通常の操作 | ユーザー作成、リクエスト完了 |
| WARN | 潜在的な問題 | リトライが必要、非推奨 API の使用 |
| ERROR | 操作失敗 | データベース接続失敗 |
| FATAL | アプリケーションクラッシュ | 回復不能なエラー |
すべきこと:
すべきでないこと:
ロギングを実装する際:
WebSearch: "[言語] structured logging library [year]"
| タイプ | 使用場面 | 例 |
|---|---|---|
| Counter | 累積値（増加のみ） | リクエスト数、エラー数 |
| Gauge | ポイントインタイム値（増減あり） | アクティブ接続数、キューサイズ |
| Histogram | 値の分布 | リクエストレイテンシー、レスポンスサイズ |
| Summary | 事前計算されたパーセンタイル | p50、p99 レイテンシー |
形式: <namespace>_<name>_<unit>
良い例:
- http_requests_total
- http_request_duration_seconds
- database_connections_active
- queue_messages_waiting
悪い例:
- requests (名前空間なし、単位なし)
- httpRequestDuration (camelCase、不統一)
- request-latency (ハイフン、単位なし)
RED メソッド（リクエスト指向）:
USE メソッド（リソース指向）:
Four Golden Signals:
メトリクスを実装する際:
WebSearch: "[言語] metrics library [year]"
WebSearch: "metrics collection [インフラストラクチャ] [year]"
Trace（リクエスト全体の旅程）
├── Span A: API Gateway（親）
│ ├── Span B: Auth Service
│ └── Span C: User Service
│ └── Span D: Database Query
コンテキスト伝播の標準ヘッダー:
| 標準 | 説明 |
|---|---|
| W3C Trace Context | モダンな標準（traceparent、tracestate） |
| B3 | Zipkin 形式（X-B3-* ヘッダー） |
トレーシングを実装する際:
WebSearch: "distributed tracing [言語] [year]"
WebSearch: "[トレーシングプラットフォーム] integration guide"
// GET /health
{
"status": "healthy|degraded|unhealthy",
"version": "アプリバージョン",
"uptime_seconds": 3600,
"checks": {
"database": {
"status": "healthy",
"latency_ms": 5
},
"cache": {
"status": "healthy",
"latency_ms": 2
},
"external_api": {
"status": "degraded",
"message": "High latency"
}
}
}
| チェック | 目的 | 失敗時のアクション |
|---|---|---|
| Liveness | アプリは動作しているか？ | コンテナを再起動 |
| Readiness | リクエストを処理できるか？ | ロードバランサーから除外 |
| Startup | アプリは起動したか？ | まだ liveness をチェックしない |
良いアラートに含まれるもの:
避けるべきこと:
SLI: 99.9% のリクエストが 200ms 以内に完了
SLO: 30 日間で 99.9% の成功率
エラーバジェット: 0.1% = 約 43 分/月
アラート条件:
- バーンレート > 1x: スローバーン、低重大度
- バーンレート > 10x: ファストバーン、高重大度
セキュリティと運用の安全性に不可欠。
運用品質に重要。適切な理由がある場合はオーバーライド可。
包括的なオブザーバビリティのための推奨事項。