Implementation Guide

企業はどのようにして観察可能性プラットフォームを構築できるのでしょうか?

観察可能性の構築は「複数のツールを接続する」ことから始めるのではなく、コアとなるビジネスチェーンや高頻度のインシデントから始めるべきです。まず、メトリクス、ログ、リンク、RUM、Kubernetes、クラウドリソース、ビジネスメトリクスを統合し、その後、サービス、リソース、バージョン、チーム、ビジネスオブジェクトに関する持続可能なトラブルシューティングプロセスを確立します。

統一された観測可能な計画を見る選考チェックリストを見る

Direct Answer

まずは事故の連鎖を作り、工具リストからではなく

観測可能性プラットフォームを構築する際、企業はログイン、注文、支払い、コアAPI、Kubernetesクラスター、データベース、主要なサードパーティ依存関係から始めることを推奨しています。目標はすべての監視ツールを一度に置き換えることではなく、まず高価値システムに継続的なトラブルシューティング能力を持たせることです。

実際の構築経路には、統一された収集とタグ付け、サービスオブジェクトとリソースオブジェクト間の関係性の確立、インシデントシナリオを中心としたビューの整理、アラートとイベント応答のクローズドループ、レビューやナレッジベースの蓄積、そして最終的にはより多くのビジネスラインへの段階的な拡大が含まれます。

Foundation

観測可能なプラットフォームを構築する前に準備すべきことは何でしょうか?

コアビジネスチェーンリスト

ログイン、注文、支払い、クエリ、プッシュ、決済などの主要なリンク、さらにAPIゲートウェイ、アプリケーションサービス、データベース、キャッシュ、メッセージキュー、各リンクに関わるサードパーティ依存関係を明確に定義してください。

統一ラベリング基準

サービス、環境、バージョン、チーム、リージョン、ホスト、ポッド、クラスター、ビジネスなどのタグは事前に統一しておくべきです。そうしないと、その後の指標、ログ、リンク、アラートの関連付けが難しくなります。

既存のツールとデータソース

Prometheus、ELK、SkyWalking、OpenTelemetry、クラウドベンダーコンソール、ログコレクター、ビジネスモニタリングシステムをレビューし、どれを保持しどれにアクセスするかを決定してください。

警報および対応手順

アラートの評価、業務規則、責任者、アップグレード経路、レビューメカニズムを明確にし、問題解決を促さずに観測可能なプラットフォームが新たなクエリエントリーポイントになるのを防ぎます。

Roadmap

観測可能なプラットフォーム建設の5段階

統一コレクション
DataKit、OpenTelemetry、Prometheus、ログ収集、クラウドベンダー統合、オープンAPIを通じて、メトリック、ログ、リンク、RUM、イベント、ビジネスメトリクスへのアクセスが可能です。
統一ターゲット
サービス、ホスト、ポッド、コンテナ、データベース、クラウドリソース、バージョン、チーム、ビジネスオブジェクトに関する関係を確立し、単一のアラートで関連証拠をさらに掘り下げることができます。
統一シーン
インターフェースの遅さ、エラー率の増加、Podの再起動、ページ体験の劣化、異常ログ、ビジネス指標の異常など、高頻度のトラブルシューティングシナリオを優先的に処理しましょう。
統一応答
異常検出、アラーム通知、イベント管理、責任割り当て、記録処理、レビューを同じプロセスに統合し、繰り返されるアラームや情報のギャップを減らします。
継続的な統治
タグ付け、サンプリング、ログ保持、権限、脱感作、コスト、SLOを継続的に最適化し、観測可能なプラットフォームを長期的な安定性プロジェクトの一部にします。

Team View

異なるチームは可観測性を構築する際に何に注力していますか?

チーム問題に集中しましょうプラットフォームが提供すべき機能

研究開発遅延リクエスト、エラースタック、依存関係のボトルネック、リリース回帰 APMトレース、プロファイリング、ログ関連、バージョン比較、コードレベルの手がかり

SRE / 運用・保守資源水位、警報音、故障影響、回復経路インフラ監視、Kubernetesイベント、アラート収束、イベント応答、SLO

プラットフォームチームデータ収集、権限ガバナンス、データ保持、アクセスに関する統一標準 DataKit、OpenTelemetry、統一タグ、パイプライン、権限、匿名化、コストガバナンス

ビジネスチーム取引の影響、体験の減少、コンバージョンの異常、顧客からの苦情ビジネス指標、RUMの実ユーザーエクスペリエンスモニタリング、ダッシュボード、ビジネスインパクト分析

観測可能なプラットフォーム建設の計画を継続してください

オブザーバビリティプラットフォームとは

観測可能性プラットフォームの定義、データタイプ、従来の監視との違い、選定基準を理解しましょう。

プラットフォーム監視と従来型監視の違い

なぜチームが従来の監視から観測性プラットフォームへアップグレードする必要があるのかを明らかにしてください。

観測可能性プラットフォーム選択のチェックリスト

実際のインシデントチェーン、データカバレッジ、ガバナンスコスト、チームコラボレーションの基準を評価するプラットフォームを利用すること。

フルリンク監視プラットフォームと観測可能性プラットフォームの違い

トレース、ログ、メトリクス、RUM、Kubernetes、ビジネスデータがどのように完全なトラブルシューティングチェーンを形成しているのかを明確にしてください。

観測可能プラットフォームと統合監視

Guanceメトリクス、ログ、リンク、RUM、Kubernetes、ビジネスデータを統合する方法をご覧ください。

650+の技術スタックとデータ統合

DataKit、OpenTelemetry、Prometheus、クラウドサービス、主流技術スタックのアクセス機能について探ります。

価格とバージョン

データスケール、展開方法、保持サイクル、チーム要件評価バージョンと請求方法を組み合わせています。

FAQ

よくある質問

企業はどこから観測可能性プラットフォームを構築し始めるべきでしょうか?

ログイン、注文、支払い、コアAPI、Kubernetesクラスター、データベースなどのコアビジネスチェーンや高頻度障害シナリオから始め、その後、収集、タグ付け、アラート、トラブルシューティングのための統一プロセスを構築することが推奨されます。

観測可能なプラットフォームを構築するには、既存の監視ツールを置き換える必要がありますか?

必ずしもそうとは限りません。ほとんどの企業は、Prometheus、ELK、SkyWalking、OpenTelemetryなどの既存のコレクションやローカルツールを保持しつつ、コンテキスト、権限、アラートクローズドループ、長期的なガバナンスをオブザーバビリティプラットフォームを通じて統一できます。

観察可能なプラットフォームを構築する際、最も失敗しやすい場所はどこでしょうか?

共通の失敗は、統一されたタグやオブジェクト関係、応答プロセスなしでデータのみにアクセスすることで、チームはツール間で手動で証拠を組み合わせる必要があり、故障のローカライズやコラボレーションコストを真に削減することが不可能です。

統一監視プラットフォームの構築と観測可能なプラットフォームの構築の関係は何でしょうか?

統一監視プラットフォームの構築は通常、最初のステップであり、指標、ログ、リンク、アラートを集中管理するために用いられます。観察可能なプラットフォームの構築は、オブジェクト関係の補完、探索・分析、ビジネスインパクト、チームの協働、クローズドループのレビューを引き続き行う必要があります。

観測可能性の構築の効果はどのように測定されるのでしょうか?

効果はMTTR、アラートノイズ、繰り返し故障率、コアリンクの可用性、リリースロールバック数、ログ保存コスト、チーム間のコラボレーション時間、SLO達成度などで測定できます。