システム内の障害点を特定する方法を理解したところで、トラブルシューティング プロセスの次の層に進みます。チームのアプリをサポートする基盤となるインフラストラクチャに問題があると通知されたとします。「ホスト データを使用したアプリの障害の診断」のスキルを構築して、リソースの割り当てを決定できるようにデータを比較する 1 つの方法を学びます。
目的
このチュートリアルでは、次の方法を学習します。
- CPU 使用率が高いアラートホストのトラブルシューティング
- リソース割り当てについてデータに基づいた決定を下す
CPU の突然のスパイクを調査する
リソースに問題があるかどうかを判断する
停止の性質について追加のコンテキストがないと仮定します。最初のステップは、変更をリソースに関連付けることができるかどうかを判断することです。概要ページから開始して、CPU、メモリ使用量、ディスク使用量などのリソース関連データを評価します。
このスクリーンショットを例として使用すると、次のことが推測できます。
host-tower-portland重大なアラート インシデントが発生しました。概要テーブルから、CPU が 99.84% で高温で動作していることがわかります。
メトリクス グラフは、この動作が少なくとも 30 分間継続していることを示しています。
この動作は予期しないものであるため、その特定のホストをさらに詳しく調べる必要があります。
データを関連付けます
ホストをクリックすると、そのホストに固有のデータを含む新しい概要ページが表示されます。この段階では、概要ページから特定されたパターンについて詳しく説明しようとしています。CPU の割合を host-tower-portlandに固有の他のデータと関連付けることができるかどうかを見てみましょう。
CPU の割合を扱っているので、問題がアプリ関連かマシン関連かを判断する必要があります。 そのためには、サイドバーのProcesses runningテーブルをLatest eventsと比較する必要があります。 このステップでは、マシンに直接変更が加えられたために問題が発生しているのか、プロセスがリソースを使い果たしているせいで問題が発生しているのかを明確にします。
このスクリーンショットに基づくと、次のようになります。
CPU 使用率は上昇しており、100% 近くで横ばいになっています。
過去 30 分間 (変更が最初に発生した頃) にイベントは報告されませんでした。イベントのレポートがあった場合は、マシンの構成ファイルに変更があるかどうかを探すか、誰かがマシンに入って直接変更を加えたかどうかを確認することになります。
rubyプロセスが CPU の 77.34% を使用しています。CPU の割合とプロセスを関連付けたので、問題がホスト自体に起因するものではなく、アプリがリソースを占有していると結論付けることができます。
そのアプリにより多くのリソースを割り当てる必要があるかどうかを判断する
リソース関連の問題は、必ずしもソリューションがより多くのリソースをプロビジョニングすることを意味するわけではありません。CPU 使用率が高くなる理由はたくさんありますが、主な理由は次の 2 つです。
アプリが冗長なプロセスを実行しているため、CPU の使用率が急上昇しています。この場合は、そのアプリの最適化について所有チームに連絡する必要があります。
より多くのエンドユーザーがそのコンポーネントにアクセスし、システムにストレスを与えています。この場合、その負荷を満たすためにより多くのリソースをプロビジョニングする必要があります。
host-tower-portlandの概要ページを見ると、さまざまなグラフ間の時系列パターンを相関させることで、どのシナリオがこの状況に当てはまるかを特定できます。 ネットワーク トラフィックをインフラストラクチャ メトリックと比較してみましょう。この場合、
Network traffic
グラフは、CPU 使用率、メモリ使用率などのメトリクス グラフと同様の傾向を示すことが予想されます。
リソースが負荷ではなくアプリの問題に関連している場合、ネットワークの時系列は通常どおりの傾向を示し、急上昇や急降下は見られません。
ただし、負荷が CPU 使用率の高さの原因である場合は、ネットワークの時系列が他のメトリック グラフ全体の傾向を反映していることに気付くでしょう。
CPU usageとNetwork trafficを比較してみましょう。
システムに負荷がかかっている場合、ネットワーク トラフィックはメトリクス グラフと同様の増加を示します。
また、ピークの後、時間の経過とともにトラフィックがゆっくりと減少していることに気づく場合もあります。これは、リソースが不足し、それらのプロセスが停止するためです。つまり、利用可能なリソースが需要をサポートできない場合、ネットワーク トラフィックがスロットルされ、着実に減少する可能性があります。
ただし、ネットワーク トラフィックは一貫した動作を示しています。 リソースが枯渇しても、全体的な動作は時間の経過とともに変化しないようです。 代わりに、時系列には定期的なピークと谷が示されます。
これは、アプリが負荷に対応するためにより多くのリソースを必要としているのではなく、実際にはアプリに問題があることを示しています。
この場合、追加のリソースをアプリに割り当てませ ん 。代わりに、所有チームに連絡して、問題のある Ruby プロセスを最適化することを推奨してください。
チームと共有する
他のチームに提案するときは、全員に同じデータを見てもらいたいと考えます。これにより、潜在的な変更に対する意思決定が、トラブルシューティングで使用されたものと同じデータに基づいて行われることが保証されます。
前の手順では、フィルター クエリを適用して、問題に関連する特定のホストのセットを表示しました。これにより、概要ページのデータが更新され、他のチーム用に保存できます。
他のチームが仕事をするために必要なデータ量を判断します。おそらく、考慮すべきホストのセットが存在するか、サンプル データの 1 つのスライスのみが必要である可能性があります。
関連するデータのみを表示するフィルターを作成します。わかりやすくするために、保存されたビューにはフィルター
hostname = host-tower-portlandからの 1 つのホストが含まれています。もう 1 つの可能性は、アプリ名、またはアラート ステータスでフィルタリングすることです。ビューに名前を付けて、 Saveをクリックします。
データ ビューを作成したら、そのビューを保存して、他のチームが検索できるようにします。独自のアプリの動作のトラブルシューティングを行う場合、ドロップダウンを検索してビューを見つけることができます。
次は何ですか？
これまで、インフラストラクチャ データを使用してリソース関連のインシデントのトラブルシューティングを行う方法について説明してきました。数千のホストからホストのセットまで範囲を絞り、データを関連付けて意思決定を行う方法について説明しました。次のドキュメントでは、インフラストラクチャ メトリックを使用してカスタム ダッシュボードを作成する方法を示します。