Azure Functions の監視を構成する方法

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

Azure Functions が Application Insights に統合されると、関数アプリの監視をより適切に行うことができます。 Azure Monitor の機能である Application Insights は、アプリがログに書き込む情報など、関数アプリによって生成されたデータを収集する拡張可能なアプリケーションパフォーマンス管理 (APM) サービスです。 Application Insights との統合は、通常、関数アプリが作成されるときに有効になります。アプリにインストルメンテーションキーが設定されていない場合は、まず Application Insights との統合を有効にする必要があります。

Application Insights はカスタム構成なしで使用できます。既定の構成ではデータ量が多くなる可能性があります。 Visual Studio Azure サブスクリプションを使っている場合、Application Insights のデータ上限に達する可能性があります。 Application Insights のコストについては、「Application Insights の課金」をご覧ください。詳細については、「テレメトリの量が多いソリューション」を参照してください。

この記事の後半では、関数から Application Insights に送信するデータを構成し、カスタマイズする方法を説明します。一般的なログ構成は host.json ファイルに設定できます。既定では、これらの設定により、独自のコードで出力されるカスタムログも制御されますが、場合によっては、この動作を無効にして、ログをより細かく制御できるオプションを使用することもできます。詳しくは、「カスタムアプリケーションログ」をご覧ください。

注意

特別に構成されたアプリケーション設定を使用すれば、特定の環境の host.json ファイル内の特定の設定を表すことができます。これにより、プロジェクトで host.json ファイルを再発行しなくても、host.json 設定を効果的に変更できます。詳細については、「host.json 値をオーバーライドする」を参照してください。

カスタムアプリケーションログ

既定では、書き込まれたカスタムアプリケーションログは Functions ホストに送信され、"Worker" カテゴリを介して Application Insights に送信されます。いくつかの言語スタックでは、ログを Application Insights に直接送信することができ、書き込んだログの出力方法を完全に制御できます。ログパイプラインが worker -> Functions host -> Application Insights から worker -> Application Insights に変更されます。

次の表は、各スタックで使用できるオプションをまとめたものです。

言語スタック	カスタムログの構成
.NET (インプロセスモデル)	`host.json`
.NET (分離モデル)	既定値: `host.json` ログを直接送信するオプション: HostBuilder で Application Insights を構成する
Node.JS	`host.json`
Python	`host.json`
Java	既定値: `host.json` ログを直接送信するオプション: Application Insights Java エージェントを構成する
PowerShell	`host.json`

カスタムアプリケーションログが直接送信されると、ホストはログを出力しなくなり、host.json はログの動作を制御しなくなります。同様に、各スタックによって公開されるオプションはカスタムログにのみ適用され、この記事で説明する他のランタイムログの動作を変更することはありません。すべてのログの動作を制御するには、両方の構成に変更を加える必要があります。

カテゴリを構成する

Azure Functions のロガーでは、すべてのログにカテゴリがあります。カテゴリは、ランタイムコードや関数コードのどの部分にログが記述されているかを示します。バージョン 1.x とそれ以降のバージョンとでは、カテゴリが異なります。

カテゴリ名は、他の .NET フレームワークとは異なる方法で関数に割り当てられます。たとえば、ASP.NET で ILogger<T> を使用する場合、カテゴリはジェネリック型の名前になります。 C# 関数も ILogger<T> を使用しますが、ジェネリック型名をカテゴリとして設定する代わりに、ランタイムはソースに基づいてカテゴリを割り当てます。次に例を示します。

関数の実行に関連するエントリには、Function.<FUNCTION_NAME> カテゴリが割り当てられます。
logger.LogInformation() の呼び出し時など、関数内のユーザーコードによって作成されたエントリには、Function.<FUNCTION_NAME>.User カテゴリが割り当てられます。

以下のチャートは、ランタイムが作成するログの主なカテゴリについて説明します。

v2.x+
v1.x

