こんにちは。システム監視設計シリーズの第④段です。今回はサーバ監視について記事にします。ビジネス監視、アプリケーション監視からさらにインフラよりのお話になってきます。
サーバ監視とは？
サーバ監視とは、サーバの性能監視（ＣＰＵ使用率など）やＯＳ・ミドルのエラー監視となります。大きな意味ではサーバ自体の死活監視もこのスコープとなってきます。
もはやアプリケーションレイヤの人はあまり意識ない領域になってきています。
サーバ性能監視
サーバ性能監視では、ＣＰＵ使用率、メモリ使用率、Ｉ/Oなどをの情報を一定間隔で取得し、月次や週次などで分析することが多いかと思います。Linuxでは、Sarコマンドなどで取得可能な情報です。
この監視設計のポイントは二つです。
性能情報取得間隔
まず1点目として情報取得のインターバルです。30秒間隔取得か1分間間隔取得か10分間隔取得なのかという話です。
取得感覚が短いと取得行為がサーバに負荷を与える可能性がありますが、最近は高性能なので情報取得程度は誤差だと私は思っています。そのため、1分や30秒間隔など短い間隔で取得をお勧めします。
ただし、何も長期間保存する必要はありません。30秒の性能情報を保管続けたらディスク量が飛んでもないことになります。私としては高頻度の性能情報は一か月もあれば充分です。とっとと分析するか、割り切ってトラブルなければ削除でよいです。変わりに将来的な傾向分析用としてもう少し長いスパンの正常情報を1年など保存すると考えます。3か月後にトラブルがあった時に前からこういう傾向だったのかなどを分析可能となります。
性能評価指標値
多くの場合は、指標値を決めてxx%超えているか超えていないかで評価することが多いと思います。この考えはありはありです。ただし、単純に超えているかだけではなく、傾向をしっかりみましょう。段々と値が伸びきているのか？またはどこかの瞬間だけ飛びぬけて使用率が伸びていたりI/O負荷が高いところがないかなどです。こういうところが将来的なボトルネック・障害の原因になります。そのため、傾向分析は非常に大切になります。
加えて指標値は、システムの構成・目的により変わりますので、どんなシステムでもCPU使用率が70%や80%が良いなんてないので注意しましょう。例えば利用者が限られて社会的影響が少ないシステムであったらCPU使用率が平均90%だったとしても問題ありません。一方で突然負荷がかかる可能性がある社会インフラだったりシステムであればCPU使用率は通常時50%や30%にすることだってありだと思っています。そのため、過去の経験から決め打ちで指標を決めるのではなく、システム構成・目的をなどを踏まえて指標値を決めましょう
【続き】