ログ分析収集用にセルフホステッド統合ランタイム (SHIR) を構成する

[アーティクル]
01/05/2024

適用対象: Azure Data Factory Azure Synapse Analytics

ヒント

企業向けのオールインワン分析ソリューション、Microsoft Fabric の Data Factory をお試しください。 Microsoft Fabric は、データ移動からデータサイエンス、リアルタイム分析、ビジネスインテリジェンス、レポートまで、あらゆるものをカバーしています。無料で新しい試用版を開始する方法について説明します。

前提条件

この方法には、使用可能な Log Analytics ワークスペースが必要です。特定のシナリオで必要になる可能性があるため、Log Analytics ワークスペースのワークスペース ID と認証キーをメモしておくことをお勧めします。このソリューションにより、Log Analytics ワークスペースに送信されるデータが増加し、全体的なコストに小さい影響があります。最小限のデータ量を保つ方法の詳細については、この後で説明します。

目標とシナリオ

イベントとパフォーマンスカウンターデータを Log Analytics ワークスペースに一元化します。まず、SHIR のホストである仮想マシンを適切にインストルメント化する必要があります。次の 2 つの主なシナリオのいずれかを選択します。

オンプレミスの仮想マシンをインストルメント化する

記事「Log Analytics エージェントを Windows コンピューターにインストールする」では、一般的にオンプレミスでホストされる仮想マシンにクライアントをインストールする方法を説明しています。これは、物理サーバー、またはお客様が管理するハイパーバイザーでホストされる仮想マシンです。前提条件のセクションで説明したように、Log Analytics エージェントをインストールするときに、Log Analytics ワークスペース ID とワークスペースキーを指定して接続を完了する必要があります。

Azure 仮想マシンをインストルメント化する

Azure 仮想マシンベースの SHIR のインストルメント化で、推奨される方法は、記事「VM 分析情報の有効化の概要」で説明している、仮想マシンの分析情報を使用することです。 SHIR が Azure 仮想マシンでホストされているときに Log Analytics エージェントを構成する方法は、複数あります。記事「Log Analytics エージェントの概要」では、そのすべてについて説明しています。

イベントログとパフォーマンスカウンターキャプチャを構成する

この手順では、Log Analytics に送信されるイベントビューアーログとパフォーマンスカウンターの両方を構成する方法を説明します。以下に示すのは、エージェントのデプロイ方法に関係なく、一般的な手順です。

イベントビューアーのジャーナルを選択する

まず、記事「Azure Monitor で Log Analytics エージェントを使用して Windows イベントログデータソースを収集する」の説明に従って、SHIR に関連するイベントビューアージャーナルを収集する必要があります。

インターフェイスを使用してイベントログを選択するときに、マシンに存在する可能性のある一部のジャーナルが表示されないのは、異常ではありません。そのため、SHIR 監視に必要な 2 つのジャーナルは、この一覧に表示されていません。ローカル仮想マシンに表示されるとおりにジャーナル名を入力すると、その名前がキャプチャされ、Log Analytics ワークスペースに送信されます。

構成する必要のあるイベントジャーナルの名前は、次のとおりです。

Connectors – Integration Runtime
統合ランタイム

Screenshot of the selection of the SHIR relevant logs with errors and warnings checked.

重要

[情報] レベルをオンのままにすると、デプロイした SHIR ホストの数が多く、スキャンの数がさらに多い場合は、データの量が大幅に増加します。エラーと警告のみを保持することを強く推奨します。

パフォーマンスカウンターを選択する

同じ構成ウィンドウで、[Windows パフォーマンスカウンター] をクリックして、ログ分析に送信する個々のパフォーマンスカウンターを選択できます。

重要

パフォーマンスカウンターは、その性質上、継続的なデータストリームであることを憶えておいてください。したがって、Azure Monitor/Log Analytics のデプロイの総コストにデータ収集が及ぼす影響を考慮することが重要です。許可されるデータインジェスト予算が承認されていると同時に、継続的なデータインジェストが許可され、その予算が承認されていない限り、パフォーマンスカウンターの収集を、定義された期間に対してのみ構成してパフォーマンスベースラインを確立する必要があります。