カテゴリ	テーブル	説明
`Function`	traces	すべての関数実行の関数の開始ログと完了したログが含まれます。正常に実行された場合、これらのログは `Information` レベルとなります。例外は `Error` レベルでログされます。また、キューメッセージが有害キューに送信されたといったような場合には、ランタイムによって `Warning` レベルのログも作成されます。
`Function.<YOUR_FUNCTION_NAME>`	dependencies	一部のサービスについては、依存関係データが自動的に収集されます。正常に実行された場合、これらのログは `Information` レベルとなります。詳しくは、「依存関係」をご覧ください。例外は `Error` レベルでログされます。また、キューメッセージが有害キューに送信されたといったような場合には、ランタイムによって `Warning` レベルのログも作成されます。
`Function.<YOUR_FUNCTION_NAME>`	customMetrics customEvents	C# および JavaScript SDK を使用すると、カスタムメトリックを収集し、カスタムイベントをログに記録することができます。詳細については、「カスタム利用統計情報」を参照してください。
`Function.<YOUR_FUNCTION_NAME>`	traces	特定の関数の実行について、Function started および completed のログが含まれます。正常に実行された場合、これらのログは `Information` レベルとなります。例外は `Error` レベルでログされます。また、キューメッセージが有害キューに送信されたといったような場合には、ランタイムによって `Warning` レベルのログも作成されます。
`Function.<YOUR_FUNCTION_NAME>.User`	traces	ユーザーが生成したログ。任意のログレベルとすることができます。関数からのログへの書き込みの詳細については、「ログへの書き込み」を参照してください。
`Host.Aggregator`	customMetrics	これらのランタイム生成ログには、構成可能な期間の関数呼び出しの回数と平均回数が記録されます。既定の期間は、30 秒か 1,000 回のどちらか早い方です。例としては、実行回数、成功率、時間などがあります。これらすべてのログは `Information` レベルで書き込まれます。 `Warning` 以上でフィルターすると、このデータは表示されなくなります。
`Host.Results`	requests	これらのランタイム生成ログから、関数の成功または失敗を確認できます。これらすべてのログは `Information` レベルで書き込まれます。 `Warning` 以上でフィルターすると、このデータは表示されなくなります。
`Microsoft`	traces	ホストによって起動される .NET ランタイムコンポーネントを反映する完全修飾ログカテゴリ。
`Worker`	traces	.NET 以外の言語用の言語ワーカープロセスによって生成されるログ。言語ワーカーログは、`Microsoft.Azure.WebJobs.Script.Workers.Rpc.RpcFunctionInvocationDispatcher` などの `Microsoft.*` カテゴリで記録される場合もあります。これらのログは `Information` レベルで書き込まれます。

Note

.NET クラスライブラリ関数の場合、これらのカテゴリでは、ILogger<T> ではなく ILogger を使用していることが想定されています。詳細については、Functions ILogger のドキュメントを参照してください。

カテゴリ	テーブル	説明
`Function`	traces	ユーザーが生成したログ。任意のログレベルとすることができます。関数からのログへの書き込みの詳細については、「ログへの書き込み」を参照してください。
`Host.Aggregator`	customMetrics	これらのランタイム生成ログには、構成可能な期間の関数呼び出しの回数と平均回数が記録されます。既定の期間は、30 秒か 1,000 回のどちらか早い方です。例としては、実行回数、成功率、時間などがあります。これらすべてのログは `Information` レベルで書き込まれます。 `Warning` 以上でフィルターすると、このデータは表示されなくなります。
`Host.Executor`	traces	特定の関数の実行について、Function started および Function completed ログを含みます。正常に実行された場合、これらのログは `Information` レベルとなります。例外は `Error` レベルで記録されます。また、キューメッセージが有害キューに送信されたといったような場合には、ランタイムによって `Warning` レベルのログも作成されます。
`Host.Results`	requests	これらのランタイム生成ログから、関数の成功または失敗を確認できます。これらすべてのログは `Information` レベルで書き込まれます。 `Warning` 以上でフィルターすると、このデータは表示されなくなります。

テーブル列に、Application Insights のどのテーブルにログが書き込まれるかが示されます。

ログレベルを構成する

"ログレベル" がすべてのログに割り当てられます。値は、相対的な重要度を示す整数です。

