スキル observability-engineer
📊

observability-engineer

安全

本番環境のオブザーバビリティシステムを設計

このスキルは、エンタープライズアプリケーション向けの包括的なモニタリング、ログ、トレーシングシステムの設計と実装を支援します。SLI/SLO 管理、分散トレーシング、インシデント対応ワークフローに関する専門的なガイダンスを提供します。

対応: Claude Codex Code(CC)
🥉 74 ブロンズ
1

スキルZIPをダウンロード

2

Claudeでアップロード

設定 → 機能 → スキル → スキルをアップロードへ移動

3

オンにして利用開始

テストする

「observability-engineer」を使用しています。 1 日 10 万件の注文を処理するチェックアウトサービスのモニタリング戦略を設計

期待される結果:

  • メトリクス収集：注文スループット、レイテンシパーセンタイル（p50、p95、p99）、タイプ別エラーレートのレコーディングルールを含む Prometheus をデプロイ
  • 主要ダッシュボード：Grafana でエグゼクティブ概要、運用リアルタイム、トラブルシューティングドリルダウンビューを作成
  • アラート：p99 レイテンシ > 2 秒、エラーレート > 1%、チェックアウト成功率 < 99% のアラートを設定
  • トレーシング：10% のトレースサンプリングとエラーのフルトレーシングを含む OpenTelemetry 自動インストルメンテーションを実装
  • ログ：トレースとの相関関係のため、注文 ID、ユーザー ID、レイテンシを含む構造化 JSON ログ

「observability-engineer」を使用しています。 99.9% の可用性ターゲットを持つ決済 API の SLO を定義

期待される結果:

  • SLI 定義：5 分間のウィンドウで測定された成功した決済リクエスト数 / 総決済リクエスト数
  • SLO：30 日間のローリングウィンドウで 99.9% の成功率 = 43.8 分の許容エラーバジェット
  • エラーバジェットアラート：2 倍（1 日 87.6 分）と 10 倍（1 日 438 分）のしきい値でバーンレートアラート
  • 消費追跡：残りのエラーバジェット、1 日のバーンレート、予測される侵害日を表示するダッシュボード

セキュリティ監査

安全
v1 • 2/24/2026

Prompt-only skill with no executable code. Static analysis scanned 0 files (0 lines) and detected 0 security issues. The skill provides observability engineering guidance through text prompts only. No dangerous patterns, no network requests, no file system access, and no external commands detected. Content describes legitimate monitoring, logging, and tracing system design.

0
スキャンされたファイル
0
解析された行数
0
検出結果
1
総監査数
セキュリティ問題は見つかりませんでした
監査者: claude

品質スコア

38
アーキテクチャ
100
保守性
87
コンテンツ
50
コミュニティ
100
セキュリティ
91
仕様準拠

作れるもの

マイクロサービスモニタリングアーキテクチャの設計

50 以上のサービスを持つマイクロサービスシステム向けの包括的なモニタリング戦略を作成。メトリクス収集、分散トレーシング、アラート機能を含む。

SLI/SLO フレームワークの確立

99.9% の可用性ターゲットとバーンレートモニタリングを備えた API サービス向けに、サービスレベル指標、目標、エラーバジェットを定義。

分散トレーシングの実装

レイテンシのボトルネックを特定し、サービス境界を越えたルート Cause 分析を実行するために、E コマースプラットフォームに分散トレーシングを設定。

これらのプロンプトを試す

基本的なモニタリング設計 
1 日あたり [traffic volume] リクエストを処理する [service type] 向けのモニタリング戦略を設計してください。メトリクス収集、ログアプローチ、アラート推奨を含めてください。
SLI/SLO 定義 
[availability target]% の可用性を持つ [service name] API の SLI と SLO の定義を支援してください。エラーバジェット計算とバーンレートアラートを含めてください。
インシデント対応設定 
[incident type] のインシデント対応ワークフローを作成してください。アラートルーティング、エスカレーション手順、ランブック推奨、事後分析プロセスを含めてください。
コスト最適化 
現在のオブザーバビリティ設定を分析し、コスト最適化戦略を推奨してください。現在 [tools] を使用しており、毎日 [volume] のテレメトリデータを生成しています。

ベストプラクティス

  • ビジネス成果から始める - メトリクスを選択する前に、ユーザーにとって信頼性の高いサービスが何を意味するかを定義する
  • 段階的なインストルメンテーションを実装：まず可視性のためにメトリクス、次にデバッグのためにトレース、そして詳細のためにログ
  • 原因ではなく症状でアラート - 内部コンポーネントが失敗したときではなく、ユーザーが影響を受けたときに通知する

回避

  • あらゆる可能性のある失敗に対してアラートを作成 - アラート疲労と通知の無視につながる
  • 目的なくすべてをモニタリング - コストが増加し、シグナル品質が低下する
  • SLO を厳しすぎに設定 - 不要なストレスとバジェット枯渇を引き起こす

よくある質問

このスキルはどのツールをサポートしていますか？
このスキルは、Prometheus、Grafana、Jaeger、Zipkin、ELK Stack、Loki、DataDog、New Relic、CloudWatch、OpenTelemetry、PagerDuty、および AWS、Azure、GCP 全体のクラウドネイティブモニタリングを含む主要なオブザーバビリティツールをカバーしています。
このスキルはモニタリングインフラをデプロイできますか？
いいえ。このスキルは設計ガイダンス、設定推奨、実装計画を提供します。実際のデプロイには Terraform や Kubernetes などの別のインフラストラクチャツールが必要です。
オブザーバビリティをどのように始めればよいですか？
重要なユーザージャーニーを特定し、信頼性の高いサービスが何を意味するかを定義することから始めます。次に、4 つの黄金のシグナル（レイテンシ、トラフィック、エラー、飽和）のためにインストルメントします。トレースとログは段階的に追加します。
モニタリングとオブザーバビリティの違いは何ですか？
モニタリングは何が間違っているかを教えてくれます。オブザーバビリティはなぜ間違っているかを理解するのに役立ちます。モニタリングにはメトリクスとダッシュボードを、デバッグにはトレースを、深い調査にはログを使用します。
アラートノイズをどのように削減しますか？
アラートグルーピング、重複排除、抑制ルールを使用します。内部コンポーネントの失敗ではなく、ユーザーに影響を与える症状に対してアラートを出します。迅速なトリアージを可能にするために、各アラートにランブックを実装します。
SLI、SLO、エラーバジェットとは何ですか？
SLI はサービスの動作を測定します（例：リクエスト成功率）。SLO は目標とする SLI 値です（例：99.9% の成功率）。エラーバジェットは残りの許容障害時間です。これらを組み合わせることで、データ駆動型の信頼性判断が可能になります。

開発者の詳細

作成者

sickn33

ライセンス

MIT

リポジトリ

https://github.com/sickn33/antigravity-awesome-skills/tree/main/skills/observability-engineer

参照

main

ファイル構成

📄 SKILL.md