エッジでの Azure Monitor パイプラインの構成

Azure Monitor パイプラインは、Azure Monitor 用の一貫性のある一元化されたデータ収集を提供するデータ インジェスト パイプラインです。 エッジのパイプラインでは大規模な収集が可能になり、クラウドに送信する前にテレメトリ データのルーティングができます。 接続が復元した時点でデータをローカルにキャッシュし、クラウドと同期し、ネットワークがセグメント化され、データをクラウドに直接送信できない場合は、テレメトリを Azure Monitor にルーティングできます。 この記事では、環境内でエッジのパイプラインを有効化して構成する方法について説明します。

概要

Azure Monitor のエッジのパイプラインは、Arc 対応 Kubernetes クラスターにデプロイされ、OpenTelemetry Collector を基盤として活用するコンテナー化されたソリューションです。 次の図は、エッジのパイプラインのコンポーネントを示しています。 1 つ以上のデータ フローがクライアントからの受信データをリッスンし、パイプライン拡張機能が必要に応じてローカル キャッシュを使用して、データをクラウドに転送します。

パイプライン構成ファイルは、エッジのパイプラインのデータ フローとキャッシュ プロパティを定義します。 DCR は、クラウド パイプラインに送信されるデータのスキーマ、データをフィルター処理または変更するための変換、およびデータの送信先を定義します。 パイプライン構成の各データ フロー定義では、DCR に加え、クラウド パイプラインでそのデータを処理する DCR 内のストリームを指定します。

Azure Monitor エッジでのパイプラインのデータフローの概要図。

Note

クラウド パイプラインへの接続の際に、プライベート リンクがエッジのパイプラインによってサポートされます。

Azure Monitor エッジのパイプラインを有効化するには、次のコンポーネントと構成が必要です。 Azure portal を使用してエッジのパイプラインを構成する場合は、これらの各コンポーネントが自動的に作成されます。 その他の方法を使用する場合は、それぞれを構成する必要があります。

コンポーネント 説明
エッジ パイプライン コントローラー拡張機能 パイプライン機能をサポートするために Arc 対応 Kubernetes クラスターに拡張機能が追加されました - microsoft.monitor.pipelinecontroller
エッジ パイプライン コントローラー インスタンス Arc 対応 Kubernetes クラスターで稼働するエッジ パイプラインのインスタンス。
データ フロー パイプライン コントローラー インスタンスで稼働するレシーバーとエクスポーターの組み合わせ。 レシーバーはクライアントからのデータを受け入れ、エクスポーターはそのデータを Azure Monitor に提供します。
パイプラインの構成 パイプライン インスタンスのデータ フローを定義する構成ファイル。 各データ フローには、レシーバーとエクスポーターが含まれます。 レシーバーは受信データをリッスンし、エクスポーターはデータを宛先に送信します。
データ収集エンドポイント (DCE) データが Azure Monitor パイプラインに送信されるエンドポイント。 パイプライン構成には DCE の URL のプロパティが含まれるため、パイプライン インスタンスはデータの送信先を認識します。
構成 説明
データ収集ルール (DCR) クラウド パイプラインでのデータの受信方法と送信先を定義する構成ファイル。 DCR には、宛先に送信する前にデータをフィルター処理または変更する変換を含めることもできます。
パイプラインの構成 データ フローとキャッシュを含むパイプライン インスタンスのデータ フローを定義する構成。

サポートされている構成

サポートされているディストリビューション
エッジの Azure Monitor パイプラインは、次の Kubernetes ディストリビューションでサポートされています。

  • Canonical
  • Azure 用のクラスター API プロバイダー
  • K3
  • Rancher Kubernetes Engine
  • VMware Tanzu Kubernetes Grid

サポートされる場所
エッジの Azure Monitor パイプラインは、次の Azure リージョンでサポートされています。

  • 米国東部 2
  • 米国西部 2
  • 西ヨーロッパ

前提条件

ワークフロー

Azure portal を使用して構成するために、Azure Monitor パイプラインによって実行されるさまざまな手順について詳しく理解する必要はありません。 ただし、別のインストール方法を使用する場合や、データを宛先に保存する前にデータを変換するなど、より高度な構成を実行する必要がある場合は、より詳細な理解が必要になる場合があります。

次の表と図では、エッジのパイプラインを使用してデータを収集し、Azure Monitor で保存するためにクラウド パイプラインに渡すプロセスの詳細な手順とコンポーネントについて説明します。 また、これらの各コンポーネントに必要な構成も表に含まれています。

Step アクション サポートする構成
1. クライアントがエッジ パイプライン レシーバーにデータを送信する。 クライアントはエッジ パイプラインのレシーバーの IP とポートで構成され、レシーバーの種類に対して想定される形式でデータを送信します。
2. レシーバーがエクスポーターにデータを転送する。 レシーバーとエクスポーターが、同じパイプライン内に構成されます。
3. エクスポーターがクラウド パイプラインにデータを送信しようとする。 パイプライン構成内のエクスポーターには、DCE の URL、DCR の一意識別子、およびデータの処理方法を定義する DCR 内のストリームが含まれます。
3a. エクスポーターが DCE に接続できない場合、ローカル キャッシュにデータを保存する。 キャッシュの永続ボリュームとローカル キャッシュの構成が、パイプライン構成で有効化されます。

