Azure Functions を監視するMonitor Azure Functions


Azure Functions には、関数を監視するための Azure Application Insights とのビルトイン統合機能が用意されています。Azure Functions offers built-in integration with Azure Application Insights for monitoring functions. この記事では、Functions がテレメトリ データを Application Insights に送信するように構成する方法を示します。This article shows how to configure Functions to send telemetry data to Application Insights.

Application Insights メトリックス エクスプローラー

Functions には、Application Insights を使用しないビルトイン監視機能もありますFunctions also has built-in monitoring that doesn't use Application Insights. Application Insights ではより多くのデータや優れたデータ分析方法が提供されるため、Application Insights の使用をお勧めします。We recommend Application Insights because it offers more data and better ways to analyze the data.

Application Insights の価格と制限Application Insights pricing and limits

Function App との Application Insights 統合は無料でお試しいただくことができます。You can try out Application Insights integration with Function Apps for free. ただし、1 日に無料で処理できるデータ量には上限があり、テスト中にこの上限に達する場合があります。However, there's a daily limit to how much data can be processed for free, and you might hit that limit during testing. 1 日あたりの上限に近づいた場合は、ポータルと電子メール通知でお知らせします。Azure provides portal and email notifications when the you're approaching your daily limit. しかし、これらのアラートに気が付かず、上限に達してしまった場合は、新しいログが Application Insights クエリに表示されません。But if you miss those alerts and hit the limit, new logs won't appear in Application Insights queries. 不要なトラブルシューティングに時間を費やさずにすむように、上限には気を付けてください。So be aware of the limit to avoid unnecessary troubleshooting time. 詳細については、「Application Insights での価格とデータ ボリュームの管理」を参照してください。For more information, see Manage pricing and data volume in Application Insights.

App Insights 統合を有効にするEnable App Insights integration

関数アプリでデータを Application Insights に送信するには、Application Insights リソースのインストルメンテーション キーについて知っておく必要があります。For a function app to send data to Application Insights, it needs to know the instrumentation key of an Application Insights resource. キーは、APPINSIGHTS_INSTRUMENTATIONKEY という名前のアプリ設定で指定する必要があります。The key has to be provided in an app setting named APPINSIGHTS_INSTRUMENTATIONKEY.

この接続は、Azure Portal で次の方法で設定できます。You can set up this connection in the Azure portal:

新しい関数アプリNew function app

  1. 関数アプリの [作成] ページに移動します。Go to the function app Create page.

  2. [Application Insights] スイッチを [オン] に設定します。Set the Application Insights switch On.

  3. Application Insights の場所を選択します。Select an Application Insights Location.

    データを格納する Azure の地域で、関数アプリのリージョンに最も近いリージョンを選択してください。Choose the region that is closest to your function app's region, in an Azure geography where you want your data to be stored.

    関数アプリの作成時に Application Insights を有効にする

  4. 必要な他の情報を入力します。Enter the other required information.

  5. 作成を選択します。Select Create.

次に、組み込みログを無効にします。The next step is to disable built-in logging.

App Insights リソースを手動で接続するManually connect an App Insights resource

  1. Application Insights リソースを作成します。Create the Application Insights resource. アプリケーションの種類を [全般] に設定します。Set application type to General.

    Application Insights リソースを作成して [全般] を指定する

  2. Application Insights リソースの [要点] ページからインストルメンテーション キーをコピーします。Copy the instrumentation key from the Essentials page of the Application Insights resource. 表示されているキー値の末尾にカーソルを合わせて、[コピーするにはクリックします] ボタンを表示します。Hover over the end of the displayed key value to get a Click to copy button.

    Application Insights のインストルメンテーション キーをコピーする

  3. 関数アプリの [アプリケーション設定] ページで、[新しい文字列の追加] をクリックしてアプリの設定を追加します。In the function app's Application settings page, add an app setting by clicking Add new setting. 新しい設定の名前を APPINSIGHTS_INSTRUMENTATIONKEY にして、コピーしたインストルメンテーション キーを貼り付けます。Name the new setting APPINSIGHTS_INSTRUMENTATIONKEY and paste the copied instrumentation key.

    インストルメンテーション キーをアプリ設定に追加する

  4. [Save] をクリックします。Click Save.

組み込みログを無効にするDisable built-in logging

Application Insights を有効にする場合は、Azure Storage を使用する組み込みログを無効にすることをお勧めします。If you enable Application Insights, we recommend that you disable the built-in logging that uses Azure storage. 組み込みログは軽量のワークロードには便利ですが、高負荷の実稼働環境での使用には向きません。The built-in logging is useful for testing with light workloads but is not intended for high-load production use. 実稼働環境の監視には、Application Insights をお勧めします。For production monitoring, Application Insights is recommended. 組み込みログを実稼働環境で使用すると、Azure Storage での調整のためにログ レコードが不完全になる場合があります。If built-in logging is used in production, the logging record may be incomplete due to throttling on Azure Storage.

