web-dev-qa-db-ja.com

サーバーを監視する場合、どのメトリックを監視する必要がありますか？

私はたくさんの監視ツールを見ましたが、ほとんど同じことを示しています。しかし、これらすべてを監視することが本当に必要かどうか疑問に思います。

たとえば、PHP-FPM、Nginx、MySQLを使用して主にWebサイトを実行するWebサーバーなど、どのメトリックが本当に重要かを知りたいです。

また、私はグラフィックスを調べていますが、将来の障害を防ぐためにグラフィックスを理解して分析する方法はありますか？

monitoringmetrics
4
yvan

重要な指標は次のとおりです。

  • 提供するサービスの正しく適切な操作に問題があることを示します。または
  • 問題の根本原因を示してください

どのメトリックが重要であるかは、専門家の意見では、これら2つの基準を最もよく満たすメトリックであると判断するものによって異なります。事前に正確に判断できる専門知識がない場合は、 ええと...ええ 。必要がない可能性のあるデータをさらに収集する方が、後で必要になることが判明したデータを収集しないよりも優れています。 （注意点として、監視がサービスの効率的な運用を妨げ始めている場合は、サービスを少し下げるか、統計収集を最適化する必要があります）。

ショートカットの答えを探しているのなら、私には答えがないのではないかと思います。あなたは、システム管理者であることの意味の核心を物語る急な学習曲線に乗っています。ダウンタイムが問題にならない状況にある場合は、すばらしいです。あなたは自分自身に素晴らしい学習の機会を持っています。このサービスが完全に実行されない場合に訴えられたり廃業したりすることになった場合は、1対1のガイダンスとメンタリングを提供する経験豊富な人を見つけることをお勧めします。

5
womble

私はちょうどこの主題に関するガイドを書き、公開しました：

ここで要約させてください。あらゆる種類の本番システムを監視する際に考慮すべき3つの主な目標があります。

  1. できるだけ多くの問題を特定します。
  2. これらの問題をできるだけ早く特定します。そして
  3. 誤警報をできるだけ少なくする（つまり、適切なアラートを設定する）

そして、次のフレームワークの下でメトリックを選択することによってこれを行いたいと思います。

  1. 潜在的な悪いことを監視する（couldうまくいかないこと-これは多くの場合、いっぱいになる/なくなるものの形である-つまり、メモリ、ディスク、帯域幅）
  2. 実際の悪いことを監視する（最善の努力にもかかわらずdoうまくいかないこと）
  3. 良いことを監視する（またはその欠如-起こりたいことに注意を払い、発生頻度が低いときにアラートを設定する
  4. 調整と改善（そうしないと、「泣いているオオカミ」に相当するDevOpsとして知られる「アラート疲労」のリスクがあります）

YMMVのように、すべての展開は少し異なりますが、これは、経験豊富なプロの多くが物事について考えるために使用するフレームワークです（明示的かどうかは関係ありません）。

[開示のために編集：私はこの分野に関与している会社であるScalyrと提携しており、上記のリンクは彼らのサイトに公開されています]

3
nlh

最も基本的なのは、CPU負荷、空きメモリとスワップ、ディスクスペース、ディスクI/O、およびネットワーク/帯域幅I/Oの量を監視することです。これは、muninやcollectdなどのツールを使用して実行できます。 lotのことを監視するのが好きな人もいますが、少なくともそれを単純に保つと、全体像を把握できます。また、問題が発生し始めたときに電子メールアラートを送信するように監視ツールを構成することをお勧めします（つまり、「しきい値」などを使用します）。

もう1つの非常に便利なことは、エラーメッセージや警告など、異常なものがないか、最も重要なサーバーログを監視することです。ただし、このようなメッセージは、さまざまなソフトウェアがログに記録するように構成されている方法によっては非常に一般的です。通常、デーモンには、「LogLevel」をエラー（=何かが壊れたときにのみログを記録する）からデバッグ（=何かをログに記録する）に変更できる構成ファイルがあります。サーバーで実行しているデーモンを確認し、ログレベルをエラーまたは警告に変更します。次に、OSSECなどのログファイル分析ツールをインストールし、特定の問題が許容できる場合はサイレントになるようにトレーニングし、問題が発生した場合は警告を発するようにトレーニングします。これらのアラートは、電子メールで送信できます。

特定のサービスNginxおよびMysqlについては、それらの応答時間を監視することをお勧めします。これには2つの理由があります。まったく応答がない場合、何かが壊れています。また、応答時間が異常に長いことを示す応答が表示された場合（特に、一時的ではなく、数分または数時間以上の場合）、サービスは問題を抱えています。

1
öde

Collectdをご覧になることをお勧めします。後で分析するために、多数の測定値をRRDファイルに記録するように構成できます。必要なCPUはごくわずかであり、負荷によってパフォーマンスがどのように変化するかを理解するのに役立ちます。

生成されたRRDから実際にグラフを描画するための本当に素晴らしいツールは見つかりませんでしたが、実際にグラフを投影する場合を除いて、コマンドラインでrrdgraphを使用するだけで、大きな変更を定期的にチェックできます。

0
Bittrance

上記の優れたアドバイス。ただし、本当に始める必要がある場合は、最初に基本事項を確認してください。時間の経過に伴うCPU使用率、時間の経過に伴うメモリ使用量、帯域幅の使用量、ディスク容量の使用量（または空きディスク容量）です。これらの4つは、コンピューターの機能をほぼ定義しているため、非常に一般的です。

しばらく監視し、サーバーの「正常」が何であるかを理解すると、何かが異常であるかどうかを見つけることができます。それはあなたがより深く掘り下げ始めて「なぜ」を見つける準備ができているときです-それは追加のより具体的な監視を必要とします:)

0
DougN