Azure Monitor のエッジのパイプラインを使用したデータ収集の手順とコンポーネントの詳細図。

手順 アクション サポートする構成
4. クラウド パイプラインが受信データを受け入れる。 DCR には、エッジのパイプラインから送信されるデータのスキーマと一致する必要がある受信ストリームのスキーマ定義が含まれます。
5. クラウド パイプラインがデータに変換を適用する。 DCR には、宛先に送信する前にデータをフィルター処理または変更する変換が含まれます。 変換では、データをフィルター処理し、列を削除または追加し、スキーマを完全に変更することがあります。 変換の出力は、宛先テーブルのスキーマと一致する必要があります。
6. クラウド パイプラインが宛先にデータを送信する。 DCR には、データが保存される Log Analytics ワークスペースとテーブルを指定する宛先が含まれます。

Azure Monitor クラウド パイプラインを使用したデータ収集の手順とコンポーネントの詳細図。

セグメント化されたネットワーク

ネットワークのセグメント化とは、ソフトウェア定義の境界を使用して、ネットワークのさまざまな部分に対して異なるセキュリティ体制を作成するモデルです。 このモデルでは、インターネットや他のネットワーク セグメントに接続できないネットワーク セグメントがある場合があります。 エッジのパイプラインを使用して、これらのネットワーク セグメントからデータを収集し、クラウド パイプラインに送信できます。

Azure Monitor エッジのパイプラインのレイヤード ネットワークの図。

レイヤード ネットワーク構成で Azure Monitor パイプラインを使用するには、Arc 対応 Kubernetes クラスターの許可リストに次のエントリを追加する必要があります。 「レベル 4 のクラスターで Azure IoT Layered Network Management プレビューを構成する」を参照してください。

- destinationUrl: "*.ingest.monitor.azure.com"
  destinationType: external
- destinationUrl: "login.windows.net"
  destinationType: external

Log Analytics ワークスペースでテーブルを作成する

エッジのパイプライン用にデータ収集プロセスを構成する前に、Log Analytics ワークスペースにデータを受信するためのテーブルを作成する必要があります。 組み込みテーブルは現在サポートされていないため、これはカスタム テーブルである必要があります。 テーブルのスキーマは受信するデータと一致する必要がありますが、収集プロセスには受信データを変更できる複数の手順があるため、テーブル スキーマは収集するソース データと一致する必要はありません。 Log Analytics ワークスペースのテーブルの唯一の要件は、TimeGenerated 列があることです。

テーブルを作成するためのさまざまな方法の詳細については、「Azure Monitor ログのテーブルと列を追加または削除する」を参照してください。 たとえば、次の CLI コマンドを使用して、BodyTimeGenerated、および SeverityText という 3 つの列を含むテーブルを作成します。

az monitor log-analytics workspace table create --workspace-name my-workspace --resource-group my-resource-group  --name my-table_CL --columns TimeGenerated=datetime Body=string SeverityText=string

キャッシュを有効化する

一部の環境のエッジ デバイスでは、ネットワークの輻輳、信号の干渉、停電、モビリティなどのさまざまな要因により断続的な接続が発生する場合があります。 これらの環境では、クラスターに永続ボリュームを作成することで、データをキャッシュするようにエッジのパイプラインを構成できます。 このプロセスは特定の環境によって異なりますが、構成は次の要件を満たす必要があります。

  • メタデータ名前空間が、Azure Monitor パイプラインの指定されたインスタンスと同じである必要がある。
  • アクセス モードが ReadWriteMany をサポートする必要がある。

適切な名前空間にボリュームが作成されたら、以下のパイプライン構成ファイルのパラメータを使用してボリュームを構成します。

注意事項

エッジ パイプラインの各レプリカは、そのレプリカに固有の永続ボリューム内の場所にデータを保存します。 クラスターがクラウドから切断されている間にレプリカの数を減らすと、接続の復元時にそのデータがバックフィルされなくなります。

データは、先入れ先出し法 (FIFO) を使用してキャッシュから取得されます。 48 時間以上前のデータはすべて破棄されます。

パイプラインを有効化して構成する

有効化と構成に関する現在のオプションについては、以下のタブで詳しく説明します。

Azure portal を使用してパイプラインを構成する

Azure portal を使用してパイプラインを有効化して構成すると、選択内容に基づいて必要なすべてのコンポーネントが作成されます。 これにより、各コンポーネントを個別に作成する複雑さが軽減されますが、他の方法を使用する必要があることがあります。

