その①
前回に引き続き、Well Architected Frameworkに基づいた監視の構成について、
実装部分を行っていきます。
全体構成
ここからは、実際のWebサーバーの環境に合わせて監視体制を構築するための設計をしていきます。
ざっくりと全体構成を配備します。
※Application InsightsはAzure Monitorの機能の一部らしいので厳密には重複した言い方になっていますが、
Azure Monitor ＝ VM監視 Application Insights ＝ アプリケーション監視くらいのニュアンスで使い分けしています。
例えばWebページに繋がらないなどの問い合わせに対しては、Network WatcherやAzure Monitorで原因を探し、Webページの特定のページがおかしいなどに対してはApplication Insightsで原因を探すというような使い分けを想定します。
監視体制
以下4つの観点から監視を行います。
ユーザー目線の可用性
これはApplication Insightの可用性テストを使って実装します。
Application Insightの可用性テストでは、世界中からWebサーバーに向けたアプリの死活だけでなく、証明書のチェックやHTTPヘッダ（POST,GETなど）に対する応答などもチェックできます。
アプリケーションレイヤー（今回は省略）
こちらもApplication Insightを使って監視します。
ライブメトリック機能を使うとリアルタイムの監視ができたり、
スマート検知機能では「いつもと違う」をAIが検知してアラートを発砲するといった機能も備わっています。
以下は、Microsoft LearnのApplication Insight概要に関するトレーニングをAIに要約させた記事です。
App Serviceで構築したWebアプリケーションであればスムーズな連携が可能ですが、
VM上のApache+PHPで構築したWordPressのテレメトリ情報を取るにはコードの変更が必要だったりと作業の難易度や危険性がやや上がるため、今回は省略します。
＜Java および Python アプリ用の App Service と Java Functions ではOpenTelemetoryの自動インストルメンテーションが利用できる＞
＜JapaScript SDKを使うことでテレメトリデータの収集が可能だがコードの追加が必要＞
＜App ServiceであればPortalからApplication Insightsの有効化が可能＞
インフラレイヤー
Azure MonitorのVM Insightを使ってディスクやメモリ、CPUのメトリックを監視できます。
主要なプロセス（ApacheやMySQL）の稼働監視もでき、
取得したメトリックを可視化します。
また、ログの取得も可能で、syslogやauthログ（SSHログインの成功・失敗、sudoの使用履歴など）も
LogAnalyticsで一元監視できます。
ネットワークレイヤー
Network Watcherの仮想ネットワークフローログや、トラフィック分析を使うことで、
過剰なポートが開いていないか、トラフィックが輻輳していないかなどを見ることができます。
また、IPフロー検証やNSG診断などのトラブルシュートなどに使えるツールが豊富です。
VM1台のWebサーバーに対する監視としては過剰ですが、学習のために今回は仮想ネットワークフローログの取得とトラフィック分析による可視化を採用してみます。
実装
紹介した順番と前後しますが、VMの監視（VMInsight）→アプリの監視（Application Insight）→ネットワークの監視（Network Watcher）の順に実装してみます。
VMの監視
流れとしては以下の通りです。
１．LogAnalyticsワークスペースの作成
２．VM Insight DCRの作成
３．データコレクションの追加（ログ取得）
Log Analyticsワークスペースの作成
１．Azure Portalにログイン
２．検索ボックスからLog Analyticsワークスペースを選択し、作成します。
３．リソースグループやリージョンなどを入力して作成します。
VM Insight DCRの作成
１．Azure Portalの「監視」→「仮想マシン」を選択し、分析情報の構成を選択します
２．監視対象外のVMで有効にするを選択します。
３．今回はプレビュー機能は外して、ログベースのメトリックを選択します。
オンボードに成功しましたと出れば、Azure Monitor AgentがVMにデプロイされています。
４．監視対象の項目に移り、DCRが設定されていればメトリックの取得は完了です。
５．仮想マシンのリソースから「分析情報」→Azure Monitorへと進みパフォーマンスタブで視覚化されたメトリック情報を確認できます。
データコレクションの追加（ログ取得）
１．続いて、認証ログなどもLog Analyticsで一元管理するために、Ljnux上のログを取得できるようDCRを構成します。
先ほど作成されたDCRから「データソース」→「パフォーマンスカウンター」と進みます。
２．追加を押し、データソースを選択します。
今回はLinuxサーバーなので「Linux Syslog」を選択し、取得するログの種類と程度を決めます。
ここはコスト面に関して重要な部分で、規定のままだと全てのログをフルで収集してしまいLogAnalyticsのデータ保存料金が増大してしまうリスクがあるので、必要分だけの取得を検討します。
今回は以下のログレベルで取得します。
| ログの種類 | ログレベル | 備考 |
| LOG_ALERT | LOG_WARNING | その他に属さない警報ログ |
| LOG_AUDIT | none | 監査ログ。量が多すぎるのでnone |
| LOG_AUTH | LOG_INFO | 認証（一般） |
| LOG_AUTHPRIV | LOG_INFO | 認証（機密） |
| LOG_CLOCK | none | システム時計（NTPでカバー） |
| LOG_CRON | LOG_ERR | 定期実行タスク |
| LOG_DAEMON | LOG_WARNING | デーモン |
| LOG_FTP | none | ファイル転送 |
| LOG_KERN | LOG_WARNING | カーネル |
| LOG_LOCAL0～７ | none | |
| LOG_LPR | none | プリンタログ |
| LOG_MAIL | none | メールログ |
| LOG_NEWS | none | ニュースグループ？ |
| LOG_NOPRI | none | 分類不能ログ |
| LOG_NTP | LOG_ERR | サーバーの時刻 |
| LOG_SYSLOG | LOG_WARNING | ログシステム自体のメッセージ |
| LOG_USER | LOG_ERR | ユーザーレベルのプログラムログ |
| LOG_UUCP | none | 昔のレガシープロトコル |
３．その後、ターゲットの選択で送付するLogAnalyticsワークスペースを選択し、データソースの追加をします。
４．作成したデータソースが追加されていればOKです（Mocrosoft-Perfという謎のソースもできますが無視します。）
５．仮想マシンのページからログの項目を開くと、LogAnalyticsの画面が出てくるので、
authログを取得するKQLを打ってみます。
私のログインした情報が出てきました。
これにより、身に覚えのないログインなどを発見したり、アラートを飛ばすということがAzure Monitor上でできるようになります。
アプリケーションの監視
Application Insightsでは可用性テストやパフォーマンスチェックを使ってアプリケーションを監視します。
Application Insightsのデプロイ
１．Application Insightsと検索し、作成します。
ここで、Log Analyticsワークスペースは一元管理がWell-Architected Frameworkの推奨なので、VMログチェックの時に作成したものを選択します。
可用性テストの設定
１．デプロイしたApplication Insightsの「有効」から「標準テストの追加」を選択します。
※公式ドキュメントでは「有効」ではなく「可用性」と表記されています。環境によって変わるかもしれないのでご注意ください。
２．可用性テストの項目を設定します。
URLは監視対象のサイトURLを入力します。
テストの場所は今回、Japane EastやEast Asiaなど適当に5か所選択しており、選択したリージョンから10分おきに死活監視を行うようになります。
３．作成後規定の分数ごとにテスト結果が出ます。
＜参考：可用性テストの作成＞
ネットワークの監視
Network Watcherを使ってネットワークの監視構成を組みます。
VNETフローログ
VNET内の通信を記録し可視化する機能です。（NSGフローログの後継）
１．フローログの保存場所はAzure ストレージアカウントになるので、ストレージアカウントを作成します。
リージョンは必ずVNetと同じリージョンを選択する必要があります。
検証のためLRSに設定し、その他は規定のまま作成します。
２．デプロイが完了したら、サブスクリプション→設定→リソースプロバイダーから「microsoft.insights」が登録されていることを確認します。
３．その後、Network Watcherからログ→フローログ→新規作成を行います。
４．ターゲットリソースを監視対象のVNETに設定します。
５．ログの保管先を先ほど作成したストレージアカウントに設定します。
リテンション期間は10日とします。
６．分析タブでTraffic Analyticsを有効にし、LogAnalyticsワークスペースを選択し作成を行います。
７．時間が経てばNetwork Watcherのトラフィック分析タブからトラフィック情報を確認できます。
悪意のあるトラフィックなど、ネットワークに関する様々な情報が見れます。
まとめ
今回は監視を行うための設定やログの取得設定などを中心に行いました。
ベストプラクティスに基づくと、監視やログ取得だけでなく「アラートの定義＆発砲体制」「バックアップ」なども考える必要があるので、次回以降このあたりを調査し用と思います。
コメント