インターフェイスでは、最初に構成するときに、一定のカウンターセットが推奨されます。実行するパフォーマンス分析の種類に該当する値を選択します。 [%CPU] と [使用可能なメモリ] は、一般的に監視されるカウンターですが、[ネットワーク帯域幅の消費] などの他のカウンターは、データボリュームが大きく、帯域幅や実行時間が制限されているシナリオで役立つ場合があります。

Screenshot of the counter selection interface in the Azure portal.

Log Analytics でイベントとパフォーマンスカウンターデータを表示する

Log Analytics でデータにクエリを実行する方法に関する記事で、このチュートリアルを参照してください。テレメトリが保存される 2 つのテーブルはそれぞれ、Perf および Event と呼ばれます。次のクエリでは、行数を確認して、データの取り込み中であるかどうかを調べます。これにより、上記のインストルメント化が機能しているかどうかが確認されます。

サンプル KQL クエリ

行数を確認する

(
        Event 
        | extend TableName = "Event"
        | summarize count() by TableName
)     
| union
(     
        Perf
        | extend TableName = "Perf"
        | summarize count() by TableName
)

イベントにクエリを実行する

最初の 10 行のイベントを取得する

Event
| take 10

メッセージの重大度別のイベント数を取得する

Event
| summarize count() by EventLevelName

メッセージの重大度別のイベント数の円グラフをレンダリングする

Event
| summarize count() by EventLevelName
| render piechart

特定のテキスト文字列を含むすべてのエラーを取得する

ここでは、disconnected という単語を含むすべてのメッセージを検索しています。

Event
| where RenderedDescription has "disconnected"

スキーマがわからない場合にキーワードを複数テーブル検索する

検索コマンドは、情報が含まれている列がわからない場合に便利です。このクエリでは、検索用語を含む列が少なくとも 1 つ含まれる、指定したテーブルのすべての行が返されます。この例では、その用語はdisconnected です。

search in (Perf, Event) "disconnected"

特定の 1 つのログジャーナルのすべてのイベントを取得する

この例では、Connectors - Integration Runtime という名前のログジャーナルにクエリを絞り込んでいます。

Event 
| where EventLog == "Connectors - Integration Runtime"

期間を使用してクエリ結果を制限する

このクエリでは、上記と同じクエリを使用しますが、結果が、2 日以上前に発生したイベントに制限されます。

Event 
| where EventLog      == "Connectors - Integration Runtime"
  and   TimeGenerated >= ago(2d)

パフォーマンスカウンターデータを問い合わせる

最初の 10 個のパフォーマンスカウンターの読み取り値を取得する

Perf
| take 10

時間の制約のある特定のカウンターを取得する

Perf
| where     TimeGenerated >= ago(24h)
        and ObjectName    == "Network Adapter"
        and InstanceName  == "Mellanox ConnectX-4 Lx Virtual Ethernet Adapter"
        and CounterName   == "Bytes Received/sec"

パフォーマンスカウンターは、本質的に階層構造であるため、十分な数の where 述語をクエリに含めて、必要な特定のカウンターのみを選択するようにしてください。

過去 24 時間の 30 分スライスでビン分割された特定のカウンターの 95 パーセンタイルを取得する

この例は、特定のネットワークアダプターのすべてのカウンターです。

Perf
| where     TimeGenerated >= ago(24h)
        and ObjectName    == "Network Adapter"
        and InstanceName  == "Mellanox ConnectX-4 Lx Virtual Ethernet Adapter"
| project TimeGenerated, Computer, ObjectName, InstanceName, CounterName, CounterValue
| summarize percentile(CounterValue, 95) by bin(TimeGenerated, 30m), Computer, ObjectName, InstanceName, CounterName

コードを再利用するために変数を使用する

ここでは、オブジェクト名とカウンター名を変数にしています。これで、後で変数を変更する場合に KQL クエリ本文を変更する必要がなくなります。

let pObjectName  = "Memory"; // Required to select the right counter
let pCounterName = "Available MBytes"; // Required to select the right counter
Perf
| where Type == "Perf" and ObjectName == pObjectName and CounterName == pCounterName
| project TimeGenerated, Computer, CounterName, CounterValue
| order by TimeGenerated asc 
| summarize Value=max(CounterValue) by CounterName, TimeStamps=TimeGenerated