Azure portal で次のいずれかを実行して、Azure Monitor パイプラインのインストール プロセスを起動します。

  • [Azure Monitor パイプライン (プレビュー)] メニューから [作成] をクリックします。
  • Arc 対応 Kubernetes クラスターのメニューから、[拡張機能] を選択し、[Azure Monitor パイプライン拡張機能 (プレビュー)] 拡張機能を追加します。

[Basic] タブで、クラスターに拡張機能とパイプライン インスタンスをデプロイするための次の情報が求められます。

[Azure Monitor パイプラインの作成] 画面のスクリーンショット。

このタブの設定を次の表で説明します。

プロパティ 説明
インスタンス名 Azure Monitor パイプライン インスタンスの名前。 サブスクリプションに対して一意である必要があります。
サブスクリプション パイプライン インスタンスを作成する Azure サブスクリプション。
リソース グループ パイプライン インスタンスを作成するリソース グループ。
クラスター名 パイプラインがインストールされる Arc 対応 Kubernetes クラスターを選択します。
カスタムの場所 Arc 対応 Kubernetes クラスターのカスタムの場所。 これには、クラスター用に作成されるカスタムの場所の名前が自動的に設定されます。または、クラスター内の別のカスタムの場所を選択できます。

[データフロー] タブでは、パイプライン インスタンス用のデータフローを作成および編集できます。 各データフローには、次の詳細情報が含まれます。

[データフローの作成と追加] 画面のスクリーンショット。

このタブの設定を次の表で説明します。

プロパティ 内容
Name データフローの名前。 このパイプラインに対して一意である必要があります。
変換元の型 収集されるデータの種類。 現在は、次のソースの種類がサポートされています。
- Syslog
- OTLP
ポート パイプラインが受信データをリッスンするポート。 2 つのデータフローが同じポートを使用する場合、データの受信と処理の両方を実施します。
Log Analytics ワークスペース データの送信先の Log Analytics ワークスペース。
テーブル名 データの送信先の Log Analytics ワークスペース内のテーブルの名前。

構成の確認

クラスターで稼働しているパイプライン コンポーネントを確認する

Azure portal で [Kubernetes サービス] メニューに移動し、Arc 対応 Kubernetes クラスターを選択します。 [サービスとイングレス] を選択し、次のサービスが表示されていることを確認します。

  • <パイプライン名>-external-service
  • <パイプライン名>-service

Azure Monitor のエッジのパイプラインをサポートするクラスター コンポーネントのスクリーンショット。

<パイプライン名>-external-service のエントリをクリックし、[エンドポイント] 列の IP アドレスとポートを確認します。 これは、クライアントがデータを送信する先の外部 IP アドレスとポートです。 クライアントからこのアドレスを取得する方法については、「イングレス エンドポイントを取得する」を参照してください。

ハートビートを確認する

パイプライン インスタンスで構成された各パイプラインは、毎分 Log Analytics ワークスペースの Heartbeat テーブルにハートビート レコードを送信します。 OSMajorVersion 列の内容は、パイプライン インスタンスの名前と一致する必要があります。 パイプライン インスタンスに複数のワークスペースがある場合は、最初に構成されたワークスペースが使用されます。

次の例のように、ログ クエリを使用してハートビート レコードを取得します。

Azure Monitor のエッジのパイプライン用にハートビート レコードを返すログ クエリのスクリーンショット。

クライアントの構成

エッジ パイプライン拡張機能とインスタンスがインストールされると、パイプラインにデータを送信するようにクライアントを構成する必要があります。

イングレス エンドポイントを取得する

各クライアントには、Azure Monitor パイプライン サービスの外部 IP アドレスが必要です。 次のコマンドを使用して、このアドレスを取得します。

kubectl get services -n <namespace where azure monitor pipeline was installed>
  • ログを生成するアプリケーションがクラスターの外部にある場合は、ロード バランサーの種類とともに、サービスの <パイプライン名>-service または <パイプライン名>-external-service の external-ip 値をコピーします。
  • アプリケーションがクラスター内のポッド上にある場合は、cluster-ip 値をコピーします。

Note

external-ip フィールドが pending に設定されている場合は、クラスターの構成に従って、このイングレスの外部 IP を手動で構成する必要があります。

クライアント 説明
syslog Syslog クライアントを更新して、パイプライン エンドポイントと Syslog データフローのポートにデータを送信します。
OTLP Azure Monitor エッジ パイプラインは、ポート 4317 で gRPC ベースの OTLP エンドポイントを公開します。 この OTLP エンドポイントに送信するようにインストルメンテーションを構成する方法は、インストルメンテーション ライブラリ自体によって異なります。 OpenTelemetry のドキュメントについては、「OTLP エンドポイントまたはコレクター」を参照してください。 環境変数の方法は、「OTLP エクスポーターの構成」に記載されています。

データの確認

最後の手順では、Log Analytics ワークスペースでデータが受信されたことを確認します。 この確認を実行するには、Log Analytics ワークスペースでクエリを実行して、テーブルからデータを取得します。

Syslog コレクションを返すログ クエリのスクリーンショット。

次のステップ