Microsoft Azure の監視

まず、Azure にアプリを登録します。 このアプリは、Checkmk が Azure から必要なデータを読み込むために使用されます。 このオプションは、Azure ポータルの「(All services > Identity > Identity management > ) App registrations 」にあります。 または、ポータル検索を使用して「App registrations 」を入力することもできます。 ページが表示されたら、「New registration 」をクリックします。

任意の識別名を割り当ててください。 この例では、my-checkmk-app を使用しています。 ただし、この名前は情報目的のみに使用されます。 その代わりに、次のステップで表示されるアプリケーション ID を使用して、アプリを参照します。Supported account types セクションでは何も変更する必要はなく、Redirect URI フィールドは空のままにしてください。Register をクリックして、入力内容を確定してください。

アプリを作成すると、この新しいアプリの概要が表示されます。 表示されない場合は、前述の「All applications 」タブにあるすべてのApp registrations のリストから新しいアプリを見つけてください。 アプリの詳細には、「Application (client) ID 」と「Directory (tenant) ID 」の両方が表示されます。これらは後で Checkmk に入力する必要があります。

次に、Checkmk が Azure API にログインするために必要なクライアントシークレットも必要です。 このシークレットを生成するには、アプリの概要で「Certificates & secrets 」をクリックし、「Client secrets 」タブをクリックして、「New client secret 」をクリックします。

これにより、Add a client secret ダイアログが開きます。 任意の名前を付け、シークレットの有効期間を選択します。 後で、スペシャルエージェントのルールで App Registrations オプションを有効にすると、この有効期間が終了する前に通知する便利なサービスを利用できるようになります。Add をクリックしてダイアログを確認します。

この新しいシークレットに「Value 」の内容をすぐにコピーすることが重要です。一定時間経過すると、Azure ポートラルには、このようなシークレットの最初の 3 文字しか表示されなくなるからです。

Checkmk で以下のサービスを監視する場合は、アプリに追加の API 許可を付与する必要があります。

新しいアプリの許可の割り当ては、前のセクションで開いたままの新しいアプリの概要から開始します。

[API permissions ] をクリックし、[Add a permission.] をクリックします。 開いたダイアログで、[Microsoft Graph] を見つけてクリックします。 次に、[Application permissions ] を選択し、検索フィールドに「Directory.Read.All 」と入力します。 対応するチェックボックスを有効にして、[Add permissions] をクリックします。 この許可には、Azure 環境の管理者による追加の同意が必要です (Admin consent required)。 許可された許可のリストの上に [Grant admin consent ] ボタンが表示されない場合は、担当の管理者に連絡してください。

Checkmk が新しいアプリを介して監視データにアクセスできるようにするには、サブスクリプションレベルでアプリに役割を割り当てる必要があります。 これを行うには、左側のメインナビゲーションで [All services ] を選択し、[General ] の下にある [Subscriptions ] エントリを選択します。 該当するボタンが見つからない場合は、ポータル内の検索機能を使用できます。

複数のサブスクリプションがある場合は、監視するサブスクリプションの名前をクリックする必要があります。 サブスクリプションの概要ページが表示されます。 ここで「Subscription ID 」をメモしておきます。 これは後でスペシャルエージェントのルールに入力する必要があります。

次に、Access Control (IAM) をクリックし、Add をクリックし、Add role assignment:

次に、Reader という名前の役割を選択し、Type BuiltInRole を選択します。 名前に「Reader」という単語を含む役割は合計 100 以上あるため、ここでは注意が必要です。 次に、Next をクリックして、Members タブに移動します。

ここをクリックしてください。+ Select members.

Select members ダイアログで、先ほど作成したアプリの名前を検索フィールドに入力し、このアプリを選択して、Select.をクリックします。Review + assign をさらに2回クリックすると、Azureポータルでのセットアップが完了します。

Azureでは物理的なホストを扱っていませんが、Checkmk で Azure ディレクトリ用のホストを作成してください。 ホスト名は任意で定義できます。 重要：Azure はサービスであるため、IP アドレスや DNS 名はありません（アクセス自体はスペシャルエージェントが行います）。そのため、IP address family をNo IP に設定する必要があります。

この時点では、サービスディスカバリーはまだ機能しないため、Save & view folder で保存することをお勧めします。

Azure は通常の Checkmk エージェントではクエリできないため、Azureスペシャルエージェントを設定します。 この状況では、Checkmk は通常どおり TCP ポート 6556 経由でターゲットホストに連絡するのではなく 、Azure のアプリケーション固有の API 経由でターゲットシステムと通信するユーティリティを呼び出します。

これを行うには、Setup > Agents > VM, cloud, container > Microsoft Azure で、先ほど作成した Azure ホストにのみ適用される条件を持つルールを作成します。 そこに、ID およびシークレットを入力するフィールドがあります。

ここでは、監視するリソースグループまたはリソースも選択できます。explicitly specified groupsをチェックしていない場合は、すべてのリソースグループが自動的に監視されます。

ここで、Azure ホストでサービスディスカバリーを実行すると、少なくともAzure Agent Info というサービスが検出されるはずです。

API へのアクセスが機能しない場合 (ID が間違っている、許可が間違っている、または以下の例のようにクライアントシークレットが間違っている場合など)、Azure Agent Info のステータステキストに、対応するエラーメッセージが表示されます。

