データを使用してリソースを決定する

リソースに問題があるかどうかを判断する

停止の性質について追加のコンテキストがないと仮定します。最初のステップは、変更をリソースに関連付けることができるかどうかを判断することです。概要ページから開始して、CPU、メモリ使用量、ディスク使用量などのリソース関連データを評価します。

このスクリーンショットを例として使用すると、次のことが推測できます。

• host-tower-portland 重大なアラート違反があります。

• 概要テーブルから、CPU が 99.84% で高温で動作していることがわかります。

• メトリクス グラフは、この動作が少なくとも 30 分間継続していることを示しています。

  この動作は予期しないものであるため、その特定のホストをさらに詳しく調べる必要があります。

データを関連付けます

ホストをクリックすると、そのホストに固有のデータを含む新しい概要ページが表示されます。この段階では、概要ページから特定されたパターンについて詳しく説明しようとしています。CPU の割合を host-tower-portlandに固有の他のデータと関連付けることができるかどうかを見てみましょう。

ここでは CPU の割合を扱っているため、問題がアプリに関連しているのか、マシンに関連しているのかを判断したいと考えています。これを行うには、サイドバーの Latest events [最新のイベント] に対して Processes running [プロセス実行] テーブルを確認します。このステップでは、マシンに直接変更が加えられたために問題が発生しているのか、それともプロセスがリソースを使い果たしているのかを明確にします。

このスクリーンショットに基づくと、次のようになります。

• CPU 使用率は上昇しており、100% 近くで横ばいになっています。

• 過去 30 分間 (変更が最初に発生した頃) にイベントは報告されませんでした。イベントのレポートがあった場合は、マシンの構成ファイルに変更があるかどうかを探すか、誰かがマシンに入って直接変更を加えたかどうかを確認することになります。

• ruby プロセスが CPU の 77.34% を使用しています。

  CPU の割合とプロセスを関連付けたので、問題がホスト自体に起因するものではなく、アプリがリソースを占有していると結論付けることができます。

そのアプリにより多くのリソースを割り当てる必要があるかどうかを判断する

リソース関連の問題は、必ずしもソリューションがより多くのリソースをプロビジョニングすることを意味するわけではありません。CPU 使用率が高くなる理由はたくさんありますが、主な理由は次の 2 つです。

• アプリが冗長なプロセスを実行しているため、CPU の使用率が急上昇しています。この場合は、そのアプリの最適化について所有チームに連絡する必要があります。

• より多くのエンドユーザーがそのコンポーネントにアクセスし、システムにストレスを与えています。この場合、その負荷を満たすためにより多くのリソースをプロビジョニングする必要があります。

  host-tower-portlandの概要ページを見ると、異なるチャート間の時系列パターンを相関させることで、この状況にどのシナリオが当てはまるかを特定できます。ネットワーク トラフィックをインフラストラクチャのメトリクスと比較してみましょう。

• この場合、 Network traffic [ネットワーク トラフィック] グラフが CPU 使用率、メモリ使用量などのメトリック グラフと同様の傾向を示すことが期待されます。

• リソースが負荷ではなくアプリの問題に関連している場合、ネットワーク時系列は通常の傾向、つまり急増や谷のない傾向になります。

• ただし、負荷が CPU 使用率の高さの原因である場合は、ネットワーク時系列が他のメトリック グラフ全体の傾向を反映していることに気づくでしょう。

  CPU usage [CPU 使用率] と Network traffic [ネットワーク トラフィック]を比較してみましょう。

  

• システムに負荷がかかっている場合、ネットワーク トラフィックはメトリクス グラフと同様の増加を示します。

• また、ピークの後、時間の経過とともにトラフィックがゆっくりと減少していることに気づく場合もあります。これは、リソースが不足し、それらのプロセスが停止するためです。つまり、利用可能なリソースが需要をサポートできない場合、ネットワーク トラフィックがスロットルされ、着実に減少する可能性があります。

• ただし、ネットワーク トラフィックは一貫した動作を示しています。リソースが枯渇しても、全体的な動作は時間の経過とともに変化するようには見えません。代わりに、時系列には規則的な山と谷が表示されます。

• これは、アプリが負荷に対応するためにより多くのリソースを必要としているのではなく、実際にはアプリに問題があることを示しています。

  この場合、追加のリソースをアプリに割り当てませ ん 。代わりに、所有チームに連絡して、問題のある Ruby プロセスを最適化することを推奨してください。

チームと共有する

他のチームに提案するときは、全員に同じデータを見てもらいたいと考えます。これにより、潜在的な変更に対する意思決定が、トラブルシューティングで使用されたものと同じデータに基づいて行われることが保証されます。

前の手順では、フィルター クエリを適用して、問題に関連する特定のホストのセットを表示しました。これにより、概要ページのデータが更新され、他のチーム用に保存できます。

1. 他のチームが仕事をするために必要なデータ量を判断します。おそらく、考慮すべきホストのセットが存在するか、サンプル データの 1 つのスライスのみが必要である可能性があります。

2. 関連するデータのみを表示するフィルターを作成します。わかりやすくするために、保存されたビューにはフィルター hostname = host-tower-portlandからの 1 つのホストが含まれています。もう 1 つの可能性は、アプリ名、またはアラート ステータスでフィルタリングすることです。

3. ビューに名前を付けて、 Save [保存]をクリックします。

   

   

   データ ビューを作成したら、そのビューを保存して、他のチームが検索できるようにします。独自のアプリの動作のトラブルシューティングを行う場合、ドロップダウンを検索してビューを見つけることができます。