LogLevel	コード	説明
Trace	0	最も詳細なメッセージを含むログ。これらのメッセージには、機密性の高いアプリケーションデータが含まれる場合があります。これらのメッセージは既定で無効になっているため、運用環境では有効にしないでください。
デバッグ	1	開発時に対話型調査に使用されるログ。これらのログには、主にデバッグに役立つ情報が含まれており、長期的な値は含まれていません。
Information	2	アプリケーションの一般的なフローを追跡するログ。これらのログには長期的な値を含める必要があります。
警告	3	アプリケーションフロー内の異常なイベントまたは予期しないイベントを強調するが、それ以外ではアプリケーションの実行を停止することはないログ。
エラー	4	エラーが発生したために現在の実行フローが停止したことを強調するログ。これらのエラーは、アプリケーション全体の障害ではなく、現在のアクティビティの失敗を示している必要があります。
Critical	5	回復不可能なアプリケーションまたはシステムのクラッシュや、早急に対処する必要がある重大な障害について説明するログ。
なし	6	指定したカテゴリのログ記録を無効にします。

host.json ファイルの構成により、関数アプリから Application Insights に送信されるログの量が決まります。

カテゴリごとに、送信する最小のログレベルを指定します。 host.json の設定は、Functions ランタイムのバージョンによって異なります。

以下の例では、次の規則に基づいてログ記録を定義します。

既定のログレベルは、予期しないカテゴリに対する過剰なログ記録を防ぐために、Warning に設定されています。
Host.Aggregator と Host.Results は低いレベルに設定されています。これらを高すぎるレベル (特に Information より高いレベル) に設定すると、メトリックとパフォーマンスデータが失われる可能性があります。
関数の実行のログ記録が Information に設定されています。これは、必要に応じてローカル開発で Debug または Trace にオーバーライドできます。

v2.x+
v1.x

{
  "logging": {
    "fileLoggingMode": "debugOnly",
    "logLevel": {
      "default": "Warning",
      "Host.Aggregator": "Trace",
      "Host.Results": "Information",
      "Function": "Information"
    }
  }
}

{
  "logger": {
    "categoryFilter": {
      "defaultLevel": "Warning",
      "categoryLevels": {
        "Host.Results": "Information",
        "Host.Aggregator": "Trace",
        "Function": "Information"
      }
    }
  }
}

host.json に、同じ文字列で始まる複数のログが含まれている場合は、より明確に定義されたログが先に一致します。ランタイムで、Host.Aggregator を除き、Error レベルのすべてのものをログする次の例について考えてみます。

v2.x+
v1.x

{
  "logging": {
    "fileLoggingMode": "debugOnly",
    "logLevel": {
      "default": "Information",
      "Host": "Error",
      "Function": "Error",
      "Host.Aggregator": "Information"
    }
  }
}

{
  "logger": {
    "categoryFilter": {
      "defaultLevel": "Information",
      "categoryLevels": {
        "Host": "Error",
        "Function": "Error",
        "Host.Aggregator": "Information"
      }
    }
  }
}

None というログレベル設定を使用すれば、カテゴリのログが書き込まれないようにすることができます。

注意事項

Azure Functions は、Application Insights にテレメトリイベントを格納することで、Application Insights と統合されます。カテゴリログレベルを Information とは異なる値に設定すると、テレメトリがそれらのテーブルに流れなくなります。結果として、[Application Insights] や関数の [監視] タブで関連データを表示できなくなります。

上記のサンプルから:

Host.Results カテゴリが Error ログレベルに設定されている場合、requests テーブルには、失敗した関数の実行に関するホスト実行テレメトリイベントのみが収集されます。これにより、[Application Insights] と関数の [監視] の両方のタブで、成功した実行のホスト実行の詳細が表示されなくなります。
Function カテゴリが Error ログレベルに設定されている場合は、すべての関数について、dependencies、customMetrics、customEvents に関連する関数テレメトリデータの収集が停止され、Application Insights にこのデータが表示されなくなります。 Error レベルで記録された traces のみが収集されます。

どちらの場合も、[Application Insights] および関数の [監視] タブでのエラーと例外のデータの収集は続けられます。詳細については、「テレメトリの量が多いソリューション」を参照してください。

アグリゲーターを構成する

前のセクションで述べたように、ランタイムでは期間内の関数実行についてデータが集計されます。既定の期間は、30 秒か 1,000 回実行のどちらか早い方です。 host.json ファイル内でこの設定を構成できます。次に例を示します。

{
    "aggregator": {
      "batchSize": 1000,
      "flushTimeout": "00:00:30"
    }
}

サンプリングを構成する

Application Insights には、負荷がピークのときに、完了した実行に関してテレメトリデータが生成されすぎないようにするサンプリング機能があります。 Application Insights では、受信実行の割合が指定されたしきい値を超えると、受信した実行の一部がランダムに無視され始めます。 1 秒あたりの最大実行数の既定の設定は 20 (バージョン 1.x では 5) です。 host.json でサンプリングを構成できます。次に例を示します。

v2.x+
v1.x

{
  "logging": {
    "applicationInsights": {
      "samplingSettings": {
        "isEnabled": true,
        "maxTelemetryItemsPerSecond" : 20,
        "excludedTypes": "Request;Exception"
      }
    }
  }
}

特定の種類のテレメトリをサンプリングから除外することができます。この例では、Request および Exception 型のデータがサンプリングから除外されます。これにより確実に、"すべての" 関数実行 (要求) と例外がログに記録される一方で、他の種類のテレメトリはサンプリング対象のままとなります。

{
  "applicationInsights": {
    "sampling": {
      "isEnabled": true,
      "maxTelemetryItemsPerSecond" : 5
    }
  }
}

プロジェクトで Application Insights SDK に依存してテレメトリ追跡を手動で行っている場合、ご使用のサンプリング構成が関数アプリのサンプリング構成と異なっていると、予想外の動作が起こることがあります。このような場合は、関数アプリと同じサンプリング構成を使用します。詳細については、「Application Insights におけるサンプリング」を参照してください。

SQL クエリコレクションを有効にする

Application Insights は、HTTP 要求、データベース呼び出し、および複数のバインディングの依存関係に関するデータを自動的に収集します。詳しくは、「依存関係」をご覧ください。 SQL 呼び出しの場合、サーバーとデータベースの名前は常に収集されて保存されますが、SQL クエリテキストは既定では収集されません。 dependencyTrackingOptions.enableSqlCommandTextInstrumentation を使用して、host.json ファイルで (少なくとも) 次の設定を行うことで、SQL クエリテキストログを有効にすることができます。

"logging": {
    "applicationInsights": {
        "enableDependencyTracking": true,    
        "dependencyTrackingOptions": {
            "enableSqlCommandTextInstrumentation": true
        }
    }
}

詳しくは、「詳細な SQL 追跡で完全な SQL クエリを取得する」を参照してください。

スケールコントローラーのログを構成する

この機能はプレビュー段階にあります。

Azure Functions スケールコントローラーから Application Insights または BLOB ストレージにログを出力させることで、関数アプリに対してスケールコントローラーが行っている決定をより詳しく把握することができます。

この機能を有効にするには、SCALE_CONTROLLER_LOGGING_ENABLED という名前のアプリケーション設定を、ご利用の関数アプリの設定に追加します。設定の次の値は、形式 <DESTINATION>:<VERBOSITY> にする必要があります。

プロパティ説明

<DESTINATION> ログの送信先。有効な値は AppInsights と Blob です。
AppInsights を使用する場合は、関数アプリで Application Insights が有効になっていることを確認してください。
宛先を Blob に設定すると、AzureWebJobsStorage アプリケーション設定で設定されている既定のストレージアカウントの azure-functions-scale-controller という名前の BLOB コンテナーにログが作成されます。

<VERBOSITY> ログ記録のレベルを指定します。サポートされている値は、None、Warning、および Verbose です。
Verbose に設定すると、スケールコントローラーは、すべてのワーカー数の変更の理由と、それらの決定の要因となるトリガーに関する情報をログに記録します。詳細ログには、トリガー警告と、スケールコントローラーの実行前と実行後にトリガーによって使用されたハッシュが含まれます。

プロパティ	説明
`<DESTINATION>`	ログの送信先。有効な値は `AppInsights` と `Blob` です。 `AppInsights` を使用する場合は、関数アプリで Application Insights が有効になっていることを確認してください。宛先を `Blob` に設定すると、`AzureWebJobsStorage` アプリケーション設定で設定されている既定のストレージアカウントの `azure-functions-scale-controller` という名前の BLOB コンテナーにログが作成されます。
`<VERBOSITY>`	ログ記録のレベルを指定します。サポートされている値は、`None`、`Warning`、および `Verbose` です。 `Verbose` に設定すると、スケールコントローラーは、すべてのワーカー数の変更の理由と、それらの決定の要因となるトリガーに関する情報をログに記録します。詳細ログには、トリガー警告と、スケールコントローラーの実行前と実行後にトリガーによって使用されたハッシュが含まれます。

ヒント

スケールコントローラーのログを有効にしたままにすると、関数アプリの監視にかかる可能性のあるコストに影響することに注意してください。スケールコントローラーの動作を理解するのに十分なデータを収集するまでログ記録を有効にし、その後は無効にすることを検討してください。

たとえば、次の Azure CLI コマンドを実行すると、スケールコントローラーから Application Insights への詳細ログ記録が有効になります。

az functionapp config appsettings set --name <FUNCTION_APP_NAME> \
--resource-group <RESOURCE_GROUP_NAME> \
--settings SCALE_CONTROLLER_LOGGING_ENABLED=AppInsights:Verbose

この例では、<FUNCTION_APP_NAME> と <RESOURCE_GROUP_NAME> を実際の関数アプリの名前とリソースグループ名でそれぞれ置き換えます。

次の Azure CLI コマンドでは、詳細度が None に設定されているため、ログ記録が無効になります。

az functionapp config appsettings set --name <FUNCTION_APP_NAME> \
--resource-group <RESOURCE_GROUP_NAME> \
--settings SCALE_CONTROLLER_LOGGING_ENABLED=AppInsights:None

また、次の Azure CLI コマンドを使用して SCALE_CONTROLLER_LOGGING_ENABLED 設定を削除することで、ログ記録を無効にすることもできます。

az functionapp config appsettings delete --name <FUNCTION_APP_NAME> \
--resource-group <RESOURCE_GROUP_NAME> \
--setting-names SCALE_CONTROLLER_LOGGING_ENABLED

スケールコントローラーのログを有効にすると、スケールコントローラーのログに対してクエリを実行できるようになります。

Application Insights との統合を有効にする

関数アプリが Application インサイトにデータを送信するには、次のいずれかのアプリケーション設定のみを使用して Application インサイトリソースに接続する必要があります。

設定の名前	説明
APPLICATIONINSIGHTS_CONNECTION_STRING	これは推奨設定です。これは、アプリケーションインサイトインスタンスがソブリンクラウドで実行される場合に必要です。接続文字列では、その他の新機能がサポートされています。
APPINSIGHTS_INSTRUMENTATIONKEY	従来の設定。これは、接続文字列設定を優先してアプリケーションインサイトによって非推奨とされます。

Azure portal で、または Azure Functions Core Tools または Visual Studio Code を使用してコマンドラインから関数アプリを作成すると、Application Insights 統合が既定で有効になります。 Application Insights リソースは関数アプリと同じ名前を持ち、同じリージョンまたは最も近いリージョンのどちらかで作成されます。

ポータルでの新しい関数アプリ

作成されている Application Insights リソースを確認するには、それを選択して [Application Insights] ウィンドウを展開します。 [新しいリソース名] を変更するか、またはデータを格納する Azure 地域内の別の [場所] を選択することができます。

Screenshot of enabling Application Insights while creating a function app.

[作成] を選択すると、関数アプリと共に Application Insights リソースが作成され、アプリケーション設定の APPLICATIONINSIGHTS_CONNECTION_STRING が設定されます。これで、すべて準備ができました。

既存の関数アプリに追加する

ご利用の関数アプリで Application Insights リソースが作成されていない場合は、次の手順を使用してリソースを作成します。その後、そのリソースの接続文字列を、関数アプリのアプリケーション設定として追加できます。

Azure portal で、関数アプリを検索して選択してから、対象の関数アプリを選択します。
ウィンドウの上部にある [Application Insights が構成されていません] バナーを選択します。このバナーが表示されない場合は、アプリで既に Application Insights が有効になっている可能性があります。

[リソースの変更] を展開し、下の表に指定されている設定を使用して、Application Insights リソースを作成します。

設定	提案された値	説明
新しいリソース名	一意のアプリ名	関数アプリと同じ名前を使用するのが最も簡単です。この名前は、サブスクリプション内で一意である必要があります。
場所	西ヨーロッパ	可能であれば、お使いの関数アプリと同じリージョン、または近隣のリージョンを使用してください。

Screenshot of creating an Application Insights resource.

[適用] を選択します。

Application Insights リソースは、関数アプリと同じリソースグループおよびサブスクリプションに作成されます。リソースが作成されたら、[Application Insights] ウィンドウを閉じます。
対象の関数アプリで、 [設定] の下の [構成] を選択し、 [アプリケーション設定] を選択します。 APPLICATIONINSIGHTS_CONNECTION_STRING という設定が表示された場合は、Azure で実行されている関数アプリに対して Application Insights 統合が有効になっています。何らかの理由でこの設定が存在しない場合は、アプリケーションインサイト接続文字列を値として使用して追加します。

Note

古い関数アプリでは、代わりにAPPLICATIONINSIGHTS_CONNECTION_STRING使用APPINSIGHTS_INSTRUMENTATIONKEYしている可能性があります。可能であれば、インストルメンテーションキーの代わりに接続文字列を使用するようにアプリを更新する必要があります。

組み込みログを無効にする

初期バージョンの関数では組み込みの監視を使用していましたが、これは推奨されなくなりました。 Application Insights を有効にする場合は、Azure Storage を使用する組み込みログを無効にします。組み込みログは軽量のワークロードには便利ですが、高負荷の実稼働環境での使用には向きません。実稼働環境の監視には、Application Insights をお勧めします。組み込みログを実稼働環境で使用すると、Azure Storage での調整のためにログレコードが不完全になる場合があります。

組み込みログを無効にするには、AzureWebJobsDashboard アプリ設定を削除します。 Azure portal でアプリ設定を削除する方法の詳細については、関数アプリの管理方法に関するページでアプリケーションの設定に関するセクションを参照してください。アプリ設定を削除する前に、同じ関数アプリの既存の関数によって、Azure Storage のトリガーまたはバインドにその設定が使用されていないことを確認してください。

テレメトリの量が多いソリューション

関数アプリは、IoT ソリューション、迅速なイベントドリブンソリューション、高負荷金融システム、統合システムなど、大量のテレメトリが生じる可能性のあるソリューションの必要不可欠な部分です。この場合は、監視を維持しながらコストを削減するために、追加の構成を検討する必要があります。

生成されたテレメトリは、リアルタイムダッシュボード、アラート、詳細な診断などで利用できます。生成されたテレメトリを利用する方法に応じて、生成されるデータ量を削減する戦略を定義する必要があります。この戦略により、運用環境での関数アプリの監視、運用、診断を適切に行うことができます。次のオプションを検討できます。

サンプリングを使用する: 前述のように、これは統計的に正しい分析を維持しながら、取り込まれるテレメトリイベントの量を大幅に減らすのに役立ちます。サンプリングを使用しても、大量のテレメトリを引き続き取得する可能性があります。アダプティブサンプリングによって提供されるオプションを調べます。たとえば、maxTelemetryItemsPerSecond を、監視のニーズによって生成される量のバランスを取る値に設定します。テレメトリサンプリングは、関数アプリを実行しているホストごとに適用されることに注意してください。
既定のログレベル: すべてのテレメトリカテゴリの既定値として Warning または Error を使用します。その上で、関数を適切に監視および診断できるように、Information レベルで設定するカテゴリを決めることができます。
関数のテレメトリを調整する: 既定のログレベルを Error または Warning に設定すると、各関数からの詳細情報 (依存関係、カスタムメトリック、カスタムイベント、トレース) は収集されません。運用環境の監視にとって重要な関数については、Function.<YOUR_FUNCTION_NAME> カテゴリに明示的なエントリを定義して、Information に設定します。これにより、詳細情報を収集できます。この時点で、ユーザーが生成したログが Information レベルで収集されないようにするには、Function.<YOUR_FUNCTION_NAME>.User カテゴリを Error または Warning のログレベルに設定します。
Host.Aggregator カテゴリ: 「カテゴリを構成する」で説明したように、このカテゴリを使用すると関数呼び出しの集計情報が提供されます。このカテゴリの情報は Application Insights の customMetrics テーブルに収集され、Azure portal の関数の [概要] タブに表示されます。アグリゲーターの構成方法によっては、flushTimeout によって決定される遅延が、収集されるテレメトリに含まれることを考慮してください。このカテゴリを Information 以外の値に設定すると、customMetrics テーブルでのデータの収集は停止され、関数の [概要] タブにメトリックが表示されなくなります。

