次の方法で共有

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

  • [アーティクル]

適用対象: 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
  • 統合ランタイム

エラーと警告がチェックされている、SHIR 関連ログの選択のスクリーンショット。

重要

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

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

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

重要

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

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

Azure portal のカウンター選択インターフェイスのスクリーンショット。

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

Kusto 照会言語 (KQL) を使用して Azure Monitor ログまたは Log Analytics ストアにある監視データを分析する方法については、「Kusto クエリ」を参照してください。

テレメトリが保存される 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

関連するコンテンツ