わかりやすくするために、Checkmk の Azure 監視は、Azure リソースグループごとに、Checkmk 内で（いわば）論理的なホストとして表現されるように設計されています。 これは、ピギーバックメカニズムを使用して実現されています。 このピギーバックは、スペシャルエージェントを使用して Azure ホストからデータを取得し、Checkmk 内でこれらのリソースグループホストにリダイレクトします。

リソースグループホストは、Checkmk に自動的に表示されません。 これらのホストは、手動で、またはオプションでダイナミックホストマネージメントを使用して配置してください。 重要 — その際、ホストの名前はリソースグループの名前と完全に一致する必要があります — 大文字と小文字も区別されます。 グループの名前の正確なスペルがわからない場合は、Azure ホストのAzure Agent Info サービスから直接確認できます。

IP アドレスを使用せずにリソースグループホストを設定し（Azure ホストと同様）、エージェントとして「No API integrations, no Checkmk agent 」、ピギーバックとして「Always use and expect piggyback data 」を選択します。

ここで、これらのリソースグループホストのいずれかでサービスディスカバリーを実行すると、このリソースグループに固有の追加のサービスがあることがわかります。

Azure を使用して、Checkmk の通常のホストとしても機能する仮想マシンを監視する場合、これらの VM に関連付けられている Azure サービスを、リソースグループホストではなく、Checkmk の VM ホストに直接割り当てることができます。

これを行うには、Azure ルールで、[Map data relating to VMs ] オプションの下にある [Map data to the VM itself ] 設定を選択します。 この設定を有効にするには、監視対象の VM の Checkmk ホストの名前が、Azure 内の対応する VM の名前と完全に一致している必要があります。

Microsoft Azure ルールは、CheckmkがAzure環境で発生したすべてのコストも監視するように事前設定されています。 具体的には、サービスは前日に発生したコストを表示します。 これにより、変更があったかどうかをすばやく確認できます。

コストが発生した場所を正確に把握し、特定の閾値を設定できるように、いくつかのサービスが作成されています。 最初に作成したAzure ホストのAzure ディレクトリレベルの合計コストが表示されます。 さらに、リソースグループを表す各ホストに対してサービスが作成されます。 両方のレベルで、Checkmk は、いわゆる「リソースプロバイダ」ごとのコストについて 1 つのサービスを生成します (例：microsoft.compute およびmicrosoft.network)。Costs Summary サービスは、リソースグループまたは Azure ディレクトリ全体の合計額を表示します。

Azure Usage Details (Costs) ルールを使用して、これらすべてのサービスに個別の閾値を定義することができます。

コストを監視したくない場合は、Microsoft Azure ルールでUsage Details オプションを無効にする必要があります。

デフォルトでは、Checkmk は Azure 環境からすべてのタグをインポートし、ホストラベルおよびサービスラベルに変換します。 割り当ては期待どおりに実行されます。 リソースグループに割り当てられたタグは、Checkmk ではこのリソースグループを表すホストに割り当てられ、VM のタグは、この VM のホストラベルになります。

この方法で作成されたすべてのラベルには、プレフィックスcmk/azure/ が付きます。 さらに、Checkmk で無効なラベルになる文字や値は置き換えられます。 空の値（Azure の「Value 」フィールド）は「true 」に置き換えられ、名前または値内のコロンはアンダースコアに置き換えられます。

Filter tags imported as host/service labels オプションを使用すると、Azureからのタグのインポートを制御できます。 ここでチェックボックスを有効にすると、Do not import tags でインポートを完全に防止できます。 ここでFilter valid tags by key pattern を選択すると、次のフィールドに正規表現を入力できます。 Checkmkは、この正規表現と一致するタグからのみラベルを生成します。

現在、Checkmk が Azure の監視に必要な API クエリは（AWS とは対照的に）無料ですが、一定期間に許可されるクエリの数には制限があります（スロットリング制限）。 現在のところ、Checkmk が監視に必要な API クエリは、Azure では（AWS とは対照的に）無料です。ただし、一定期間に許可されるクエリの数には制限があります（スロットリング制限）。

API の構造上、Checkmk は、要求されたリソースごとに 1 つ以上のクエリを必要とします。 したがって、クエリの総数は、監視対象のリソースの数に比例して増加します。 クエリの制限に達した場合、または制限を超えた場合、クエリは HTTP コード 429 (リクエストが多すぎます) で失敗し、Azure ホストの「Check_MK 」サービスは「CRIT 」としてフラグが付けられます。

この制限は、Azure のいわゆる「トークンバケット」アルゴリズムによるものです。 まず、250 件のクエリの「クレジット」が与えられます。クエリを実行するたびに、このクレジットが 1 件ずつ消費されます。 同時に、1 秒あたり 25 件のクエリがクレジットに追加されます。Azure Agent Info サービスの出力で、現在残っているクエリの数を確認できます。

具体的には、次のように機能します：

この場合、ポーリングするリソースグループまたはリソースの数を減らすか、Azure ホストの「Check_MK 」アクティブチェックのチェック間隔を短くして、ポーリングレートを下げることができます。 これは、Normal check interval for service checks ルールを使用して可能です。

タイムリーに対応できるよう、Azure Agent Info サービスは、残りのクエリの数を監視しています。 デフォルトでは、閾値は設定されていません。 これらは、ルールAzure Agent Info で自分で設定できます。

Microsoft Learn の記事「Azure Resource Manager がリクエストをスロットルする仕組み」で、この機能について詳しく説明しています。