この記事は更新から24ヶ月以上経過しているため、最新の情報を別途確認することを推奨いたします。
システムは設計者の意図する姿で稼働することが求められます。その中でも保守を行う際の重要な要素としてシステム監視業務があります。今回は、システム監視業務を設計する際の検討、実装におけるポイントを纏めてみました。
（１）概要
24時間365日の運用体制で保守を行うことが多いですが日中のみの運用と比較すると3倍弱のコストがかかることになります。
またシステム特性によっては日中のみ、またはサービス停止時のみ対応したいという要望も多いと思います。
そのようなケースでは、システムを自動監視、障害時には自動復旧し結果を通知するのみで運用担当者の負担削減（コスト削減）を
図ることが推奨されます。以前はシステムの安定性などから自動化しても監視がされているのかを監視する「監視のための監視」がありましたが、クラウドに監視サーバを置くことで、この対応までを必要としなくなりました。
（２）システム監視設計のポイント
システム要件に沿って設計、実装を行うのがセオリーですが、監視に関してはビジネス上の関心事は比較的シンプルで
・エンドユーザがサービスをストレスなく利用できているか
に尽きます。
① ストレスなく＝パフォーマンス監視
② 利用出来ている＝アプリケーション（ログやプロセス）、OS（ログやメトリック）、ネットワーク監視
として捉えることで、不要な監視アラートを出さないことが可能です。
上記程度にとどめておかないと例えば設定できるすべての監視項目を対象とすると、多くのアラートを受信、確認することになるので運用担当者は疲弊してしまいます。（離任～引継ぎの悪循環でノウハウがたまらず低い品質で保守することになってしまいます）
監視間隔や閾値などのチューニングを定期的に見直すことも必要です。運用の振り返りなどでアラート通知状況の棚卸を行えば良いでしょう。
（３）Azureで実施できる監視項目
AzureではAzure Monitorという標準の監視ツールがあります。複数のシステムを運用している場合は出来る限り統合した監視ツールを利用することが負担を軽減しますが、Azure単体でシステムを構築する場合はAzure Monitorだけで十分です。
項目としては、
・OSメトリック監視
・ログ監視
・アプリ監視
など必要な監視機能は備えています。
https://docs.microsoft.com/ja-jp/azure/azure-monitor/overview
また、セキュリティセンターなどを利用することでセキュリティ上のリスク、推奨事項の確認も可能です。
これらはオンデマンド型の監視項目（以前からある形式）なので、より利用状況をリアルタイム且つシビアに監視・レポートが必要なシステムに対してはプロアクティブ型の監視サービスを導入することを推奨します。
（４）監視実装のあるある
運用フェーズでは監視を行う際に注意する点、想定していないトラブルも多々おきます。以下筆者が経験、対応した際の内容を記載します。参考になれば幸いです。
・CPU、メモリ等のOSメトリック監視は通知されても利用傾向を見るだけなので、このメトリックの通知だけを夜間に通知されても不愉快になるだけです。
→ これらについては、ビジネスタイムにTeamsやslack等の利用しているコミュニケーションツールに転送するだけで十分です。何らかの原因でCPU、メモリ異常になることがありますが、その際は原因を究明するためにはログ監視、アプリ監視などのアプローチを先に考え、それでも監視漏れが起きるリスクが十分にある場合に通知を実装すべきです。
・OSレベルでインストールする監視エージェントが反応せず、結果タイムアウトとなり通知されることがあります。
反応しない原因は様々ですが、頻繁に生じた場合は調査が必要です。
→ 調査観点としては、サーバ単体なのか、同じ機能を持ったサーバ群で発生しているのか、同じ時間帯、曜日などの傾向分析、発生日時の前後での仕様変更の確認、ログ調査を並列で行います。
例えばセキュリティソフトのアップデートなどでメモリロックされた状態などで発生するケースもありますので、監視対象の一部であればサーバ構成から原因を切り分けることが可能です。
・監視した内容を極力自動的に対応、修復できるようなプロセス作りすることがオペミスを減らす施策につながります。
→ 通知としてTeamsやslackに状態の転送（またはRedmine等へのチケット起票）しながら、アラート条件のWebhookを利用し、スクリプト実行することで、OS再起動など対応する手順を自動化します。その他、OSコマンドを利用する場合などはansibleなどのツールを
利用することも検討できます。
・監視アラートは出ないようにする（オオカミ少年状態を作らないようにする）ことが重要です。
→ アラート別の対応が出来たら自動化プロセスを検討、適用し負担を減らすことを年頭に設計する、それを形骸化させないことが必要です。そのために保守フェーズのコスト、工数を捻出しこれらの活用に寄与するための調整が必要です。
・監視結果のレポートも重要な機能です。レポート内容から傾向を把握し、閾値等の監視チューニングを実施し、定期的な見直しに活用できます。
→ 既存の監視ツール（OSS、無償レベル）では収集期間、分析内容に制限があることが多いので、商用製品を採用することで投資対効果を高めることも検討します。（月報にコピペする程度は無償で十分ですが）
（５）推奨する監視システム（案）
以上のポイントを踏まえ、考える監視システム案は以下のとおりです。この際、複数のSaaSやツールと連携することになりますので、それらの利用状況を監視するための手段は別途検討が必要です。SaaSについてはSNS等でリアルタイムに障害が起きていないか確認することが手っ取り早いです。
次回はこれらの実装をガイドしたいと考えています。
(この記事が参考になった人の数：1)
読み込み中...