次のスクリーンショットは、関数の [概要] タブに表示されている Host.Aggregator テレメトリデータを示しています。

次のスクリーンショットは、Application Insights の customMetrics テーブルの Host.Aggregator テレメトリデータを示したものです。
Host.Results カテゴリ: 「カテゴリを構成する」で説明されているように、このカテゴリでは、ランタイムによって生成された、関数呼び出しの成功または失敗を示すログが提供されます。このカテゴリの情報は Application Insights の requests テーブルに収集され、関数の [監視] タブおよびさまざまな Application Insights ダッシュボード ([パフォーマンス]、[失敗] など) に表示されます。このカテゴリを Information とは異なる値に設定すると、定義されたログレベル (またはそれ以上) で生成されたテレメトリのみが収集されます。たとえば、これを error に設定すると、失敗した実行の要求データのみが追跡されます。

次のスクリーンショットは、関数の [監視] タブに表示されている Host.Results テレメトリデータを示しています。

次のスクリーンショットは、Application Insights の [パフォーマンス] ダッシュボードに表示された Host.Results テレメトリデータを示したものです。
Host.Aggregator と Host.Results: どちらのカテゴリでも、関数の実行に関する適切な分析情報が提供されます。必要に応じて、これらのカテゴリの一方から詳細情報を削除し、監視およびアラートにもう一方を使用できます。サンプルを次に示します。

v2.x+
v1.x

{
  "version": "2.0",  
  "logging": {
    "logLevel": {
      "default": "Warning",
      "Function": "Error",
      "Host.Aggregator": "Error",
      "Host.Results": "Information", 
      "Function.Function1": "Information",
      "Function.Function1.User": "Error"
    },
    "applicationInsights": {
      "samplingSettings": {
        "isEnabled": true,
        "maxTelemetryItemsPerSecond": 1,
        "excludedTypes": "Exception"
      }
    }
  }
}

{
  "logger": {
    "categoryFilter": {
      "defaultLevel": "Warning",
      "categoryLevels": {
        "Function": "Error",
        "Host.Aggregator": "Error",
        "Host.Results": "Information",
        "Host.Executor": "Warning"
      }
    }
  },
  "applicationInsights": {
    "sampling": {
      "isEnabled": true,
      "maxTelemetryItemsPerSecond" : 5
    }
  }
}

この構成では、次のようになります。

すべての関数およびテレメトリカテゴリの既定値が Warning に設定されます (Microsoft および worker のカテゴリを含む)。そのため、既定では、ランタイムおよびカスタムログによって生成されたすべてのエラーと警告が収集されます。
Function カテゴリログレベルは Error に設定されているため、すべての関数について、既定では例外とエラーログだけが収集されます (依存関係、ユーザー生成メトリック、ユーザー生成イベントはスキップされます)。
Host.Aggregator カテゴリは Error ログレベルに設定されているため、関数呼び出しからの集計情報は customMetrics Application Insights テーブルに収集されず、実行数 (合計、成功、失敗) に関する情報は関数の概要ダッシュボードに表示されません。
Host.Results カテゴリについては、すべてのホスト実行情報が requests Application Insights テーブルに収集されます。関数の [モニター] ダッシュボードと Application Insights のダッシュボードに、すべての呼び出し結果が表示されます。
Function1 という関数に対して、ログレベルが Information に設定されます。したがって、この具象関数については、すべてのテレメトリ (依存関係、カスタムメトリック、カスタムイベント) が収集されます。同じ関数で、Function1.User カテゴリ (ユーザー生成トレース) は Error に設定されているため、カスタムエラーログだけが収集されます。

