Windows Azure Diagnostics を使用したイベントの集計と収集

Azure Service Fabric クラスターを実行している場合、1 か所ですべてのノードのログを収集することをお勧めします。 1 か所でログを収集すると、クラスター内の問題と、そのクラスターで実行されているアプリケーションやサービスで発生する問題の分析と解決に役立ちます。

ログをアップロードして収集する 1 つの方法として、Windows Azure Diagnostics (WAD) 拡張機能を使用します。この機能を使用すると、ログが Azure Storage にアップロードされますが、Azure Application Insights や Event Hubs にログを送信することもできます。 また、外部プロセスを使用してストレージからイベントを読み取り、Azure Monitor ログなどの分析プラットフォーム製品や別のログ解析ソリューションに配置することもできます。

Note

この記事では、Azure と対話するために推奨される PowerShell モジュールである Azure Az PowerShell モジュールを使用します。 Az PowerShell モジュールの使用を開始するには、Azure PowerShell のインストールに関するページを参照してください。 Az PowerShell モジュールに移行する方法については、「AzureRM から Az への Azure PowerShell の移行」を参照してください。

前提条件

この記事では、次のツールが使用されます。

Service Fabric プラットフォームのイベント

Service Fabric にはすぐに使用できるログ チャネルがいくつか用意されています。そのうち、次のチャネルは、監視および診断データをストレージ テーブルや他の場所に送信する拡張機能が事前に構成されています。

ポータルを使用して診断拡張機能をデプロイする

ログ収集の最初の手順は、Service Fabric クラスター内の仮想マシン スケール セット ノード上に診断拡張機能をデプロイすることです。 診断拡張機能を使用すると、各 VM のログが収集され、指定したストレージ アカウントにアップロードされます。 以下の手順は、Azure Portal と Azure Resource Manager テンプレートを使用して、新規と既存のクラスターでこれを行う方法を示しています。

Azure Portal を使用してクラスター作成の一環として診断拡張機能をデプロイする

クラスター構成手順の中でクラスターを作成する場合は、省略可能な設定を展開し、診断が [オン] (既定の設定) に設定されていることを確認します。

ポータルでのクラスター作成のための Azure Diagnostics 設定

最後の手順で [作成] をクリックする前にテンプレートをダウンロードしておくことを強くお勧めします。 詳細については、Azure Resource Manager テンプレートを使用して Service Fabric クラスターをセットアップする方法に関するページを参照してください。 データを収集するチャンネル (上記) を変更するためにテンプレートが必要です。

クラスター テンプレート

Azure Storage にイベントを集計するため、Azure Monitor ログ ポータルで、分析情報の取得とクエリを実行するように Azure Monitor ログを設定します。

Note

現在のところ、テーブルに送信されるイベントをフィルター処理したり調整したりする方法はありません。 テーブルからイベントを削除するプロセスを実装しない場合、テーブルは増加し続けます (既定の上限は 50 GB です)。 これを変更する方法については、この記事の中で後で説明します。 さらに、ウォッチドッグ サンプルで実行されるデータ グルーミング サービスの例があります。30 日または 90 日の期間を超えてログを保存する正当な理由がない限り、データ グルーミング サービスを自分で作成することをお勧めします。

Azure Resource Manager を使用して診断拡張機能をデプロイする

診断拡張機能付きのクラスターを作成する

Resource Manager を使用してクラスターを作成するには、診断構成 JSON を完全なクラスターの Resource Manager テンプレートに追加する必要があります。 ここでは、リソース マネージャー テンプレート サンプルの一部として、診断構成を追加した five-VM クラスター リソース マネージャー テンプレートのサンプルを用意しました。 このサンプルは、Azure サンプル ギャラリーの「 Five-node cluster with Diagnostics Resource Manager template sample」で参照できます。

Resource Manager テンプレートの診断設定を確認するには、azuredeploy.json ファイルを開き、IaaSDiagnostics を検索します。 このテンプレートを使用してクラスターを作成するには、前のリンクにある [Azure にデプロイ] ボタンをクリックしてください。

