Azure Monitoring and Alert v0.1.21.0422

「「「Azure の監視ってどうやるの？」」」
この仕事についてから数えるのもイヤになるくらい聞かれた質問なのですが、改めて整理してみると監視って広くて深くて、何よりも人によって意味がマチマチだったりします。
Azure には Azure Monitor がありますが、それだけでは監視の要件を満たせるとは限りません。まずは標準的に備わっている機能を把握していただくための資料として作成したものです。

Transcript

1. Ayumu Inaba Cloud Solution Architect Microsoft Japan Microsoft Azure 監視と通知 1
2. 監視の目的 障害は発生させないことが理想だが、発生してしまったら迅速 に対応することが重要 検 出 診 断 修 復 検 出 診 断 修 復
3. クラウドサービスの監視 プラットフォームの障害もアプリケーションの障害も、一元管理 できる仕組みが重要 3
4. Agenda Azure Monitor Overview プラットフォームとしての正常性評価 - Service Health リソース個別の正常性評価 - Resource Health その他のアクティビティログの活用 - Activity Log 問題の早期発見と通知 - Resource Metric 各種リソースイベントの高度な分析 - Resource Log 4
6. Azure 監視の全体像 メトリック ログ アプリケーション コンテナ VM Monitoring Solutions Insights ダッシュボード Views Power BI Workbooks Visualize Metrics Explorer Log Analytics Analyze Alerts Autoscal e Respond Event Hubs Ingest & Export APIs Logic Apps Integrate Azure Monitor カスタム ソース アプリケーション オペレーティングシステム Azure リソース Azure サブスクリプション Azure テナント
7. 監視対象データソース 7 ソース 内容 収集方法 アプリケーション アプリケーションで発生する各種イベント、テレメトリ、例外等 Application Insight SDK を使用したインストル メンテーション Application Insight Agent による自動収集 オペレーティングシステム Azure 仮想マシンのメトリックおよびログ Azure Diagnostics 拡張機能 任意の環境で動作するサーバーのメトリックおよびログ Log Analytics Agent プロセスの依存関係やネットワーク呼び出しのメトリック Dependency Agent （VM Insights） Azure リソース リソースログ（診断ログ）と各種メトリック 診断設定 Azure サブスクリプション アクティビティログ（サービス操作の監査、サービスやリソースの正 常性、計画メンテナンスなど） 診断設定 Azure AD テナント サインインアクティビティ履歴、変更の監査証跡 カスタムソース 外部のログ データコレクター API 外部のメトリック カスタムメトリック API その他 Azure Security Center Azure Sentinel
8. ２ 種類のデータ形式 メトリック 一定の間隔で収集される時系列の数値データで、特 定時刻における対象リソースの特性を表現する Azure リソースからは構成不要で収集されメトリックエ クスプローラで可視化・分析ができる データとしては軽量のため、ほぼリアルタイムでのア ラートをサポートする ログ 対象リソースで発生したイベントを記録する文字データ で、不定期に発生する Log Analytics や Storage に明示的に送信すること でクエリや保管が可能になる クエリ条件を元にしたアラートも可能だが、遅延は大き くリアルタイム監視には不向き 8 ※ VM や アプリのメトリックについては構成や設定等が必要になる ※ 93日間を超えて保存・分析する場合へエクスポート設定が必要 ※ プラットフォームが出力するアクティビティログは自動で保存されるが ログの活用の観点からは Log Analytics 等への送信がほぼ必須 ※ 保存期間は送信先のストレージに依存する
9. 収集したデータの活用 9 Integrate ：連携 Analyze ： 分析 Visualize ： 可視化 Insights : 洞察 Respond ： 対応
10. Azure プラットフォームの正常性評価 10
11. アクティビティログ Azure プラットフォームが出力する各種イベントの記録 システムによって自動生成され、変更や削除ができず、90日間保存される Azure ポータルの各リソースの画面で確認できる 11 カテゴリ 内容 主な用途 Administrative Azure Resource Manager に対して行われ た各種操作が記録される 監査証跡 ServiceHealth Azure 全体や各種サービスレベルでのインシ デントが記録される 大規模障害の検知や更新履歴 ResourceHealth ユーザーがデプロイした特定の Azure リソー スの正常性の状態変化と理由が記録される 利用するサービス障害や自動 シャットダウン等の検知 Alert 実際に発砲されたアラートが記録される アラート履歴や傾向分析 Autoscale オートスケールが動作履歴が記録される コストやキャパシティの最適化 Recommendation Azure Advisor によって提示された推奨事項 推奨事項や対象変化の追跡 Security Azure Security Center によって検知された 警告 セキュリティインシデントの確認 Policy Azure Policy による評価とアクションの履歴 ガバナンス適用状況の追跡
12. Service Health ServiceHealth カテゴリ専用の画面が 用意されている 現在の問題だけでなく、過去の履歴、将来のメンテナンス予定 なども表示される 何かおかしいと思ったらまずココを開く 12 アラートも設定可能
13. サービス正常性の通知 サービス正常性アラートで 受信したメールのサンプル 2021年3月に発生した Azure AD 障害 の RCA が通知されている例 先はメール通知の例だが、SMS や Webhook への通知も可能 ログが記録されるのは障害 だけでなく一連の経緯 アラートとして必要なイベントが何かを精 査する 13
14. [補足] Azure の状態 Azure ポータルにアクセスでき ない場合は「Azure の状態」を 確認する https://status.azure.com/ Service Health とは異なり、Azure 全サービス とリージョンのインシデントが記録される（＝必ずし も影響を受けているとは限らない） 外出先や自宅では Azure AD 認証が通らない などの制約があると、サービス正常性画面が開け ないのでこちらも確認 RSS フィードが取得できるためこちらもサブスク ライブしておくと良い 14
15. 再起動を伴う計画メンテナンスを検知する 仮想マシンの再起動を伴うメンテの事前通知は Service Health で確認できる Service Health は正常性に関わるイベントなので、必ずしも障害とは限らない 15 ※ 再起動を伴わないメンテナンスは含まれない 計画メンテナンスの通知メール （探す）
16. Azure リソースの正常性評価 16
17. アクティビティログ Azure プラットフォームが出力する各種イベントの記録 システムによって自動生成され、変更や削除ができず、90日間保存される Azure ポータルのほぼすべての画面で確認できる 17 カテゴリ 内容 主な用途 Administrative Azure Resource Manager に対して行われ た各種操作が記録される 監査証跡 Service Health Azure 全体や各種サービスレベルでのインシ デントが記録される 大規模障害の検知や更新履歴 Resource Health ユーザーがデプロイした特定の Azure リソー スの正常性の状態変化と理由が記録される 利用するサービス障害や自動 シャットダウン等の検知 Alert 実際に発砲されたアラートが記録される アラート履歴や傾向分析 Autoscale オートスケールが動作履歴が記録される コストやキャパシティの最適化 Recommendation Azure Advisor によって提示された推奨事項 推奨事項や対象変化の追跡 Security Azure Security Center によって検知された 警告 セキュリティインシデントの確認 Policy Azure Policy による評価とアクションの履歴 ガバナンス適用状況の追跡
18. Resource Health Resource Health は各リソース毎に 確認できる 報告されるステータスは３つ（使用可能、使用不可、不明） チェック内容はリソース種別によって異なる 18 個々のリソースの 画面から確認
19. リソース正常性の監視 異常が検知されると・・・ 19
20. リソース正常性の監視 リソース正常性アラートで受 信したメールのサンプル Spot VM が容量不足で強制的に割り当 て解除されたことが報告されている VM の停止なので Resource Health からアラート通知されている これ自体は想定された挙動なので実際に は障害ではない 20
21. 複数リソースの正常性を横断的に取得 サービス正常性の画面でリソース種類ごとに一覧表示可能 特定サービスの大規模障害が 起こっている状況において 影響を受けているリソースを特定 システム単位などで複数リソース 種類を横断的に確認したい場合は REST API を利用するとよい Azure リソース正常性 REST API REST API をオンプレミスや 他社クラウドから呼び出すことで 外部監視とすることも可能 21
22. リソース正常性の監視 - サブスクリプション一括 Azure CLI の az rest コマンド az rest --method get --url https://management.azure.com/subscriptions/${SubscriptionId}/providers/Microsoft.ResourceHealth/availabilityStatuses?api-version=2018-07-01 22
23. リソース正常性の監視 - サブスクリプション一括 Azure PowerShell の Invoke-AzRest コマンド $path = “/subscriptions/${SubscriptionId}/providers/Microsoft.ResourceHealth/availabilityStatuses?api-version=2018-07-01” $res = Invoke-AzRestMethod -Method GET –Path $path ($res.Content | ConvertFrom-Json).value | foreach {…} 23
24. アクティビティログの活用 24
25. アクティビティログの活用 正常性以外のカテゴリにも重要なイベントが記録されている 25 カテゴリ 内容 主な用途 Administrative Azure Resource Manager に対して行われ た各種操作が記録される 監査証跡 Service Health Azure 全体や各種サービスレベルでのインシ デントが記録される 大規模障害の検知や更新履歴 Resource Health ユーザーがデプロイした特定の Azure リソー スの正常性の状態変化と理由が記録される 利用するサービス障害や自動 シャットダウン等の検知 Alert 実際に発砲されたアラートが記録される アラート履歴や傾向分析 Autoscale オートスケールが動作履歴が記録される コストやキャパシティの最適化 Recommendation Azure Advisor によって提示された推奨事項 推奨事項や対象変化の追跡 Security Azure Security Center によって検知された 警告 セキュリティインシデントの確認 Policy Azure Policy による評価とアクションの履歴 ガバナンス適用状況の追跡
26. アクティビティログアラート アクティビティログは既定で保存されており、それを元にしたア ラート発報が可能 ある１つのログのプロパティが条件に合致するか否かというシンプルな基準 クエリ結果を基にした複雑な条件指定で発報したい場合は、後述の診断設定とログアラート を併用すると良い 26 query Threshould Alert
27. アクティビティログの活用 アクティビティログは診断設定をして別サービスに送信するとよい アクティビティログ自体は 90 日しか保存されず、クエリなどによる活用が難しい 複数の診断設定をすることが可能（インフラ運用分析 ＋ セキュリティ監査用途など） 送信先サービスによる料金が別途発生することに注意 27 その他の監視データとの関連付け 複雑な条件によるアラート発報 長期データの横断的な分析 監査証跡としての長期保存 ローカル端末にダウンロードした分析 3rd Party ソリューションとの連携 SIEMやログ分析ソリューションなど
28. アクティビティログのクエリ アクティビティログを Log Analytics に送信することで複数 のイベントを横断した解析が可能になる 28
29. 問題の早期発見と通知 29
30. Azure Monitor メトリック リソースレベルのメトリック設定不要で分析・可視化が可能 Azure ポータルで各サービスの概要画面にグラフが表示されるものが多い 詳細な分析を行いたい場合はメトリックエクスプローラを使用する ほぼリアルタイムのシナリオに対応するため問題の通知や迅速な検出に有用 30 多次元メトリックデータを 活用したフィルタと分割
31. メトリックアラートとその対応 観測されたメトリックに対して静的／動的な条件によってア ラートを発報することができる 静的 : 前述のリソース制限などをベースに閾値が固定できるもの 動的 : 閾値を固定せず過去データの機械学習を元に判定するもの 31 - 対人通知 - E-mail 、SMS、電話音声、 Azure モバイルアプリ - 自動対応 - Automation Runbook、 Logic Apps、Functions - 外部連携 - WebHook、ITSM Azure Monitor を使用してメトリック アラートを 作成、表示、管理する
32. メトリックデータの長期保管 既定では93日間保存されるが、さらに長期的な分析を行い たい場合は診断設定によって外部にエクスポート可能 ただし一部のメトリックは非対応、単一ディメンジョンにフラット化されてしまうことに注意 リアルタイム性も劣化するため、タイムリーな検知にはメトリックアラートを使用した方が良い 32 各種 リソース
33. エラーの予兆と発生を検知 各リソース制限に抵触するとエラーの発生や性能劣化につな がるため、まずは制限値に対するメトリックに着目するとよい Azure サブスクリプションの制限とクォータ Azure Monitor でサポートされているメトリック (リソースの種類別) 33 エラー 性能劣化 警告 保守対応 障害対応
34. メトリック表示名 ユニット Used capacity Bytes Transactions Count Ingress Bytes Egress Bytes Success E2E Latency Millisecounds Success Server Latency Millisecounds Storage Account ストレージで懸念されるエラーの検知と対応策の例 34 リソース 制限 サブスクリプションあたりの各リージョンのスト レージ アカウント数 250 ストレージ アカウントの最大容量 5 PiB 1 ストレージ アカウントあたりの BLOB コンテ ナー、BLOB、ファイル共有、テーブル、キュー、エ ンティティ、メッセージの最大数 制限なし ストレージ アカウントあたりの最大要求レート1 1 秒あたり 20,000 要求 ストレージ アカウントあたりの最大イングレス 1 (米国、ヨーロッパ リージョン) 10 Gbps ストレージ アカウントあたりの最大イングレス 1 (米国とヨーロッパ以外のリージョン) RA-GRS/GRS が有効な 場合は 5 Gbps、LRS / ZRS の場合は 10 Gbps 汎用 v2 および BLOB ストレージ アカウントの 最大送信速度 (すべてのリージョン) 50 Gbps ストレージアカウントごとの仮想ネットワーク規則 の最大数 200 ストレージアカウントごとの IP アドレス規則の最 大数 200 Microsoft.Storage/storageAccounts 名前空間のメトリック（一部抜粋）
35. SQL Database 単一データベースで懸念されるエラーの検知と対応策の例 35 Microsoft.Sql/servers/databases 名前空間のメトリック（一部抜粋） メトリック表示名 ユニット Data space used percent Percent Data space used Bytes Data space allocated Bytes Data IO percentage Percent Workers percentage Percent Successful Connections Count Failed Connections Count Deadlocks Count 監視とパフォーマンスのチューニング - Azure SQL Database
36. Synapse Analytics Synapseで懸念されるエラーの検知と対策の例 36 管理と監視 - クエリ アクティビティ、リソース使用状況 - Azure Synapse Analytics カテゴリ 説明 最大値 Data Warehouse ユ ニット (DWU) 1 つの専用 SQL プール に対する最大 DWU Gen1:DW6000 Gen2:DW30000c Data Warehouse ユ ニット (DWU) サーバーあたりの既定の DTU 54,000 データベース接続 同時に開かれる最大 セッション数 1024 データベース接続 準備されたステートメント に対する最大メモリ容量 20 MB ワークロードの管理 同時クエリの最大数 128 tempdb 最大 GB DW100c あたり 399 GB 専用 SQL プールの容量制限 （一部抜粋） Microsoft.Synapse/workspaces/sqlPools 名前空間のメトリック （一部抜粋） メトリック表示名 ユニット DWU used percentage Percent Connections Count Active queries Count Queued queries Count Workload group active queries Count Workload group queued queries Count
37. Data Factory Azure Monitor には完了済みのイベ ントのみが出力される このため事後データの解析を主眼にした監視となる 37 リソース 既定の制限 データ ファクトリあたりの同時実行パイプラインの実行数 (ファクトリ内 のすべてのパイプライン間で共有) 10,000 パイプラインあたりの最大アクティビティ数 (コンテナーの内部アクティ ビティを含む) 40 単一のセルフホステッド統合ランタイムに対して作成できる、リンクされ た統合ランタイムの最大数 100 パイプラインあたりの最大パラメーター数 50 ForEach 項目数 100,000 ForEach 並列処理 20 パイプラインあたりのキューに入れられた実行の最大数 100 式ごとの文字数 8,192 最小タンブリング ウィンドウ トリガー間隔 15 分 パイプラインのアクティビティ実行の最大タイムアウト 7 日 パイプライン オブジェクトのオブジェクトあたりのバイト数3 200 KB データセットおよびリンクされたサービス オブジェクトのオブジェクトあ たりのバイト数3 100 KB 各アクティビティの実行のペイロードあたりのバイト数4 896 KB コピー アクティビティの実行あたりのデータ統合単位1 256 API 呼び出しの書き込み 1,200/h API 呼び出しの読み取り 12,500/時 1 分あたりの監視クエリ 1,000 データ フロー デバッグ セッションの最大時間 8 時間 統合ランタイムごとのデータ フロー同時実行数 50 Data Flow の Azure IR の TTL 制限 4 時間 Metric display name Unit Cancelled activity runs metrics Count Failed activity runs metrics Count Succeeded activity runs metrics Count Cancelled pipeline runs metrics Count Failed pipeline runs metrics Count Succeeded pipeline runs metrics Count Cancelled trigger runs metrics Count Failed trigger runs metrics Count Succeeded trigger runs metrics Count Microsoft.DataFactory/factories 名前空間のメトリック（一部抜粋） Azure Monitor を使用して、データ ファクトリを監視する - Azure Data Factory
38. Logic Apps 38 状態を監視し、履歴を表示し、アラートを設定する - Azure Logic Apps 名前 制限 実行継続時間 90 日間 ストレージでの実行履歴の保持期間 90 日間 最小の繰り返し間隔 1 秒 最大の繰り返し間隔 500 日 アクション: 5 分間隔ごとに実行 100,000 回の実行 (既定) 300,000 回の実行 (高スループット モー ドで最大) アクション:同時送信呼び出し ～ 2,500 ランタイム エンドポイント: 同時受信呼び出し ～ 1,000 ランタイム エンドポイント: 5 分あたりの読み取 り呼び出し数 60,000 ランタイム エンドポイント: 5 分あたりの起動呼 び出し数 45,000 5 分あたりのコンテンツのスループット 600 MB トリガーのコンカレンシー コンカレンシーがオフの場合:無制限 コンカレンシーがオンの場合: 既定：25、最小：1、最大：50 待機中の実行の最大数 コンカレンシーがオフの場合: 最小：1、最大：50 コンカレンシーがオンの場合: 最小：10+同時実行数、最大：100 SplitOn 項目数 コンカレンシーがオフの場合:100,000 コンカレンシーがオンの場合:100 Logic Apps の制限（一部のみ抜粋） Microsoft.Logic/workflows 名前空間のメトリック（一部抜粋） メトリック表示名 Unit Run Failure Percentage Percent Run Latency Seconds Runs Cancelled Count Runs Completed Count Runs Failed Count Runs Started Count Runs Succeeded Count Run Start Throttled Events Count Run Success Latency Seconds Run Throttled Events Count
39. Web Apps 39 リソース Standard Premium (v1 から v3) プランあたりのアプリ数 無制限 無制限 App Service プラン リソース グループあたり 100 リソース グループあたり 100 スケール アウト (最大インスタ ンス) 10 専用インスタンス 20 専用インスタンス (v1,v2)、 30 専用インスタンス (v3)。 ストレージ 50 GB 250 GB CPU 時間 無制限 無制限 メモリ制限 該当なし 該当なし 帯域幅 無制限 無制限 アプリケーションのアーキテク チャ 32 ビット/64 ビット 32 ビット/64 ビット インスタンスごとの Web ソケッ ト数 無制限 無制限 インスタンスあたりの送信 IP 接続数 インスタンス サイズに よって異なる インスタンス サイズによって異な る サブスクリプションあたりの App Service 証明書数 10 10 アプリケーションごとのカスタム ドメイン数 500 500 Hybrid Connections (ハイ ブリッド接続) プランあたり 25 アプリあたり 200 メトリック表示名 Unit CPU Percentage Percent Memory Percentage Percent Disk Queue Length Count Http Queue Length Count Socket Outbound All Count Microsoft.Web/serverfarms 名前空間のメトリック（一部抜粋） メトリック表示名 Unit Response Time Seconds Requests Count Http Server Error Count Microsoft .Web/sites 名前空間
40. 自動スケール 一部のサービスはメトリックや時間に応じた水平方向の自動 スケールに対応している エラーの予兆検知に対して人的な判断を 介在させずに緩和することができるため、 システムの信頼性品質を安定させる上で 非常に有用 スケールアウトとスケールインの両方を 組み込むことでコストの最適化にも寄与 非対応サービスの自動スケールを実現 したい場合はアラートと Automation を 組み合わせて実装すると良い 40 Microsoft Azure の自動スケール - Azure Monitor | Microsoft Docs App Service, VM Scale Sets, API Management, Data Explorer, など
41. 各種イベントの高度な分析 41
42. Azure リソースログの収集 各種リソースで発生したイベント記録は既定で保存されない ログを元にした分析や可視化のためには、まず診断設定をして送信してやる必要がある Log Analytics ： Kusto によるクエリと可視化（オススメ） Storage ： 長期保管と JSON 形式の生データに対する独自の分析 EventHub ： 外部サービスへの送信 42
43. Log Analytics によるリソースログの分析 診断設定で Log Analytics に送信されたデータは AzureDiagnostics テーブルに格納される 格納されるデータはサービス固有部分が多いため、Azure リソース ログでサポートされてい るサービスとスキーマ を参考にすると良い 43 各種 リソース Kusto クエリ言語 Azure Monitor で のログ クエリ
44. 実装済みの監視ソリューションの活用 一部のサービスでは収集したリソースログやメトリックに対する実装 済みの解析ソリューションをインストールすることができる ログやメトリックのスキーマを把握して独自のソリューションを構築するには時間と経験も必要 まずは実装済みのソリューションを活用ないしは参考にすると良い 44 Azure Monitor での監視ソリューション - Azure Monitor | Microsoft Docs
45. ログアラート クエリを定期実行し結果を元にア ラートを発報することもできる 時系列データに対して一定頻度でクエリが評価され るため、各クエリが対象とするデータ範囲に留意 45 各種 リソース
46. Microsoft Confidential ◼ 本資料は情報提供のみを目的としており、本資料に記載されている情報は、本資料作成時点でのマイクロソフトの見解を示したものです。状況等の変化により、内容は変更される場合があります。本資料 に特別条件等が提示されている場合、かかる条件等は、貴社との有効な契約を通じて決定されます。それまでは、正式に確定するものではありません。従って、本資料の記載内容とは異なる場合がありま す。また、本資料に記載されている価格はいずれも、別段の表記がない限り、参考価格となります。貴社の最終的な購入価格は、貴社のリセラー様により決定されます。マイクロソフトは、本資料の情報に対 して明示的、黙示的または法的な、いかなる保証も行いません。 © ２０２０ Microsoft Corporation. All rights reserved. Microsoft, Windows, その他本文中に登場した各製品名は、Microsoft Corporation の米国およびその他の国における登録商標または商標です。 その他、記載されている会社名および製品名は、一般に各社の商標です。 46