注意

v1.x では、関数ごとの構成はサポートされていません。
例外を除き、サンプリングは種類ごとに 1 秒あたり 1 つのテレメトリ項目を送信するように構成されます。このサンプリングは、関数アプリを実行しているサーバーホストごとに行われます。したがって、4 つのインスタンスがある場合、この構成により、1 秒あたり 4 つの種類ごとのテレメトリ項目と、発生する可能性があるすべての例外が出力されます。

注意

要求レートや例外レートなどのメトリックカウントはサンプリングレートを補正するように調整され、メトリックスエクスプローラーにはほぼ正しい値が表示されます。

ヒント

さまざまな構成を試して、ログ、監視、アラートの要件が満たされることを確認してください。また、予期しないエラーや誤動作が発生した場合に詳細な診断ができるようにします。

実行時の監視構成のオーバーライド

最後に、運用環境で特定のカテゴリのログ動作をすばやく変更する必要があり、host.json ファイルの変更のためだけに全体のデプロイを行いたくない場合があります。そのような場合は、host.json の値をオーバーライドできます。

これらの値をアプリ設定レベルで構成する (そして、host.json の変更だけでの再デプロイを回避する) には、アプリケーション設定として同等の値を作成することにより、host.json の特定の値をオーバーライドする必要があります。ランタイムによって AzureFunctionsJobHost__path__to__setting の形式のアプリケーション設定が検出されると、JSON の path.to.setting にある同等の host.json の設定がオーバーライドされます。アプリケーション設定として表現した場合、JSON 階層を示すために使用されるドット (.) は 2 つのアンダースコア (__) に置き換えられます。たとえば、以下のアプリ設定を使用して、上記の host.json と同じ個々の関数ログレベルを構成できます。

host.json のパス	アプリ設定
logging.logLevel.default	AzureFunctionsJobHost__logging__logLevel__default
logging.logLevel.Host.Aggregator	AzureFunctionsJobHost__logging__logLevel__Host__Aggregator
logging.logLevel.Function	AzureFunctionsJobHost__logging__logLevel__Function
logging.logLevel.Function.Function1	AzureFunctionsJobHost__logging__logLevel__Function__Function1
logging.logLevel.Function.Function1.User	AzureFunctionsJobHost__logging__logLevel__Function__Function1__User

設定のオーバーライドは、Azure portal の関数アプリの [構成] ブレードで直接、または Azure CLI や PowerShell スクリプトを使用して、行うことができます。

az cli
PowerShell

az functionapp config appsettings set --name MyFunctionApp --resource-group MyResourceGroup --settings "AzureFunctionsJobHost__logging__logLevel__Host__Aggregator=Information"

Update-AzFunctionAppSetting -Name MyAppName -ResourceGroupName MyResourceGroupName -AppSetting @{"AzureFunctionsJobHost__logging__logLevel__Host__Aggregator" = "Information"}

注意

アプリ設定を変更して host.json をオーバーライドすると、関数アプリが再起動されます。 Elastic Premium プランまたは Dedicated (App Service) プランで Linux 上で実行する場合、ピリオドを含むアプリ設定はサポートされません。これらのホスティング環境では、引き続き host.json ファイルを使用する必要があります。

正常性チェックを使用して関数アプリを監視する

正常性チェック機能を使用して、Premium (Elastic Premium) プランと Dedicated (App Service) プランの関数アプリを監視できます。正常性チェックは、従量課金プランのオプションではありません。構成方法については、「正常性チェックを使用して App Service インスタンスを監視する」を参照してください。関数アプリには、正常性チェックの 'Path' パラメーターで構成されているのと同じエンドポイントで HTTP 状態コード 200 で応答する HTTP トリガー関数が必要です。また、その関数で追加のチェックを実行して、依存するサービスが到達可能で動作していることを確認することもできます。

次のステップ

監視の詳細については、以下を参照してください。