または、Resource Manager サンプルをダウンロードし、変更を加え、Azure PowerShell ウィンドウで New-AzResourceGroupDeployment コマンドを使用して、変更したテンプレートでクラスターを作成する方法もあります。 コマンドに渡すパラメーターについては、次のコードを参照してください。 PowerShell を利用してリソース グループをデプロイする方法については、Azure Resource Manager テンプレートを使用したリソース グループのデプロイに関する記事を参照してください。

既存のクラスターに診断拡張機能を追加する

まだ診断がデプロイされていない既存のクラスターがある場合は、クラスター テンプレートを使用して追加または更新を実行できます。 既存クラスターの作成に使用された Resource Manager テンプレートを変更するか、前の説明に基づき、ポータルからテンプレートをダウンロードします。 次のタスクを実行して、template.json ファイルを変更します。

リソース セクションを増やすことで新しいストレージ リソースをテンプレートに追加します。

{
	"apiVersion": "2018-07-01",
	"type": "Microsoft.Storage/storageAccounts",
	"name": "[parameters('applicationDiagnosticsStorageAccountName')]",
	"location": "[parameters('computeLocation')]",
	"sku": {
	"name": "[parameters('applicationDiagnosticsStorageAccountType')]"
	"tier": "standard"
  },
	"tags": {
	"resourceType": "Service Fabric",
	"clusterName": "[parameters('clusterName')]"
  }
},

次に、ストレージ アカウント定義の直後の supportLogStorageAccountName との間に、パラメーター セクションを追加します。 プレースホルダー テキストの storage account name goes here をストレージ アカウントの名前に置き換えます。

    "applicationDiagnosticsStorageAccountType": {
      "type": "string",
      "allowedValues": [
        "Standard_LRS",
        "Standard_GRS"
      ],
      "defaultValue": "Standard_LRS",
      "metadata": {
        "description": "Replication option for the application diagnostics storage account"
      }
    },
    "applicationDiagnosticsStorageAccountName": {
      "type": "string",
      "defaultValue": "**STORAGE ACCOUNT NAME GOES HERE**",
      "metadata": {
        "description": "Name for the storage account that contains application diagnostics data from the cluster"
      }
    },

extensions 配列内に次のコードを追加し、 template.json ファイルの VirtualMachineProfile セクションを更新します。 挿入箇所に合わせ、始めまたは終わりにコンマを追加します。

{
    "name": "[concat(parameters('vmNodeType0Name'),'_Microsoft.Insights.VMDiagnosticsSettings')]",
    "properties": {
        "type": "IaaSDiagnostics",
        "autoUpgradeMinorVersion": true,
        "protectedSettings": {
        "storageAccountName": "[parameters('applicationDiagnosticsStorageAccountName')]",
        "storageAccountKey": "[listKeys(resourceId('Microsoft.Storage/storageAccounts', parameters('applicationDiagnosticsStorageAccountName')),'2015-05-01-preview').key1]",
        "storageAccountEndPoint": "https://core.windows.net/"
        },
        "publisher": "Microsoft.Azure.Diagnostics",
        "settings": {
        "WadCfg": {
            "DiagnosticMonitorConfiguration": {
            "overallQuotaInMB": "50000",
            "EtwProviders": {
                "EtwEventSourceProviderConfiguration": [
                {
                    "provider": "Microsoft-ServiceFabric-Actors",
                    "scheduledTransferKeywordFilter": "1",
                    "scheduledTransferPeriod": "PT5M",
                    "DefaultEvents": {
                    "eventDestination": "ServiceFabricReliableActorEventTable"
                    }
                },
                {
                    "provider": "Microsoft-ServiceFabric-Services",
                    "scheduledTransferPeriod": "PT5M",
                    "DefaultEvents": {
                    "eventDestination": "ServiceFabricReliableServiceEventTable"
                    }
                }
                ],
                "EtwManifestProviderConfiguration": [
                {
                    "provider": "cbd93bc2-71e5-4566-b3a7-595d8eeca6e8",
                    "scheduledTransferLogLevelFilter": "Information",
                    "scheduledTransferKeywordFilter": "4611686018427387904",
                    "scheduledTransferPeriod": "PT5M",
                    "DefaultEvents": {
                    "eventDestination": "ServiceFabricSystemEventTable"
                    }
                },
                {
                    "provider": "02d06793-efeb-48c8-8f7f-09713309a810",
                    "scheduledTransferLogLevelFilter": "Information",
                    "scheduledTransferKeywordFilter": "4611686018427387904",
                    "scheduledTransferPeriod": "PT5M",
                    "DefaultEvents": {
                    "eventDestination": "ServiceFabricSystemEventTable"
                    }
                }
                ]
            }
            }
        },
        "StorageAccount": "[parameters('applicationDiagnosticsStorageAccountName')]"
        },
        "typeHandlerVersion": "1.5"
    }
}

前述のように template.json ファイルを変更したら、Resource Manager テンプレートを再発行します。 テンプレートのエクスポート後、deploy.ps1 ファイルを実行すると、テンプレートが再発行されます。 デプロイ後、ProvisioningStateSucceeded になっていることを確認します。

ヒント

使用しているクラスターにコンテナーをデプロイする場合は、WAD を有効にして、ご自身の WadCfg DiagnosticMonitorConfiguration セクションに次のコードを追加し、Docker の統計情報を取得します。

"DockerSources": {
    "Stats": {
        "enabled": true,
        "sampleRate": "PT1M"
    }
},

ストレージ クォータを更新する

拡張機能によってデータが入力されるテーブルは、クォータに達するまで大きくなり続けるため、クォータ サイズの縮小を検討できます。 既定値は 50 GB です。この値は、テンプレートの DiagnosticMonitorConfiguration の下の overallQuotaInMB フィールドで構成可能です。

"overallQuotaInMB": "50000",

ログ収集の構成

追加チャネルのログも収集できます。Azure で実行されているクラスターを対象とした、テンプレートで作成できる最も一般的な構成をいくつか次に示します。

  • 稼働チャネル - 基本: 既定で有効。Service Fabric とクラスターで実行される高度な操作。ノードの起動、新しいアプリケーションのデプロイ、アップグレードのロールバックなどのイベントが含まれます。イベントの一覧については、稼働チャネル イベントに関するページを参照してください。
      scheduledTransferKeywordFilter: "4611686018427387904"
  • 稼働チャネル - 詳細: 正常性レポートと負荷分散の決定、および基本稼働チャネルのすべてが含まれます。 これらのイベントは、ReportPartitionHealthReportLoad などの正常性または負荷レポート API を使うことで、システムまたはユーザーのコードのいずれかによって生成されます。 Visual Studio の診断イベント ビューアーでこれらのイベントを表示するには、ETW プロバイダーのリストに "Microsoft-ServiceFabric:4:0x4000000000000008" を追加します。
      scheduledTransferKeywordFilter: "4611686018427387912"
  • データおよびメッセージング チャネル - 基本: 詳細な稼働チャネル ログに加えて、メッセージング (現時点では ReverseProxy のみ) とデータ パスで生成された重要なログおよびイベント。 これらのイベントには、ReverseProxy で発生した要求処理エラーや他の重要な問題に加え、処理された要求も含まれます。 包括的なログ記録のための推奨構成です。 Visual Studio の診断イベント ビューアーでこれらのイベントを表示するには、ETW プロバイダーのリストに "Microsoft-ServiceFabric:4:0x4000000000000010" を追加します。
      scheduledTransferKeywordFilter: "4611686018427387928"
  • データおよびメッセージング チャネル - 詳細: クラスター内のデータおよびメッセージングからの重大でないすべてのログを含む詳細チャネル、および詳細稼働チャネル。 すべてのリバース プロキシ イベントの詳細なトラブルシューティングについては、リバース プロキシの診断ガイドを参照してください。 Visual Studio の診断イベント ビューアーでこれらのイベントを表示するには、ETW プロバイダーのリストに "Microsoft-ServiceFabric:4:0x4000000000000020" を追加します。
      scheduledTransferKeywordFilter: "4611686018427387944"

Note

このチャネルには大量のイベントが含まれているため、この詳細チャネルからのイベント収集を有効にすると、大量のトレースが短時間で生成され、ストレージ容量を消費する可能性があります。 これを有効にするのは、どうしても必要な場合だけにしてください。

最小限のノイズで包括的なログを記録するための推奨構成である基本的な稼働チャネルを有効にするには、テンプレートの WadCfg は次のようになります。

  "WadCfg": {
        "DiagnosticMonitorConfiguration": {
          "overallQuotaInMB": "50000",
          "EtwProviders": {
            "EtwEventSourceProviderConfiguration": [
              {
                "provider": "Microsoft-ServiceFabric-Actors",
                "scheduledTransferKeywordFilter": "1",
                "scheduledTransferPeriod": "PT5M",
                "DefaultEvents": {
                  "eventDestination": "ServiceFabricReliableActorEventTable"
                }
              },
              {
                "provider": "Microsoft-ServiceFabric-Services",
                "scheduledTransferPeriod": "PT5M",
                "DefaultEvents": {
                  "eventDestination": "ServiceFabricReliableServiceEventTable"
                }
              }
            ],
            "EtwManifestProviderConfiguration": [
              {
                "provider": "cbd93bc2-71e5-4566-b3a7-595d8eeca6e8",
                "scheduledTransferLogLevelFilter": "Information",
                "scheduledTransferKeywordFilter": "4611686018427387904",
                "scheduledTransferPeriod": "PT5M",
                "DefaultEvents": {
                  "eventDestination": "ServiceFabricSystemEventTable"
                }
              },
              {
                "provider": "02d06793-efeb-48c8-8f7f-09713309a810",
                "scheduledTransferLogLevelFilter": "Information",
                "scheduledTransferKeywordFilter": "4611686018427387904",
                "scheduledTransferPeriod": "PT5M",
                "DefaultEvents": {
                "eventDestination": "ServiceFabricSystemEventTable"
                }
              }
            ]
          }
        }
      },

新しい EventSource チャネルから収集する

デプロイしようとしている新しいアプリケーションを表す新しい EventSource チャネルからログを収集するように診断を更新するには、前述の既存のクラスターの診断を設定する場合と同じ手順を実行します。

template.json ファイル内の EtwEventSourceProviderConfiguration セクションを更新して、新しい EventSource チャネル用のエントリを追加してから、New-AzResourceGroupDeployment PowerShell コマンドを使用して構成の更新を適用します。 イベント ソースの名前は、Visual Studio で生成された ServiceEventSource.cs ファイル内でコードの一部として定義されます。

たとえば、イベント ソースの名前が My-Eventsource である場合、My-Eventsource からのイベントを MyDestinationTableName という名前のテーブルに配置するには次のコードを追加します。

        {
            "provider": "My-Eventsource",
            "scheduledTransferPeriod": "PT5M",
            "DefaultEvents": {
            "eventDestination": "MyDestinationTableName"
            }
        }

パフォーマンス カウンターまたはイベント ログを収集するには、「Azure リソース マネージャー テンプレートを使用して監視および診断を含む Windows 仮想マシンを登録する」に記載されている例を使用して Resource Manager テンプレートを変更します。 その後、Resource Manager テンプレートを再発行します。

パフォーマンス カウンターを収集する

クラスターからパフォーマンス メトリックを収集するには、クラスターの Resource Manager テンプレートの "WadCfg > DiagnosticMonitorConfiguration" にパフォーマンス カウンターを追加します。 を変更して特定のパフォーマンス カウンターを収集する手順については、WAD を使用したパフォーマンスの監視に関するページを参照してください。 収集が推奨されるパフォーマンス カウンターの一覧については、Service Fabric のパフォーマンス カウンターに関するページを参照してください。

次のセクションで説明するように、Application Insights のシンクを使用しており、これらのメトリックを Application Insights に表示する場合は、上記の "sinks" セクションにシンク名を追加する必要があります。 これにより、Application Insights リソースに個別に構成されているパフォーマンス カウンターが自動的に送信されます。

ログを Application Insights に送信する

WAD を使用した Application Insights の構成

Note

これは現在、Windows クラスターにのみ当てはまります。

WAD から Azure Application Insights にデータを送信するには Application Insights シンクを WAD 構成に追加しますが、これには主に Azure portal から行う方法と Azure Resource Manager テンプレートから行う方法があります。

Azure portal でクラスターを作成するときに、Application Insights のインストルメンテーション キーを追加する

AIKey の追加

クラスターを作成するときに、診断が "オン" になっている場合、Application Insights のインストルメンテーション キーを入力するオプションのフィールドが表示されます。 ここに Application Insights のキーを貼り付けると、クラスターの展開に使用される Resource Manager テンプレートで、Application Insights シンクが自動的に構成されます。

Resource Manager テンプレートに Application Insights シンクを追加する

Resource Manager テンプレートの "WadCfg" に、次の 2 つの変更を含めることによって "シンク" を追加します。

  1. DiagnosticMonitorConfiguration の宣言の完了直後にシンク構成を追加します。

    "SinksConfig": {
        "Sink": [
            {
                "name": "applicationInsights",
                "ApplicationInsights": "***ADD INSTRUMENTATION KEY HERE***"
            }
        ]
    }
    
    
  2. DiagnosticMonitorConfiguration にシンクを含めます。WadCfgDiagnosticMonitorConfiguration に次の行を追加します (EtwProviders の宣言の直前に)。

    "sinks": "applicationInsights"
    

上記の両方のコード スニペットには、シンクを記述するために "applicationInsights" という名前が使用されていました。 これは要件ではなく、シンクの名前が "sinks" に含まれている限り、任意の文字列で名前を設定できます。

現時点では、クラスターのログは Application Insights のログ ビューアーにトレースとして表示されます。 プラットフォームからのトレースのほとんどは "情報" レベルであるため、シンクの構成を変更して "警告" または "エラー" タイプのログのみを送信することも検討できます。これは、この記事で説明するように、シンクに "チャネル" を追加することで実現できます。

Note

ポータルまたは Resource Manager テンプレートのいずれかで間違った Application Insights キーを使用した場合、手動でキーを変更してクラスターを更新するか、再デプロイする必要があります。

次のステップ

Azure Diagnostics を正しく構成すると、ETW ログと EventSource ログのデータがストレージ テーブルに表示されます。 Azure Monitor ログ、Kibana、または Resource Manager テンプレートで直接構成されていないその他のデータ分析および視覚化プラットフォームを使用する場合は、これらのストレージ テーブルからデータを読み取るように、選択したプラットフォームを設定する必要があります。 Azure Monitor ログでこれを行うのは比較的簡単です。方法については、イベントとログの分析に関する記事を参照してください。 Application Insights は、診断拡張機能の構成の一部として構成できるので、少し特殊と言えます。AI を使用する場合は、こちらの記事をご覧ください。

Note

現在のところ、テーブルに送信されるイベントを絞り込む方法はありません。 テーブルからイベントを削除するプロセスを実装しない場合、テーブルは増加を続けます。 現在、ウォッチドッグ サンプルで実行されるデータ グルーミング サービスの例があります。30 日または 90 日の期間を超えてログを保存する正当な理由がない限り、データ グルーミング サービスを自分で作成することをお勧めします。