AzureMonitor概要のところで、各機能の機能やエージェントについて、ご紹介しました。
今回は、少し細かい話をしましょう。
初めに
環境の運用保守において、仮想マシンやコンテナの監視、及びAzureリソースの監視は必要不可欠な部分となります。
AzureMonitorはまさにそのことをAzureのみで完結するための機能となります。
一般的な話ですと、MSの製品のSCVMMや他のサードパーティーの製品のエージェントを仮想マシンに入れて、マネージャーサーバというのを立てて監視するのがいっぱい的です。
ただ、Azureの機能で監視の要件を満たせるであれば、わざわざサードパーティーを買って導入する必要はないではないでしょうか。
ですので、ここで一般的な監視の要件から、AzureMonitorが具体的に何ができるかを説明していきたいと思います。
一般的な監視要件
オンプレと違って、クラウドはマネジッドサービスが多いため、監視が必要な内容は割と少ない感じはします。
一般的に、以下のようなものが監視として必要かと考えております(不足あったら、今後補足していく予定)。
- 仮想マシン(Windows/Linux)
- 死活監視
- メモリー監視
- CPU使用率監視
- ディスク使用率監視
- プロセス監視
- ログ監視(EventLog、syslogなど)
- Azure(ポータルレベル)監視
- リソース状態監視
- Azureリソースへの操作監視
- Azureのログイン監視
- Azureの障害監視
- ネットワーク監視:※Azureの別製品になるので、今後機会あったらご紹介します。
- コンテナの監視(AKS):※情報が揃っていないため、今後補足する予定。
それぞれも緊急レベルも必要に応じて、付ける必要もありますが、環境によるため、ここでは割愛いたします。
監視要件対AzureMonitor
では、それぞれの要件に対して、AzureMonitorでどの機能で対応できるかを見ていきましょう。
死活監視(Windows/Linux)
仮想マシンの死活監視といっても、サーバの用途によって、様々な手法があります。
例えば、WEBサーバの場合、HTTP/HTTPS通信がWEBアプリに届かなければ、そもそもサーバが死んでいなくても意味がないです。
その場合、HTTP通信で死活監視を実施しなければなりません。
Azureにおいて、ロードバランサーがその機能を持っていますが、それはまた別の話になるので、ここでは深く触れないようにします。
ここで言っている死活監視は、あくまでサーバが死んでいるかどうかの話に留まります。
AzureMonitorでの対応案:
- Log Analyticsによるheartbeatログの監視:
- Log Analyticsエージェントを仮想に入れて、AzureMonitorの「ログ」項目にて、「クエリ」を使って監視する手法
- ログクエリTable:
HeartBeat
- Activity logの仮想マシン状態ログ
- AzureMonitorの「アクティビティログ」項目にて、ログを監視する手法
上記の二つの案は合わせて使用することも可能ですが、やはりLog Analyticsの方がサーバフリーズしても検出可能なため、オススメします。
※ログのクエリは、"Kusto クエリ言語"というものを使用しています。
メモリー監視、CPU使用率監視、ディスク使用率監視
こちらは一般的なサーバ負荷監視となります。
AzureMonitorでの対応案:
- Log Analyticsによるログでのメトリック監視:
- Log Analyticsエージェントを仮想に入れて、AzureMonitorの「ログ」項目にて、「クエリ」を使って監視する手法
- ログの格納先がLog Analyticsワークスペースとなる
- Windowsは複数のLog Analyticsワークスペースを同時に指定可能
- Linuxは一つのLog Analyticsワークスペースのみ指定可能
- ログクエリTable:
Perf
- Azure Diagnostics 拡張機能の夜監視:
- Diagnostics拡張機能エージェントによる監視する手法
- 仮想マシンの「診断設定」にて、有効にできる
- デフォルトではCPUの使用率のみ監視可能
- メモリーとディスク使用率の監視は追加のエージェントを導入する必要がる
- Windows:ポータルで設定可能
- Linux(シンクに必須):InfluxData Telegraf エージェント
- メモリーとディスク使用率の監視は追加のエージェントを導入する必要がる
- ログの格納先はストレージアカウント(テーブル及びBLOB)となる
- シンク(他のところに転送)が可能:EventHub、Log Analytics、他のストレージアカウント
- AzureMonitorエージェント(プレビュー)による監視:※プレビューのため、今後機会あれば追記する。
また、Log Analyticsのメトリック監視はログとなりますが、クエリでのグラフ化も可能のため、特に劣る点はないと感じています。
プロセス監視
プロセス監視はAzureの機能では、一つの手段しかないとMSのサポートからの回答となります。
AzureMonitorでの対応案:
- Log Analyticsによるログでのメトリック監視:
- Log Analyticsエージェント + 依存関係エージェントで、プロセスの情報を取得する
- ログクエリTable:
InsightsMetrics
Azureの機能だけで、プロセスの監視までできるのは感心しました。
更に関心するのは、仮想マシンの「分析情報」項目にて、プロセス及びその依存関係のあるもののマップもグラフで見ることが可能です。
例とすれば、RDP(リモートデスクトップ)プロセスのアクセス元のIPアドレスも一覧に出てきます。
これは驚きました。
ログ監視(EventLog、syslogなど)
ログの監視は一般的なものです。
一応下記のどれでも監視することが可能です。
- Log Analyticsによるログでのメトリック監視
- Azure Diagnostics 拡張機能の監視
- AzureMonitorエージェント(プレビュー)による監視
基本システムログを監視することになりますが、Log Analyticsではカスタムログも監視可能らしい(※項目はありますが、まだ使ったことがない。)です。
Azure(ポータルレベル)監視
- アクティビティログで監視するもの
- リソース状態監視
- Azureリソースへの操作監視
- AzureMonitorで監視するもの
- Azureの障害監視
- Azure Active Directoryの「サインイン」項目で監視
- Azureのログイン監視
この部分は特別な設定やエージェントなど不要なため、簡単な紹介となってしまします。
監視後の処理
上記監視の結果は、アラートに紐づくことで、いろんなアクションを行うことが可能です。
例えば、メッセージの送信、メールの送信、Azure Automationと連携しての自動処理をするなどです。
テナント越しのデータ転送
複数のテナントに跨る環境で、集中して監視したい場合があります。
上記の機能はあくまで同じテナントで監視可能な内容のため、ここでどんな監視がどうやって他のテナントに転送できるかについて、
簡単にご紹介しようと考えています。
※テナントというのは、管理の組織のことを意味する。要するにAzure ADが違う場合とかを指します。
基本的には、Azure Diagnostics 拡張機能エージェントはEventHubへ送信可能なため、EventHub + LogicAppで他のテナントに転送することが可能です。
そのため、仮想マシンのパフォーマンス情報、ログ情報は基本転送可能となります。
プロセス監視監視はLog Analyticsでしかできないため、以下の手法でテナント越し収集可能です。
- Log Analyticsのクエリで、ログの結果をエクスポートして、他のテナントに持って行く
- エクスポートの手法
- CSVファイルのダウンロード:ファイル経由での転送
- M Query:ExcelやpowerBIへ登録できるクエリを発行し、ExcelやPowerBIへ登録することで、リアルタイムに近い体験でログ監視が可能
- エクスポートの手法
- Log Analyticsエージェントを直接向こうのテナントのVMに手動インストールする
- Log Analyticsエージェントは任意のVMは物理マシンのOSにインストール可能なため、可能となります。
- Azure Lighthouse機能を使用して、他テナントのリソースを権限委任することで、同じテナントのように監視する
- こちらは機能のみ知っているが、まだ詳しいところは確認取れていません。機会あれば確認する予定。
最後に
今回また色々最近知ったことを文字にして、皆さんの役に立てるよう情報公開をしました。
Azure上の監視運用をご検討している方は、ぜひご参考してみていただければと存じます。
ここまで読んでいただいて、お疲れ様でした。
コメント