組み込みログを無効にするには、AzureWebJobsDashboard アプリ設定を削除します。To disable built-in logging, delete the AzureWebJobsDashboard app setting. Azure Portal でアプリ設定を削除する方法については、関数アプリの管理方法に関するページで「アプリケーションの設定」セクションを参照してください。For information about how to delete app settings in the Azure portal, see the Application settings section of How to manage a function app. アプリ設定を削除する前に、同じ関数アプリの既存の関数によって、Azure Storage のトリガーまたはバインドにその設定が使用されていないことを確認します。Before deleting the app setting, make sure that no existing functions in the same function app use it for Azure Storage triggers or bindings.

[監視] タブにテレメトリを表示するView telemetry in Monitor tab

前のセクションで示したように Application Insights 統合を設定したら、[監視] タブにテレメトリ データを表示できます。After you have set up Application Insights integration as shown in the previous sections, you can view telemetry data in the Monitor tab.

  1. 関数アプリのページで、Application Insights が構成されてから少なくとも 1 回実行された関数を選択し、[監視] タブを選択します。In the function app page, select a function that has run at least once after Application Insights was configured, and then select the Monitor tab.

    [監視] タブを選択する

  2. 関数呼び出しの一覧が表示されるまで、[更新] を一定間隔で選択します。Select Refresh periodically until the list of function invocations appears.

    テレメトリ クライアントではサーバーに送信するデータをバッチ処理するため、一覧が表示されるには最大で 5 分かかる場合があります It may take up to 5 minutes for the list to appear, due to the way the telemetry client batches data for transmission to the server. (この遅延は、Live Metrics Stream には適用されません。(This delay doesn't apply to the Live Metrics Stream. このサービスは、ページの読み込み時に Functions ホストに接続するため、ログがページに直接ストリーム配信されます)。That service connects to the Functions host when you load the page, so logs are streamed directly to the page.)


  3. 特定の関数呼び出しのログを表示するには、その呼び出しの [日付] 列のリンクを選択します。To see the logs for a particular function invocation, select the Date column link for that invocation.


    その呼び出しのログ出力は、新しいページに表示されます。The logging output for that invocation appears in a new page.


両方のページ (呼び出しの一覧と詳細) が、データを取得する Application Insights Analytics クエリにリンクしています。Both pages (invocation list and details) link to the Application Insights Analytics query that retrieves the data:

Application Insights で実行する

Application Insights Analytics 呼び出しの一覧

これらのクエリで表示される呼び出しの一覧は、過去 30 日間、最大 20 行 (where timestamp > ago(30d) | take 20) に制限されています。また、呼び出しの詳細の一覧には、過去 30 日間のデータが、無制限で表示されます。From these queries, you can see that the invocation list is limited to the last 30 days, no more than 20 rows (where timestamp > ago(30d) | take 20) and the invocation details list is for the last 30 days with no limit.

詳細については、後述の「テレメトリをクエリする」を参照してください。For more information, see Query telemetry data later in this article.

App Insights でテレメトリを表示するView telemetry in App Insights

Azure Portal 上で関数アプリから Application Insights を開くには、関数アプリの [概要] ページの [構成済みの機能] セクションで [Application Insights] リンクを選択します。To open Application Insights from a function app in the Azure portal, select the Application Insights link in the Configured features section of the function app's Overview page.

[概要] ページの [Application Insights] リンク

Application Insights の使用方法については、「Application Insights のドキュメント」をご覧ください。For information about how to use Application Insights, see the Application Insights documentation. このセクションでは、Application Insights でデータを表示する方法の例をいくつか示します。This section shows some examples of how to view data in Application Insights. Application Insights をすでに使い慣れている場合は、テレメトリ データの構成とカスタマイズに関するセクションに直接進んでかまいません。If you are already familiar with Application Insights, you can go directly to the sections about configuring and customizing the telemetry data.

メトリックス エクスプローラーでは、グラフを作成したり、関数呼び出しの数、実行時間、成功率などのメトリックに基づいて警告を表示したりできます。In Metrics Explorer, you can create charts and alerts based on metrics such as number of function invocations, execution time, and success rate.

メトリックス エクスプローラー

[失敗] タブでは、グラフを作成したり、関数の失敗やサーバーの例外に基づいて警告を表示したりできます。On the Failures tab, you can create charts and alerts based on function failures and server exceptions. [操作名] は関数名です。The Operation Name is the function name. 依存関係に関するカスタム テレメトリを実装している場合を除き、依存関係のエラーは表示されません。Failures in dependencies are not shown unless you implement custom telemetry for dependencies.


[パフォーマンス] タブでは、パフォーマンスの問題を分析できます。On the Performance tab, you can analyze performance issues.


[サーバー] タブには、リソース使用率とサーバーあたりのスループットが表示されます。The Servers tab shows resource utilization and throughput per server. このデータは、関数が原因で基本リソースの処理が遅延している場合のデバッグで役立つことがあります。This data can be useful for debugging scenarios where functions are bogging down your underlying resources. サーバーは、クラウド ロール インスタンスと呼ばれます。Servers are referred to as Cloud role instances.


[Live Metrics Stream] タブには、リアルタイムで作成されたメトリック データが表示されます。The Live Metrics Stream tab shows metrics data as it is created in real time.

ライブ ストリーム

テレメトリをクエリするQuery telemetry data

Application Insights Analytics では、データベース内のテーブルの形式ですべてのテレメトリ データにアクセスできます。Application Insights Analytics gives you access to all of the telemetry data in the form of tables in a database. Analytics では、データを抽出、操作、視覚化するためのクエリ言語が用意されています。Analytics provides a query language for extracting, manipulating, and visualizing the data.

Analytics を選択する


クエリの例を次に示します。Here's a query example. ここでは、直近 30 分間の worker あたりの要求数の分布を示します。This one shows the distribution of requests per worker over the last 30 minutes.

| where timestamp > ago(30m) 
| summarize count() by cloud_RoleInstance, bin(timestamp, 1m)
| render timechart

使用可能なテーブルは、左側のペインの [スキーマ] タブに表示されます。The tables that are available are shown in the Schema tab of the left pane. 次のテーブルで、関数呼び出しによって生成されたデータを確認できます。You can find data generated by function invocations in the following tables:

  • traces - ランタイムや関数コードによって作成されたログ。traces - Logs created by the runtime and by function code.
  • requests - 関数呼び出しごとの要求。requests - One for each function invocation.
  • exceptions - ランタイムによってスローされた例外。exceptions - Any exceptions thrown by the runtime.
  • customMetrics - 呼び出しの成功数と失敗数、成功率、時間。customMetrics - Count of successful and failing invocations, success rate, duration.
  • customEvents - ランタイムによって追跡されたイベント。たとえば、関数をトリガーする HTTP 要求など。customEvents - Events tracked by the runtime, for example: HTTP requests that trigger a function.
  • performanceCounters - 関数が実行されているサーバーのパフォーマンスに関する情報。performanceCounters - Info about the performance of the servers that the functions are running on.

その他のテーブルには、可用性テストと、クライアントとブラウザーのテレメトリがあります。The other tables are for availability tests and client/browser telemetry. カスタム テレメトリを実装して、テーブルにデータを追加できます。You can implement custom telemetry to add data to them.

各テーブルでは、関数固有のデータの一部が customDimensions フィールドに保存されます。Within each table, some of the Functions-specific data is in a customDimensions field. たとえば、次のクエリでは、ログ レベルが Error のすべてのトレースが取得されます。For example, the following query retrieves all traces that have log level Error.

| where customDimensions.LogLevel == "Error"

ランタイムにより、customDimensions.LogLevelcustomDimensions.Category が提供されます。The runtime provides customDimensions.LogLevel and customDimensions.Category. 関数コードで記述したログにフィールドを追加できます。You can provide additional fields in logs you write in your function code. この記事の後半にある「構造化ログ」をご覧ください。See Structured logging later in this article.

カテゴリとログ レベルを構成するConfigure categories and log levels

Application Insights はカスタム構成なしで使用できますが、既定の構成ではデータ量が多くなる可能性があります。You can use Application Insights without any custom configuration, but the default configuration can result in high volumes of data. Visual Studio Azure サブスクリプションを使っている場合、Application Insights のデータ上限に達する可能性があります。If you're using a Visual Studio Azure subscription, you might hit your data cap for Application Insights. この記事の残りの部分では、関数から Application Insights に送信するデータを構成し、カスタマイズする方法を説明します。The remainder of this article shows how to configure and customize the data that your functions send to Application Insights.


Azure Functions のロガーでは、すべてのログにカテゴリがあります。The Azure Functions logger includes a category for every log. カテゴリは、ランタイム コードや関数コードのどの部分にログが記述されているかを示します。The category indicates which part of the runtime code or your function code wrote the log.

Functions のランタイムでは、先頭が "Host" のカテゴリを持つログが作成されます。The Functions runtime creates logs that have a category beginning with "Host". たとえば、"Function started"、"Function executed"、"Function completed" のログのカテゴリは "Host.Executor" になります。For example, the "function started," "function executed," and "function completed" logs have category "Host.Executor".

ご使用の関数コードでログを記述する場合、カテゴリは "Function" になります。If you write logs in your function code, their category is "Function".

ログ レベルLog levels

Azure Functions ロガーでは、すべてのログにログ レベルも含まれています。The Azure functions logger also includes a log level with every log. LogLevel は列挙型で、整数コードは次のような相対的な重要度を示します。LogLevel is an enumeration, and the integer code indicates relative importance:

LogLevelLogLevel コードCode
TraceTrace 00
デバッグDebug 11
情報Information 22
警告Warning 33
ErrorError 44
重大Critical 55
なしNone 66

ログ レベル None については、次のセクションで説明します。Log level None is explained in the next section.

Host.json でログを構成するConfigure logging in host.json

Host.json ファイルでは、関数アプリから Application Insights に送信するログの量を設定します。The host.json file configures how much logging a function app sends to Application Insights. カテゴリごとに、送信する最小のログ レベルを指定します。For each category, you indicate the minimum log level to send. 次に例を示します。Here's an example:

Functions バージョン 1Functions Version 1

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

Functions バージョン 2Functions Version 2

Functions バージョン 2 で、.NET Core のログ記録フィルター階層が使用されるようになりました。Functions v2 now uses the .NET Core logging filter hierarchy.

  "logging": {
    "fileLoggingMode": "always",
    "logLevel": {
      "default": "Information",
      "Host.Results": "Error",
      "Function": "Error",
      "Host.Aggregator": "Trace"

この例では、次のルールを設定します。This example sets up the following rules:

  1. カテゴリが "Host.Results" または "Function" のログの場合は、Error 以上のレベルのみを Application Insights に送信する。For logs with category "Host.Results" or "Function", send only Error level and above to Application Insights. Warning 以下のレベルのログは無視する。Logs for Warning level and below are ignored.
  2. カテゴリ Host.Aggregator があるログでは、すべてのログを Application Insights に送信します。For logs with category Host.Aggregator, send all logs to Application Insights. Trace ログ レベルは、一部のロガーで Verbose と呼ばれるものと同じですが、host.json ファイルでは Trace を使用します。The Trace log level is the same as what some loggers call Verbose, but use Trace in the host.json file.
  3. その他すべてのログについては、Information 以上のレベルのみを Application Insights に送信する。For all other logs, send only Information level and above to Application Insights.

host.json 内のカテゴリ値により、先頭の値が同一のすべてのカテゴリについてログを制御する。The category value in host.json controls logging for all categories that begin with the same value. たとえば、host.json 内の "Host" は、"Host.General"、"Host.Executor"、"Host.Results" などのログを制御します。For example, "Host" in host.json controls logging for "Host.General", "Host.Executor", "Host.Results", and so forth.

host.json に先頭の文字列が同一のカテゴリが複数含まれる場合は、同一の部分がより長いものが最初に一致する。If host.json includes multiple categories that start with the same string, the longer ones are matched first. たとえば、"Host.Aggregator" 以外のランタイムからのすべてのログを Error レベルで記録し、"Host.Aggregator" のログを Information レベルで記録するとします。For example, suppose you want everything from the runtime except "Host.Aggregator" to log at Error level, but you want "Host.Aggregator" to log at the Information level:

Functions バージョン 1Functions Version 1

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

Functions バージョン 2Functions Version 2

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

あるカテゴリのすべてのログを抑制するには、ログ レベル None を使用します。To suppress all logs for a category, you can use log level None. そのカテゴリのログは書き込まれず、その上のログ レベルはありません。No logs are written with that category and there is no log level above it.

次のセクションでは、ランタイムが作成するログの主なカテゴリについて説明します。The following sections describe the main categories of logs that the runtime creates.

カテゴリ Host.ResultsCategory Host.Results

これらのログは、Application Insights では "requests" として示されます。These logs show as "requests" in Application Insights. それらは、関数の成功または失敗を示します。They indicate success or failure of a function.


これらすべてのログは Information レベルで書き込まれるため、Warning 以上でフィルターすると、このデータは表示されなくなります。All of these logs are written at Information level, so if you filter at Warning or above, you won't see any of this data.

カテゴリ Host.AggregatorCategory Host.Aggregator

これらのログには、構成可能な期間の関数呼び出しの回数と平均回数が記録されます。These logs provide counts and averages of function invocations over a configurable period of time. 既定の期間は、30 秒か 1,000 回のどちらか早い方です。The default period is 30 seconds or 1,000 results, whichever comes first.

ログは、Application Insights の customMetrics テーブルで利用できます。The logs are available in the customMetrics table in Application Insights. 例としては、実行回数、成功率、時間などがあります。Examples are number of runs, success rate, and duration.

customMetrics クエリ

これらすべてのログは Information レベルで書き込まれるため、Warning 以上でフィルターすると、このデータは表示されなくなります。All of these logs are written at Information level, so if you filter at Warning or above, you won't see any of this data.

その他のカテゴリOther categories

すでに示されているカテゴリ以外のカテゴリのすべてのログは、Application Insights の traces テーブルで利用できます。All logs for categories other than the ones already listed are available in the traces table in Application Insights.

traces クエリ

"Host" で始まるカテゴリのすべてのログは、Functions ランタイムによって書き込まれます。All logs with categories that begin with "Host" are written by the Functions runtime. "Function started" と "Function completed" のログのカテゴリは "Host.Executor" となります。The "Function started" and "Function completed" logs have category "Host.Executor". 正常に実行された場合、これらのログは Information レベルとなり、例外は Error レベルで記録されます。For successful runs, these logs are Information level; exceptions are logged at Error level. ランタイムでは、Warning レベルのログも作成されます。たとえば、"queue messages sent to the poison queue" などです。The runtime also creates Warning level logs, for example: queue messages sent to the poison queue.

ご使用の関数コードが書き込んだログのカテゴリは "Function" となり、どのログ レベルにもできます。Logs written by your function code have category "Function" and may be any log level.

アグリゲーターを構成するConfigure the aggregator

前のセクションで述べたように、ランタイムでは期間内の関数実行についてデータが集計されます。As noted in the previous section, the runtime aggregates data about function executions over a period of time. 既定の期間は、30 秒か 1,000 回実行のどちらか早い方です。The default period is 30 seconds or 1,000 runs, whichever comes first. host.json ファイル内でこの設定を構成できます。You can configure this setting in the host.json file. 次に例を示します。Here's an example:

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

サンプリングを構成するConfigure sampling

Application Insights には、負荷がピークのときにテレメトリ データが生成されすぎないようにするサンプリング機能が備わっています。Application Insights has a sampling feature that can protect you from producing too much telemetry data at times of peak load. Application Insights では、受信テレメトリの割合が特定のしきい値を超えると、受信した項目の一部がランダムに無視され始めます。When the rate of incoming telemetry exceeds a specified threshold, Application Insights starts to randomly ignore some of the incoming items. 1 秒あたりの項目の最大数に対する既定の設定は 5 です。The default setting for maximum number of items per second is 5. host.json でサンプリングを構成できます。You can configure sampling in host.json. 次に例を示します。Here's an example:

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

C# 関数でログを書き込むWrite logs in C# functions

Application Insights で traces として表示されるログを、ご使用の関数コードで書き込むことができます。You can write logs in your function code that appear as traces in Application Insights.


関数では、TraceWriter パラメーターではなく ILogger パラメーターを使用します。Use an ILogger parameter in your functions instead of a TraceWriter parameter. TraceWriter を使って作成されたログは Application Insights に送られますが、ILogger では構造化ログを記録することができます。Logs created by using TraceWriter do go to Application Insights, but ILogger lets you do structured logging.

ILogger オブジェクトで、Log<level> ILogger 上の拡張メソッドを呼び出し、ログを作成します。With an ILogger object you call Log<level> extension methods on ILogger to create logs. たとえば、次のコードでは、カテゴリが "Function" の Information ログが書き込まれます。For example, the following code writes Information logs with category "Function".

public static async Task<HttpResponseMessage> Run(HttpRequestMessage req, ILogger logger)
    logger.LogInformation("Request for item with key={itemKey}.", id);

構造化ログStructured logging

ログ メッセージで使用するパラメーターは、プレースホルダーの名前ではなく順序によって決定されます。The order of placeholders, not their names, determines which parameters are used in the log message. たとえば、次のコードがあるとします。For example, suppose you have the following code:

string partitionKey = "partitionKey";
string rowKey = "rowKey";
logger.LogInformation("partitionKey={partitionKey}, rowKey={rowKey}", partitionKey, rowKey);

同じメッセージ文字列を維持しながらパラメーターの順序を逆にすると、結果のメッセージ テキストではそれらの値が誤った場所に配置されます。If you keep the same message string and reverse the order of the parameters, the resulting message text would have the values in the wrong places.

プレースホルダーはこのように処理されるため、構造化ログを実行できます。Placeholders are handled this way so that you can do structured logging. Application Insights では、メッセージ文字列だけでなく、パラメーターの名前と値のペアも保存します。Application Insights stores the parameter name-value pairs in addition to the message string. そのため、メッセージ引数はクエリ可能なフィールドになります。The result is that the message arguments become fields that you can query on.

たとえば、前の例のようなロガー メソッド呼び出しでは、フィールド customDimensions.prop__rowKey をクエリできます。For example, if your logger method call looks like the previous example, you could query the field customDimensions.prop__rowKey. prop__ プレフィックスを追加して、ランタイムが追加したフィールドと、ご使用の関数コードが追加したフィールドとの間に競合が起こらないようにします。The prop__ prefix is added to ensure that there are no collisions between fields the runtime adds and fields your function code adds.

フィールド customDimensions.prop__{OriginalFormat} を参照することで、元のメッセージ文字列をクエリすることもできます。You can also query on the original message string by referencing the field customDimensions.prop__{OriginalFormat}.

customDimensions データの JSON 表現の例を次に示します。Here's a sample JSON representation of customDimensions data:

  customDimensions: {
    "prop__{OriginalFormat}":"C# Queue trigger function processed: {message}",

カスタム メトリックのログ記録Logging custom metrics

C# スクリプト関数では、ILogger 上の LogMetric 拡張メソッドを使用して、Application Insights でのカスタム メトリックを作成できます。In C# script functions, you can use the LogMetric extension method on ILogger to create custom metrics in Application Insights. メソッド呼び出しの例を次に示します。Here's a sample method call:

logger.LogMetric("TestMetric", 1234); 

.NET 用 Application Insights API を使用して TrackMetric を呼び出す代わりに、このコードを使用できます。This code is an alternative to calling TrackMetric using the Application Insights API for .NET.

JavaScript 関数でログを書き込むWrite logs in JavaScript functions

Node.js 関数では、context.log を使用してログを書き込みます。In Node.js functions, use context.log to write logs. 構造化ログは使用できません。Structured logging is not enabled.

context.log('JavaScript HTTP trigger function processed a request.' + context.invocationId);

カスタム メトリックのログ記録Logging custom metrics

Node.js 関数では、context.log.metric メソッドを使用して、Application Insights でカスタム メトリックを作成できます。In Node.js functions, you can use the context.log.metric method to create custom metrics in Application Insights. メソッド呼び出しの例を次に示します。Here's a sample method call:

context.log.metric("TestMetric", 1234); 

Application Insights 用 Node.js SDK を使用して trackMetric を呼び出す代わりに、このコードを使用できます。This code is an alternative to calling trackMetric using the Node.js SDK for Application Insights.

C# 関数でのカスタム テレメトリCustom telemetry in C# functions

Microsoft.ApplicationInsights NuGet パッケージを使用して、カスタム テレメトリ データを Application Insights に送信できます。You can use the Microsoft.ApplicationInsights NuGet package to send custom telemetry data to Application Insights.

カスタム テレメトリ API を使用する C# コードの例を次に示します。Here's an example of C# code that uses the custom telemetry API. この例は .NET クラス ライブラリ用ですが、Application Insights のコードは C# スクリプト用と同じです。The example is for a .NET class library, but the Application Insights code is the same for C# script.

using System;
using System.Net;
using Microsoft.ApplicationInsights;
using Microsoft.ApplicationInsights.DataContracts;
using Microsoft.ApplicationInsights.Extensibility;
using Microsoft.Azure.WebJobs;
using System.Net.Http;
using System.Threading.Tasks;
using Microsoft.Azure.WebJobs.Extensions.Http;
using Microsoft.Extensions.Logging;
using System.Linq;

namespace functionapp0915
    public static class HttpTrigger2
        private static string key = TelemetryConfiguration.Active.InstrumentationKey = 
                "APPINSIGHTS_INSTRUMENTATIONKEY", EnvironmentVariableTarget.Process);

        private static TelemetryClient telemetryClient = 
            new TelemetryClient() { InstrumentationKey = key };

        public static async Task<HttpResponseMessage> Run(
            [HttpTrigger(AuthorizationLevel.Anonymous, "get", "post", Route = null)]
            HttpRequestMessage req, ExecutionContext context, ILogger log)
            log.LogInformation("C# HTTP trigger function processed a request.");
            DateTime start = DateTime.UtcNow;

            // parse query parameter
            string name = req.GetQueryNameValuePairs()
                .FirstOrDefault(q => string.Compare(q.Key, "name", true) == 0)

            // Get request body
            dynamic data = await req.Content.ReadAsAsync<object>();

            // Set name to query string or body data
            name = name ?? data?.name;

            // Track an Event
            var evt = new EventTelemetry("Function called");
            UpdateTelemetryContext(evt.Context, context, name);

            // Track a Metric
            var metric = new MetricTelemetry("Test Metric", DateTime.Now.Millisecond);
            UpdateTelemetryContext(metric.Context, context, name);

            // Track a Dependency
            var dependency = new DependencyTelemetry
                    Name = "GET api/planets/1/",
                    Target = "",
                    Data = "",
                    Timestamp = start,
                    Duration = DateTime.UtcNow - start,
                    Success = true
            UpdateTelemetryContext(dependency.Context, context, name);

        // This correllates all telemetry with the current Function invocation
        private static void UpdateTelemetryContext(TelemetryContext context, ExecutionContext functionContext, string userName)
            context.Operation.Id = functionContext.InvocationId.ToString();
            context.Operation.ParentId = functionContext.InvocationId.ToString();
            context.Operation.Name = functionContext.FunctionName;
            context.User.Id = userName;

関数呼び出しの要求が重複するため、TrackRequestStartOperation<RequestTelemetry> を呼び出さないでください。Don't call TrackRequest or StartOperation<RequestTelemetry>, because you'll see duplicate requests for a function invocation. Functions ランタイムでは、要求が自動的に追跡されます。The Functions runtime automatically tracks requests.

telemetryClient.Context.Operation.Id は設定しないでください。Don't set telemetryClient.Context.Operation.Id. これはグローバル設定です。多くの関数が同時に実行されていると、この設定により正しくない相関関係が発生します。This is a global setting and will cause incorrect correllation when many functions are running simultaneously. 代わりに、新しいテレメトリ インスタンス (DependencyTelemetryEventTelemetry) を作成し、その Context プロパティを変更してください。Instead, create a new telemetry instance (DependencyTelemetry, EventTelemetry) and modify its Context property. その後、テレメトリ インスタンスを、TelemetryClient (TrackDependency()TrackEvent()) の対応する Track メソッドに渡します。Then pass in the telemetry instance to the corresponding Track method on TelemetryClient (TrackDependency(), TrackEvent()). これにより、現在の関数呼び出しについては、必ず正しい相関関係の詳細がテレメトリで確保されます。This ensures that the telemetry has the correct correllation details for the current function invocation.

JavaScript 関数でのカスタム テレメトリCustom telemetry in JavaScript functions

Application Insights Node.js SDK は、現在はベータ版です。The Application Insights Node.js SDK is currently in beta. カスタム テレメトリを Application Insights に送信するサンプル コードをいくつか次に示します。Here's some sample code that sends custom telemetry to Application Insights:

const appInsights = require("applicationinsights");
const client = appInsights.defaultClient;

module.exports = function (context, req) {
    context.log('JavaScript HTTP trigger function processed a request.');

    client.trackEvent({name: "my custom event", tagOverrides:{"": context.invocationId}, properties: {customProperty2: "custom property value"}});
    client.trackException({exception: new Error("handled exceptions can be logged with this method"), tagOverrides:{"": context.invocationId}});
    client.trackMetric({name: "custom metric", value: 3, tagOverrides:{"": context.invocationId}});
    client.trackTrace({message: "trace message", tagOverrides:{"": context.invocationId}});
    client.trackDependency({target:"http://dbname", name:"select customers proc", data:"SELECT * FROM Customers", duration:231, resultCode:0, success: true, dependencyTypeName: "ZSQL", tagOverrides:{"": context.invocationId}});
    client.trackRequest({name:"GET /customers", url:"http://myserver/customers", duration:309, resultCode:200, success:true, tagOverrides:{"": context.invocationId}});


tagOverrides パラメーターにより、関数の呼び出し ID に operation_Id を設定します。The tagOverrides parameter sets operation_Id to the function's invocation ID. この設定により、指定された関数呼び出しの自動生成されたカスタム テレメトリをすべて関連付けることができます。This setting enables you to correlate all of the automatically-generated and custom telemetry for a given function invocation.

既知の問題Known issues


他のサービスに対する関数の依存関係は自動的には表示されませんが、依存関係を表示するようにカスタム コードを記述することができます。Dependencies that the function has to other services don't show up automatically, but you can write custom code to show the dependencies. C# カスタム テレメトリ セクションにあるサンプル コードで方法を示します。The sample code in the C# custom telemetry section shows how. このサンプル コードでは、次のような Application Insights のアプリケーション マップが作成されます。The sample code results in an application map in Application Insights that looks like this:

アプリケーション マップ

レポートに関する問題Report issues

Functions での Application Insights 統合に関する問題をレポートしたり、提案や要求を行ったりするには、GitHub で問題を作成しますTo report an issue with Application Insights integration in Functions, or to make a suggestion or request, create an issue in GitHub.

Application Insights を使用しない監視Monitoring without Application Insights

関数の監視には Application Insights の使用をお勧めします。Application Insights ではより多くのデータと優れたデータ分析方法が提供されるためです。We recommend Application Insights for monitoring functions because it offers more data and better ways to analyze the data. ただし、必要に応じて、Azure Storage を使用する組み込みログ システムを使用し続けることもできます。But if you prefer the built-in logging system that uses Azure Storage, you can continue to use that.

ストレージへのログ記録Logging to storage

組み込みログは、AzureWebJobsDashboard アプリ設定の接続文字列で指定されたストレージ アカウントを使用します。Built-in logging uses the storage account specified by the connection string in the AzureWebJobsDashboard app setting. 関数アプリ ページで、関数を選択し、[監視] タブを選択して、クラシック ビューで表示し続けるように選択します。In a function app page, select a function and then select the Monitor tab, and choose to keep it in classic view.

クラシック ビューに切り替える

関数の実行の一覧が表示されます。You get a list of function executions. 関数実行を選択して、時間、入力データ、エラー、および関連するログ ファイルを確認します。Select a function execution to review the duration, input data, errors, and associated log files.

前に Application Insights を有効にしていたが、組み込みログに戻る場合は、Application Insights を手動で無効にして、[監視] タブを選択します。Application Insights 統合を無効にするには、APPINSIGHTS_INSTRUMENTATIONKEY アプリ設定を削除します。If you enabled Application Insights earlier, but now you want to go back to built-in logging, disable Application Insights manually, and then select the Monitor tab. To disable Application Insights integration, delete the APPINSIGHTS_INSTRUMENTATIONKEY app setting.

[監視] タブに Application Insights データが表示されていても、組み込みログを無効にしていない場合は、ファイル システムにログ データを表示できます。Even if the Monitor tab shows Application Insights data, you can see log data in the file system if you haven't disabled built-in logging. ストレージ リソースで [ファイル] に移動し、関数のファイル サービスを選んでから、LogFiles > Application > Functions > Function > your_function に移動してログ ファイルを表示します。In the Storage resource, go to Files, select the file service for the function, and then go to LogFiles > Application > Functions > Function > your_function to see the log file.

リアルタイム監視Real-time monitoring

Azure コマンド ライン インターフェイス (CLI) または Azure PowerShell を使用して、ローカル ワークステーションのコマンド ライン セッションにログ ファイルをストリーミングできます。You can stream log files to a command-line session on a local workstation using the Azure Command Line Interface (CLI) or Azure PowerShell.

Azure CLI では、次のコマンドを使用して、サインイン、ご使用のサブスクリプションの選択、ログ ファイルのストリーミングを行います。For the Azure CLI, use the following commands to sign in, choose your subscription, and stream log files:

az login
az account list
az account set <subscriptionNameOrId>
az webapp log tail --resource-group <resource group name> --name <function app name>

Azure PowerShell では、次のコマンドを使用して、ご使用の Azure アカウントの追加、サブスクリプションの選択、ログ ファイルのストリーミングを行います。For Azure PowerShell, use the following commands to add your Azure account, choose your subscription, and stream log files:

PS C:\> Add-AzureAccount
PS C:\> Get-AzureSubscription
PS C:\> Get-AzureSubscription -SubscriptionName "<subscription name>" | Select-AzureSubscription
PS C:\> Get-AzureWebSiteLog -Name <function app name> -Tail

詳細については、Azure App Service の Web アプリの診断ログの有効化に関するページをご覧ください。For more information, see How to stream logs.

ログ ファイルをローカルに表示するViewing log files locally

ローカルに実行している Functions ホストは、次のパスにログを書き込みます。When the Functions host runs locally, it writes logs to the following path:


Windows では、<DefaultTempDirectory> は TMP、TEMP、USERPROFILE 環境変数、または Windows ディレクトリで最初に見つかった値です。On Windows, <DefaultTempDirectory> is the first found value of the TMP, TEMP, USERPROFILE environment variables, or the Windows directory. MacOS または Linux では、<DefaultTempDirectory> は TMPDIR 環境変数です。On MacOS or Linux, <DefaultTempDirectory> is the TMPDIR environment variable.


Functions ホストは、開始するときに、ディレクトリ内の既存のファイル構造を上書きします。When the Functions host starts, it overwrites the existing file structure in the directory.

次の手順Next steps

詳細については、次のリソースを参照してください。For more information, see the following resources: