BLOGAzureブログ

皆さまこんにちは、SB C&Sの八釼です。
安定的かつ継続してサービスを提供し続けるためには、システムやアプリケーションの各種コンポーネントの稼働状況を定期的に確認することや異常を速やかに検知することが大変重要です。それはオンプレミスであってもクラウドの環境であっても変わりません。

そこで今回は、Azureにおける監視サービスAzure Monitorについての概要をご紹介したいと思いますが、本サービスを利用するにあたって大前提として知っておいていただきたい複雑な事情もありますのでそれについても併せてご紹介します。

• // 目次 //
• Azure Monitorとは
• 歴史を知る
• 絶対におさえておくべき用語
• 最後に

Azure Monitorとは

データ収集対象（データソース）から「ログ」と「メトリック」を収集し、監視や分析を行う統合監視ソリューション（Azureのサービス）です。収集したデータを使って情報を可視化したり分析を行うだけでなく、異常を検出した場合にはアラートを発報したりSIEMや監視ツールにログのストリーム配信を行うこともできます。

ログ

システム内での操作や状態の変化（イベント）を時系列で出力したテキスト情報です。システムが記録している動作履歴であり、例えば障害発生の際などに原因を特定し対処するために活用します。システムやアプリケーションから吐き出される、これらに対して誰がいつ何を行ったかという情報だと考えていただいて差し支えありません。

内部統制やコンプライアンス、セキュリティ運用にも深くかかわっており、さまざまなログを収集して保存し、定期的にまたは必要に応じて参照するといった方法で一般的にITシステムにおける証跡管理は行われます。

メトリック

特定の時点におけるシステムの何らかの側面を表す数値情報で、一定の間隔で収集されます。例えばAzure VMのCPU使用率などのパフォーマンスデータが該当し、時間の経過による傾向分析を可能にしたり問題発生時にログと組み合わせて原因究明に活用したりします。オートスケールのトリガーとしても、しばしば使われます。例えばVirtual Machine Scale Sets(VMSS)を構成するAzure VMのCPU使用率に基づいて自動でスケールアウトやスケールインを実行させます。

なお現在はパブリックプレビューですが、標準で収集されるメトリックだけでなくより詳細な情報を得たい場合にはカスタムメトリックを収集することが今後できるようになります。

収集できるデータ

詳細については以下の公式ドキュメントをご参照いただければと思いますが、Azure ADテナントレベルのログからAzureリソースの操作に関するもの、Webアプリケーション内で発生するイベント、OSのシステムログ（イベントログ/ syslog）、WindowsとLinuxマシンのパフォーマンスに関する情報などなど、さまざまなデータを収集することができます。

注目すべきはAzureに関連するものしか対象にできないというわけではなく、アプリケーションであったりオンプレミスで稼働するマシン（物理/仮想）やAzure以外のクラウドサービスの仮想マシンインスタンスはもちろん、カスタムソースとして任意のRESTクライアントからもログデータを収集することもできるということです。

• 公式ドキュメント | Azure Monitor が収集するデータ

基本的には明示的にデータソースについて収集を定義するのですが、そういった定義が不要のものもあります。具体的には、アクティビティログとプラットフォームメトリックの収集です。まずはこれらのデータについてAzure Monitor ( Azure portal ) で確認してみると本サービスのイメージが湧くと思います。

歴史を知る

何でこんなことを知らなければならないんだ！と不思議に思われるかもしれませんが、このサービスにおいては非常に重要なことです。なぜならば、度重なるサービス統合や名称変更により概念の理解がとてつもなく困難な状況になっているためです。廃止になったサービス名称が一部では継続使用されている状況があったり、資料によっては変更の反映がされていない場合もあります。

• 公式ドキュメント | Azure Monitor の名称と用語の変更

加えて大幅なサービス改善も行われているのですが元々が非常に複雑だったという経緯もあり、例えばOSに導入するエージェントは新旧が入り混じってカオスな上に新しいものには制約も多く要件次第では併用が必要なのです。データ収集のための設定方法や箇所も大きく違います。

• 公式ドキュメント | Azure Monitor エージェントの概要

細かな経緯はさておき、少なくとも統合や変更の歴史があることだけでも知っていると最初から大きく道に迷う可能性が小さくなります。

とくに、一般的によく使われるであろう前述のエージェントを使用したOSからのデータ収集は、根本的に設定の仕方が変わっているのでこのような前提を理解していないと設計がままなりません。モダンな方法もまだ発展途上のため要件によってはレガシな方法を使わざるを得ません。モダンエージェントとレガシエージェントは共存できるので併用する運用は問題ありませんが、収集データの重複、ひいては利用料金には注意が必要です。詳細は割愛しますが、本サービスは基本的には収集したデータの取り込みと保持に対して料金を支払う仕組みですので、データが重複するということは当然料金に影響してくるわけです。予想される使用量に基づいて想定されるコストを見積もってみたい場合には、以前にこちらの記事でご紹介した「料金計算ツール」をご活用ください。

絶対におさえておくべき用語

細かな話をすると色々ありますが、最低限以下の二つの用語については名称と概念についてざっくりとでも知っておくと、Azure Monitorについて理解しやすいです。

Log Analyticsワークスペース

簡単に言うとログデータの保管庫です。Azureリソースとして作成されるもので、活用を目的としてデプロイした任意のワークスペースにデータを収集します。収集したデータは一連のレコードとして格納されてテーブル形式で保管されます。

なおAzure Monitorだけでなく、AIを活用した組織全体の統合セキュリティ分析サービス ( SIEM + SOAR + UEBA )であるMicrosoft Sentinelやクラウドリソースのセキュリティ体制管理と脅威保護サービス( CSPM + CWPP )であるMicrosoft Defender for Cloudなどの他のサービスでも使用する重要なものです。
注意すべきことは、前述の歴史に関わりますが「Log Analytics」という名称のサービスは既に存在しないのですが、このように一部名残があったりするのでそういうものだと割り切ってください。

KQL ( Kusto Query Language )

SQLよりシンプルなクエリ言語であり、これを使用して収集したデータを検索したりフィルタリングを行うなどして分析を行います。つまり前述したLog Analyticsワークスペースに溜まっているログデータ（テーブル）に対してKQLでクエリを投げることになります。テーブルに対してクエリを投げるというとSQL ( Structured Query Language ) がまず頭に浮かびがちですが、そうではないのでご注意ください。

このクエリは、テーブル名またはsearchコマンドから書き始めることができます（慣れるまではテーブル名から始める記述方法が推奨）。
例えば以下のような書き方ができます。

この例では、テーブル名: Event としてクエリの範囲を定義（検索対象のテーブルを指定）しパイプでwhere演算子をつなぎ（条件に基づいたフィルター処理）、EventLevelName列の値が"Error"に等しいEventレコードのみを抽出しています。

最後に

Azureを活用していく上では最適な監視戦略の実装と運用は必要不可欠です。本記事では概要をご紹介しましたが、実際の運用監視業務において然るべきデータソースからデータを収集し然るべき分析や運用を行っていくことはそれほど簡単ではありません。ご紹介したような複雑な事情も相まって環境構築や設定も相当骨が折れるかもしれません。

Azure Monitorを使った運用監視に取り組みたいと考えているが色々と不明な点がある/不安があるという皆様、まずは法人でのAzure導入前の相談窓口であるAzure相談センターまでぜひお気軽にお問い合わせください。

Azure に精通したスタッフが丁寧にご回答いたします。