システムが完全に装備されると、システム インフラストラクチャとインフラストラクチャがサポートするアプリの間でデータを関連付けることができます。ただし、さまざまなアプリにリソースを割り当てている数千の顔の見えないホストがある可能性があります。どこで何が起こっているのか完全なコンテキストを把握していない可能性があるため、関連するデータを見つけるのは大変なことです。アプリケーションが失敗するインフラストラクチャ関連の原因を見つけるために、すべてのデータをどのように分類しますか?
目的
このドキュメントでは、インフラストラクチャ UI 内で関連データを見つける方法について説明します。あなたはするであろう：
- インフラストラクチャ データを属性でフィルタリングする
- 追加のコンテキストなしで特定のホストとアプリを識別する
- タイムピッカーを使用して変更がいつ発生したかを確認します
ホストデータを調査して、停止の原因を特定します。
障害が発生したホストを特定する
開始方法がわからない場合は、最初に合計重大度でホストの範囲を限定することをお勧めします。 概要ページの概要を使用すると、システムで 3 つの重大なアラートインシデントが発生していることがわかります。
フィルター バーを使用すると、これら 3 つの重要なアラートに関するデータのみを表示できます。この場合、クエリは alertSeverity = 'CRITICAL'となり、83 のホストからの集計データの範囲が 3 つに絞り込まれます。
をまだ設定していない場合は、いつでも概要テーブルをホスト メトリックで並べ替えることができます。 たとえば、ホストに障害が発生している兆候はないが、問題について通知されたとします。
- 集計表の名前列をクリックします。昇順または降順で並べ替えることができます。
- スクリーンショットでは、CPU 使用率でホストを並べ替えており、CPU が 99.84% の
host-tower-portlandが最上位に表示されています。 - 必要に応じて、メモリ使用量やストレージ使用量などに対して同じプロセスを繰り返します。異常な動作のパターンが見つかるまで繰り返します。
- 時間があるときに、重要なしきい値に対するアラートを作成することを検討してください。
アプリ名でフィルタリングする
インシデントに関連するホストを特定したら、クリックしてそのホストに関するデータのみを表示できます。このシナリオでは、 apache-svr01を選択しました。アプリ関連の問題を解決しようとしているので、ホストのページのサービス マップから始めます。このマップには、選択したホストに依存するアプリが表示されます。
apache-svr01 スコープのビューから、2 つのアプリがこのホストに依存していることがわかります。1つは警告しています。
この場合、アプリ Orders team が失敗したアプリです。
インフラストラクチャの概要ページに戻ると、クエリを更新できます。まだアラートを出していない場合でも、このアプリに関連するすべてのホストを評価したいと考えています。パートナー セットのコンテキストで問題のホストを表示すると、アプリの失敗の原因についての理解が深まります。たとえば、他のホストがしきい値に近づいているか、他のホストに対するアラートを作成していない可能性があります。
フィルタ バーを調整して、 Orders team アプリに関連するホストを表示します。クエリは apmApplicationNames = Orders teamになるはずです。
このフィルタにより、インシデント半径が最初の apache_svr01 ホストを超えて広がりましたが、データの範囲は引き続き関連セットに限定されました。ここから、どのようなリソース制限がパフォーマンスに影響を与えているかをさらに深く掘り下げることができます。
- これらのホストのうちの 2 つだけがアラートを発しているため、すべてのホストに影響を与える潜在的なデータベースの問題を除外できます。
- 代わりに、[システム]、[ネットワーク]、[プロセス]、[ストレージ]、または [Docker] コンテナーのタブをさらに詳しく調べることもできます。このシリーズの次のドキュメントでは、データの動作を比較および相関させる方法について説明します。
時間ピッカーを調整して、変更が最初に発生した時間を確認します
タイムピッカーを調整すると、時間の経過とともにデータがどのように変化したかを確認できます。このアクションにより、変更が最初に発生したときを追跡できます。3 時間前と 6 時間前の間で切り替わるこれらのメトリクス グラフを見てみましょう。
6 時間時点の時系列では、ディスク使用率の明らかな増加は見られません。3 時間のパラメーターに切り替えると、動作が変化し始めたおおよその時間を確認できます。メトリクス グラフは、スパイクやドロップが発生したときの視覚的な手がかりを提供します。
予期しない負荷の増加があった場合、
Events
タイルには予想されるイベントが多数表示されるか、または予想よりも少ないイベントが表示されます。
Alerts
タイルには、現在クリティカルまたは警告閾値でアラートを発しているホストの数が表示されます。 時間の経過とともにアラートが着実に増加している場合は、変更によってインシデントの動作がエスカレートしたことを示している可能性があります。
タイルとメトリック グラフは、インシデントのおおよその時間を三角測量するのに役立ちます。これは、インシデントの原因が外部ベンダーからのアップデートまたは別のチームからの展開によるものである場合に特に役立ちます。そうであれば、さらに深く掘り下げるための次のステップも変わってくるでしょう。
次は何ですか？
インフラストラクチャ データを評価して、障害が発生しているアプリを特定する方法を紹介しました。概要ページから始めると、ホストのパフォーマンスが時間の経過とともにどのように変化するかを概観し、障害のあるアプリをサポートしているホストを特定できます。
しかし、インフラストラクチャ データをどのように使用してリソースの割り当てを決定するのでしょうか?次のドキュメントでは、CPU 高使用率のトラブルシューティングなど、より具体的なインシデントをさらに詳しく調べる方法について説明します。