一オンスの予防は一ポンドの治療に値する、ということわざがあります。決まり文句ではありますが、ITインフラストラクチャに関しては、この古い格言は非常に真実であることが証明されています。組織の98%が、わずか1時間のダウンタイムで10万ドル以上の損失が発生すると回答していることからも（情報源:
ITIC）、ダウンタイムが発生する前にサーバーのパフォーマンスを監視して予防することが、これまで以上に重要になっています。この記事では、サーバー監視のトピックについて深く掘り下げ、技術的な詳細とベストプラクティスについて議論します。
サーバー監視とは？
サーバー監視とは、サーバーのステータスとパフォーマンスに関するデータをポーリングし、収集する行為です。サーバー監視の目的は、重要なサーバー統計を測定し、サーバーがリソースを効果的に利用していることを確認すること、そして管理者がインフラストラクチャの詳細なビューを得ることで、問題が発生した際に先手を打って対処し、機器が停止した場合には迅速に通知を受けられるようにすることです。
監視は、ネイティブなオペレーティングシステムツール（例:
Windows Performance Monitor）、サードパーティツールおよびスキャナー（例:
Pingdom）、ネットワーク管理システム（NMSes、例:
SolarWindsや
Nagios）、またはアドホックコマンド用のカスタムスクリプトやコマンドラインユーティリティ（例: WMIを使用するPowerShellスクリプトやNet-SNMPを使用するbashスクリプト）を使用して行うことができます。
ネットワーク経由でサーバーを監視するために最も一般的に使用されるプロトコルには、SNMP（Simple Network Management Protocol）、IPMI（Intelligent Platform Management Interface）、WMI（Windows Management Instrumentation）があります。これらのプロトコルに加えて、多くのツールはSSH、FTP、ICMP、DNS、HTTP(S)、RESTful API、ベンダー固有のエージェント、またはその他のプロトコルやサービスに基づいて監視を行うことができます。
エージェントベースとエージェントレスの監視は、サーバー監視においてよく使われる2つの用語です。エージェントベースという用語は、監視を行うためにサーバー上でエージェントが実行されている必要があることを示します。エージェントレスとは、エージェントが不要で、SNMPのような標準プロトコルを監視に使用できることを意味します（ただし、SNMPはマネージャーと「エージェント」モデルに基づいているため、これは厳密には誤称と見なされる可能性があります）。それぞれの方法には長所と短所があり、一般的なトレードオフとしては、エージェントベースの方法はより詳細な情報や機能を提供できる一方、エージェントレスの方法はより軽量で一元化された監視に適しているという点です。このトピックの詳細については、Nagiosの
エージェントベースと
エージェントレスの監視オプションの説明を参照してください。
サーバー監視を設定する際に監視する最も一般的なメトリックには、メモリ、ディスク使用率、ネットワーク、CPU使用率、ping（サーバーが稼働しているか停止しているかを確認するためのICMP）、データベース統計、仮想化統計、電力メトリック、ファンステータス、温度、湿度などがあります。これらの変数は、サーバー監視に関しては氷山の一角に過ぎず、他にも多くの変数を監視でき、ユースケースによってはより具体的な監視が必要になる場合があります。例えば、Webサーバーの場合、HTTPステータスを定期的にチェックすることが必須です（
Uptime Robotはそのための無料ツールの一例です）。一方、MySQLサーバーはエラーログを定期的にチェックする必要があるかもしれませんし、ファイルおよび印刷サーバーは特定のプロセスとサービスの監視からより多くの恩恵を受けるかもしれません。さらに、多くのサーバー監視ツールは、インベントリを追跡し、ITインフラストラクチャ全体のより全体的なビューを得るのに役立ちます。
サーバーのパフォーマンスにどのように良い影響を与えるのか？
サーバー監視を取り巻く2つの大きな指標は、MTTD（平均検出時間）とMTTR（平均解決時間）です。適切に行われたサーバー監視は、この両方を削減し、ミッションクリティカルなサーバーの稼働時間を最大化し（稼働時間の最大化については、弊社の
「サーバーがダウンしていますか？ダウンタイムゼロを実現するためのヒント」をご覧ください）、IT運用をより効率的にします。
特定の環境の要求によってチームが監視する特定の変数は異なりますが、ユースケース全体に共通する点は、監視によってチームがプロアクティブになり、リソース使用率をよりよく理解し、問題が発生したときに迅速に対応できるようになることです。
上述の監視ツールの多くは、通知機能（SMS、メールなど）と自動化機能（しきい値を超えた場合やデバイスがダウンした場合にスクリプトやプログラムを実行する）を提供しており、これらを使用することで、問題への対応と解決をより迅速かつ効率的に行うことができます。これにより、次にウェブサーバーがHTTPリクエストに応答しなくなった場合、担当管理者にすぐに通知されるか、HTTPサービス（例：Apache、nginx、IIS）を再起動するためのスクリプトが実行される可能性があります。同様に、サーバーが事前に定義されたCPU使用率のしきい値を常に超えている場合、チームはアプリケーションのパフォーマンスやユーザーエクスペリエンスの問題になる前に、問題を調査し解決するための措置を講じることができます。
さらに、データを監視・取得することで、そのデータを追跡・報告し、問題が発生する前にトレンドを特定することができます。インフラストラクチャのベースラインパフォーマンスを理解することで、情報に基づいた意思決定によってより効果的にスケーリングし、インフラストラクチャの弱点を特定し、データ駆動型の微調整や最適化によってサーバーパフォーマンスを向上させることができます。
サーバー監視の開始
サーバー監視を開始するには、何を監視すべきか、そしてなぜ監視すべきかを正確に把握するために、いくつかの質問を自問する必要があります。ここでは、それらの質問を定義し、具体的な実行可能な項目に掘り下げていきます。
貴社のビジネスにとって、どのサービスが重要ですか？
Webサーバーを監視する場合、HTTPリクエスト、ネットワーク遅延、稼働時間、その他のWebサーバーの重要情報を監視するツールを選択する必要があるでしょう。データベースサーバーには、失敗したログイン、エラー、およびデータベースのステータスをチェックするためにデータベースクエリを実行できるソリューションが必要です。ハイパーバイザーとして機能するサーバーには、仮想マシンとホストがリソースを効率的に消費していることを確認するために、非常にきめ細かいリソース監視が必要です。
環境の規模はどのくらいで、今後どのように拡張されますか？
ITインフラの大きな成長を見込まない中小企業のニーズは、自社データセンターを運用するフォーチュン500企業のニーズとは異なります。監視ツールを選択する前に、環境の規模を理解することで、不要なサービスに過払いしたり、必要な機能を見逃したりすることを避けることができます。
ニーズを満たすために利用できるツールは何ですか？
小規模なサーバーネットワークであれば、ネイティブオペレーティングシステムベースのツールと組み込み機能だけを使用して、すべてのニーズを満たすことができるかもしれません。たとえば、ネットワークパフォーマンスモニターとメールアラート用のいくつかのカスタムスクリプトで、小規模なWindows環境には十分かもしれません。
さまざまな機能とアプリケーションを持つ大規模なサーバーネットワークでは、前述のすべてのユースケースなどをサポートし、一元化された監視、アラート、レポート作成を可能にする、機能豊富なNMSから恩恵を受ける可能性が高いでしょう。
監視ソリューションを導入したら、どうしますか？
この質問への回答は、選択したツールとユースケースの要件によって大きく異なりますが、一般的には、サーバーを検出してツールをプロビジョニングし、ビジネスにとって重要なメトリックのしきい値を定義し、イベント発生時に通知される連絡先を追加し、設定する必要のあるスクリプトやその他のカスタムアクションおよび機能を定義する必要があります。多くのエンタープライズグレードの監視ソリューションは「自動検出」機能をサポートしており、ネットワークデバイスの検出と監視を自動的に開始することに注意してください。サーバー監視ソリューションをプロビジョニングする際に覚えておくべきいくつかの重要なポイントは次のとおりです。
-
可能な限り自動化する - あなたのチームは、一般的な問題に対する解決策をすでに十分に理解しているはずです。それらの解決策を可能な限り自動化してください。たとえば、監視対象のサービスが半定期的にロックアップし、その解決策が単に再起動することである場合、そのためのアクションを設定してください。
-
適切な人に通知する - 自動化は素晴らしいですが、ITチームが存在する理由があります。しきい値を超えたときやサーバーがダウンしたときに、彼らに通知されるようにしてください。可能な場合は、メールとSMS通知を活用してください。
-
チームがアラームに慣れすぎないようにする - ITで最も見落とされがちな問題の1つは、アラーム過多です。行動を必要としない些細なイベントについては、チームにアラートを送信しないようにしてください。これは、ユースケースに合わない恣意的なメトリックではなく、パフォーマンスのベースラインに基づいてしきい値を設定することを意味します。たとえば、特定のバッチプロセスが実行されたときにサーバーCPUが1日に一度82%にスパイクし、チームが80%でアラームを受け取る場合、彼らはすぐにこれらのアラームを無視するようになるでしょう。
-
データを追跡してパフォーマンスのベースラインを設定する - より良い長期的な意思決定を行うには、現在のIT投資がどうなっているかを知る必要があります。収集したデータを活用して、サーバーリソースの使用状況、アップグレードが必要な領域、インフラストラクチャのボトルネックになっている可能性のある領域をマッピングしてください。
実際に機能しているかどうかをどうやって判断できますか？
しきい値を設定し、アラートとアクションを設定した後、いざという時にそれが実際に機能するかどうかをどうやって知ることができるでしょうか？多くのツールは、すべてが機能していることを確認するための「テスト」または「シミュレーション」機能を提供していますが、設定をテストするより確実な方法は、アクション（メール送信またはスクリプト実行）をトリガーするのに十分低いしきい値を設定することです。たとえば、CPU使用率に関するメールアラートの通常のしきい値が80%であるのに、CPUが通常5%で動作している場合、しきい値を1%に下げてアラートをトリガーします。期待通りに通知が届いた場合、ビジネスロジックは正しく機能しており、しきい値を元に戻すことができます。
どのようなサーバー監視計画の中心にも、稼働時間を念頭に置いて設計された堅牢なサーバーインフラストラクチャがあるべきです。弊社の
Durastreamsミッションクリティカルサーバーは、ミッションクリティカルなアプリケーションを24時間365日稼働させるように設計されています。Premioの業界をリードするサーバーおよびストレージ設計と知識豊富なソリューションエキスパートがお客様に何を提供できるかについて、今すぐお問い合わせください。
