Azure Functions を監視するMonitor Azure Functions

Azure Functions には、関数を監視するための Azure Application Insights とのビルトイン統合機能が用意されています。Azure Functions offers built-in integration with Azure Application Insights to monitor functions. この記事では、システムによって生成されたログ ファイルを Azure Functions が Application Insights に送信するように構成する方法を示します。This article shows you how to configure Azure Functions to send system-generated log files to Application Insights.

Application Insights を使用することをお勧めします。これにより、ログ、パフォーマンス、およびエラー データが収集されます。We recommend using Application Insights because it collects log, performance, and error data. また、パフォーマンスの異常が自動的に検出されるほか、問題の診断や、関数がどのように使用されているかの理解に役立つ強力な分析ツールも含まれています。It automatically detects performance anomalies and includes powerful analytics tools to help you diagnose issues and to understand how your functions are used. Application Insights は、パフォーマンスやユーザビリティを継続的に向上させるうえで役立つように設計されています。It's designed to help you continuously improve performance and usability. ローカル関数アプリ プロジェクトの開発中に Application Insights を使用することもできます。You can even use Application Insights during local function app project development. 詳細については、「Application Insights とは何か」を参照してください。For more information, see What is Application Insights?.

必要な Application Insights インストルメンテーションは Azure Functions に組み込まれているため、必要になるのは、関数アプリを Application Insights リソースに接続するための有効なインストルメンテーション キーだけです。As the required Application Insights instrumentation is built into Azure Functions, all you need is a valid instrumentation key to connect your function app to an Application Insights resource.

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

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

Application Insights との統合を有効にするEnable Application 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 must be in an app setting named APPINSIGHTS_INSTRUMENTATIONKEY.

ポータルでの新しい関数アプリNew function app in the portal

Azure Portal で関数アプリを作成すると、Application Insights 統合が既定で有効になります。When you create your function app in the Azure portal, Application Insights integration is enabled by default. Application Insights リソースは関数アプリと同じ名前を持ち、同じリージョンまたは最も近いリージョンのどちらかで作成されます。The Application Insights resource has the same name as your function app, and it's created either in the same region or in nearest region.

作成されている Application Insights リソースを確認するには、それを選択して [Application Insights] ウィンドウを展開します。To review the Application Insights resource being created, select it to expand the Application Insights window. [新しいリソース名] を変更するか、またはデータを格納する Azure 地理的環境内の別の [場所] を選択することができます。You can change the New resource name or choose a different Location in an Azure geography where you want to store your data.

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

[作成] を選択すると、関数アプリと共に Application Insights リソースが作成され、アプリケーション設定の APPINSIGHTS_INSTRUMENTATIONKEY が設定されます。When you choose Create, an Application Insights resource is created with your function app, which has the APPINSIGHTS_INSTRUMENTATIONKEY set in application settings. これで、すべて準備ができました。Everything is ready to go.

既存の関数アプリに追加するAdd to an existing function app

Azure CLIVisual Studio、または Visual Studio Code を使用して関数アプリを作成する場合は、Application Insights リソースを作成する必要があります。When you create a function app using the Azure CLI, Visual Studio, or Visual Studio Code, you must create the Application Insights resource. その後、関数アプリのアプリケーション設定として、そのリソースからインストルメンテーション キーを追加できます。You can then add the instrumentation key from that resource as an application setting in your function app.

Functions を使用すると、Azure portal から関数アプリに Application Insights 統合を簡単に追加できます。Functions makes it simple to add Application Insights integration to a function app from the Azure portal.

  1. ポータル で、[すべてのサービス] > [関数アプリ] を選択し、関数アプリを選択してから、ウィンドウの上部にある Application Insights バナーを選択します。In the portal, select All services > Function Apps, select your function app, and then choose the Application Insights banner at the top of the window

    ポータルから Application Insights を有効にする

  2. 画像の下の表に指定されている設定を使用して、Application Insights リソースを作成します。Create an Application Insights resource by using the settings specified in the table below the image:

    Application Insights リソースの作成

    SettingSetting 推奨値Suggested value DescriptionDescription
    NameName 一意のアプリ名Unique app name 関数アプリと同じ名前を使用するのが最も簡単です。この名前は、サブスクリプション内で一意である必要があります。It's easiest to use the same name as your function app, which must be unique in your subscription.
    場所Location 西ヨーロッパWest Europe 可能であれば、関数アプリと同じリージョン、または近隣のリージョンを使用してください。If possible, use the same region as your function app, or near to it.
  3. [OK] を選択します。Choose OK. Application Insights リソースは、関数アプリと同じリソース グループおよびサブスクリプションに作成されます。The Application Insights resource is created in the same resource group and subscription as your function app. 作成が完了したら、Application Insights ウィンドウを閉じます。After creation completes, close the Application Insights window.

  4. 関数アプリに戻り、[アプリケーション設定] を選択し、[アプリケーション設定] まで下にスクロールします。Back in your function app, select Application settings, and scroll down to Application settings. APPINSIGHTS_INSTRUMENTATIONKEY という名設定が表示された場合は、Azure で実行されている関数アプリに対して Application Insights 統合が有効になっていることを意味します。When you see a setting named APPINSIGHTS_INSTRUMENTATIONKEY, it means that Application Insights integration is enabled for your function app running in Azure.

初期バージョンの関数では組み込みの監視を使用していましたが、これは推奨されなくなりました。Early versions of Functions used built-in monitoring, which is no longer recommended. このような関数アプリで Application Insights 統合を有効にする場合は、組み込みログも無効にする必要があります。When enabling Application Insights integration for such a function app, you must also disable built-in logging.

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

Application Insights 統合が有効になっている場合は、 [監視] タブでテレメトリ データを表示できます。With Application Insights integration enabled, 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. その後、 [監視] タブを選択します。Then select the Monitor tab.

    [監視] タブを選択する

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

    テレメトリ クライアントではサーバーに送信するデータをバッチ処理するため、一覧が表示されるには最大で 5 分かかる場合があります。It can take up to five minutes for the list to appear while the telemetry client batches data for transmission to the server. (この遅延は、Live Metrics Stream には適用されません。(The 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 クエリへの [Application Insights で実行する] リンクがあることがわかります。You can see that both pages have a Run in Application Insights link to the Application Insights Analytics query that retrieves the data.

Application Insights で実行する

次のクエリが表示されます。The following query is displayed. 呼び出しの一覧が過去 30 日間に制限されていることがわかります。You can see that the invocation list is limited to the last 30 days. この一覧には最大 20 行 (where timestamp > ago(30d) | take 20) 表示されます。The list shows no more than 20 rows (where timestamp > ago(30d) | take 20). 呼び出しの詳細の一覧には、過去 30 日間のデータが、無制限で表示されます。The invocation details list is for the last 30 days with no limit.

Application Insights Analytics 呼び出しの一覧

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

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

Azure portal で関数アプリから Application Insights を開くには、関数アプリの [概要] ページに移動します。To open Application Insights from a function app in the Azure portal, go to the function app's Overview page. [構成済みの機能][Application Insights] を選択します。Under Configured features, select Application Insights.

関数アプリの [概要] ページで 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're already familiar with Application Insights, you can go directly to the sections about how to configure and customize the telemetry data.

[Application Insights の概要] タブ

Application Insights の次の領域は、関数の動作、パフォーマンス、およびエラーを評価するときに役立ちます。The following areas of Application Insights can be helpful when evaluating the behavior, performance, and errors in your functions:

TabTab 説明Description
障害Failures 関数の失敗やサーバーの例外に基づいてグラフやアラートを作成します。Create charts and alerts based on function failures and server exceptions. [操作名] は関数名です。The Operation Name is the function name. 依存関係に関するカスタム テレメトリを実装している場合を除き、依存関係のエラーは表示されません。Failures in dependencies aren't shown unless you implement custom telemetry for dependencies.
パフォーマンスPerformance パフォーマンスの問題を分析します。Analyze performance issues.
サーバーServers サーバーごとのリソース使用率とスループットを表示します。View 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.
メトリックMetrics メトリックに基づいたグラフやアラートを作成します。Create charts and alerts that are based on metrics. メトリックには、関数呼び出しの数、実行時間、成功率が含まれます。Metrics include the number of function invocations, execution time, and success rates.
ライブ メトリック ストリームLive Metrics Stream 作成されたメトリック データをリアルタイムに表示します。View metrics data as it's created in real time.

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

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

Analytics を選択する

分析の例

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

requests
| 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 on the left. 次のテーブルで、関数呼び出しによって生成されたデータを確認できます。You can find data generated by function invocations in the following tables:

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

その他のテーブルには、可用性テストと、クライアントとブラウザーのテレメトリがあります。The other tables are for availability tests, and client and 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.

traces 
| where customDimensions.LogLevel == "Error"

ランタイムにより、customDimensions.LogLevel フィールドと customDimensions.Category フィールドが提供されます。The runtime provides the customDimensions.LogLevel and customDimensions.Category fields. 関数コードで記述したログにフィールドを追加できます。You can provide additional fields in logs that 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. 既定の構成ではデータ量が多くなる可能性があります。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 に送信するデータを構成し、カスタマイズする方法を説明します。Later in this article, you learn how to configure and customize the data that your functions send to Application Insights. 関数アプリの場合、ログは host.json ファイルで構成されます。For a function app, logging is configured in the host.json file.

CategoriesCategories

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 with a category that begin with "Host." "Function started"、"Function executed"、"Function completed" のログのカテゴリは "Host.Executor" になります。The "function started," "function executed," and "function completed" logs have the 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 内のログの構成Log configuration 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. 2 つの例があり、1 つ目の例は Functions バージョン 2.x ランタイム (.NET Core) を対象としていて、2 つ目の例はバージョン 1.x ランタイム用です。There are two examples: the first example targets the Functions version 2.x runtime (.NET Core) and the second example is for the version 1.x runtime.

バージョン 2.xVersion 2.x

v2.x ランタイムでは、.NET Core のログ記録フィルター階層が使用されます。The v2.x runtime uses the .NET Core logging filter hierarchy.

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

バージョン 1.xVersion 1.x

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

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

  • カテゴリが 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.
  • カテゴリが 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.
  • その他すべてのログについては、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.jsonHost は、Host.GeneralHost.ExecutorHost.Results などのログを制御します。Host in host.json controls logging for Host.General, Host.Executor, Host.Results, and so on.

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 レベルで記録するとします。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:

バージョン 2.xVersion 2.x

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

バージョン 1.xVersion 1.x

{
  "logger": {
    "categoryFilter": {
      "defaultLevel": "Information",
      "categoryLevels": {
        "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's 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 レベルで書き込まれます。All of these logs are written at Information level. Warning 以上でフィルターすると、このデータは表示されなくなります。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 the number of runs, success rate, and duration.

customMetrics クエリ

これらすべてのログは Information レベルで書き込まれます。All of these logs are written at Information level. Warning 以上でフィルターすると、このデータは表示されなくなります。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 レベルとなります。For successful runs, these logs are Information level. 例外は Error レベルで記録されます。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 can 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 on completed executions at times of peak load. Application Insights では、受信実行の割合が指定されたしきい値を超えると、受信した実行の一部がランダムに無視され始めます。When the rate of incoming executions exceeds a specified threshold, Application Insights starts to randomly ignore some of the incoming executions. 1 秒あたりの最大実行数の既定の設定は 20 (バージョン 1.x では 5) です。The default setting for maximum number of executions per second is 20 (five in version 1.x). host.json でサンプリングを構成できます。You can configure sampling in host.json. 次に例を示します。Here's an example:

バージョン 2.xVersion 2.x

{
  "logging": {
    "applicationInsights": {
      "samplingSettings": {
        "isEnabled": true,
        "maxTelemetryItemsPerSecond" : 20
      }
    }
  }
}

バージョン 1.xVersion 1.x

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

注意

サンプリングは、既定で有効になっています。Sampling is enabled by default. データがないと思われる場合は、特定の監視シナリオに合わせてサンプリング設定を調整するだけで済みます。If you appear to be missing data, you might need to adjust the sampling settings to fit your particular monitoring scenario.

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

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

ILoggerILogger

関数では、TraceWriter パラメーターではなく ILogger パラメーターを使用します。Use an ILogger parameter in your functions instead of a TraceWriter parameter. TraceWriter を使って作成されたログは Application Insights に送られますが、ILogger では構造化ログを記録することができます。Logs created by using TraceWriter 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 ログが書き込まれます。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. 次のコードがあるとします。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 and the message string. そのため、メッセージ引数はクエリ可能なフィールドになります。The result is that the message arguments become fields that you can query on.

前の例のようなロガー メソッド呼び出しでは、フィールド customDimensions.prop__rowKey をクエリできます。If your logger method call looks like the previous example, you can query the field customDimensions.prop__rowKey. prop__ プレフィックスを追加して、ランタイムが追加したフィールドと、ご使用の関数コードが追加したフィールドとの間に競合が起こらないようにします。The prop__ prefix is added to ensure 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}",
    "Category":"Function",
    "LogLevel":"Information",
    "prop__message":"c9519cbf-b1e6-4b9b-bf24-cb7d10b1bb89"
  }
}

カスタム メトリックのログ記録Custom metrics logging

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 by 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 isn't enabled.

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

カスタム メトリックのログ記録Custom metrics logging

Functions Runtime のバージョン 1.x で Node.js 関数を実行すると、context.log.metric メソッドを使用して、Application Insights でカスタム メトリックを作成できます。When you're running on version 1.x of the Functions runtime, Node.js functions can use the context.log.metric method to create custom metrics in Application Insights. このメソッドは、バージョン 2.x では現在サポートされていません。This method isn't currently supported in version 2.x. メソッド呼び出しの例を次に示します。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 by using the Node.js SDK for Application Insights.

C# 関数でカスタム テレメトリをログに記録するLog 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. 次の C# の例では、カスタム テレメトリ API を使用します。The following C# example 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.

バージョン 2.xVersion 2.x

バージョン 2.x ランタイムでは、テレメトリを現在の操作と自動的に関連付けるために、Application Insights のより新しい機能が使用されます。The version 2.x runtime uses newer features in Application Insights to automatically correlate telemetry with the current operation. IdParentId、または Name フィールドを手動で設定する操作は必要ありません。There's no need to manually set the operation Id, ParentId, or Name fields.

using System;
using System.Linq;
using System.Threading.Tasks;
using Microsoft.ApplicationInsights;
using Microsoft.ApplicationInsights.DataContracts;
using Microsoft.AspNetCore.Http;
using Microsoft.AspNetCore.Mvc;
using Microsoft.Azure.WebJobs;
using Microsoft.Azure.WebJobs.Extensions.Http;
using Microsoft.Extensions.Logging;

namespace functionapp0915
{
    public class HttpTrigger2
    {
        private readonly TelemetryClient telemetryClient;

        /// Using dependency injection will guarantee that you use the same configuration for telemetry collected automatically and manually.
        public HttpTrigger2(TelemetryConfiguration telemetryConfiguration)
        {
            this.telemetryClient = new TelemetryClient(telemetryConfiguration);
        }

        [FunctionName("HttpTrigger2")]
        public Task<IActionResult> Run(
            [HttpTrigger(AuthorizationLevel.Anonymous, "get", Route = null)]
            HttpRequest req, ExecutionContext context, ILogger log)
        {
            log.LogInformation("C# HTTP trigger function processed a request.");
            DateTime start = DateTime.UtcNow;

            // Parse query parameter
            string name = req.Query
                .FirstOrDefault(q => string.Compare(q.Key, "name", true) == 0)
                .Value;

            // Track an Event
            var evt = new EventTelemetry("Function called");
            evt.Context.User.Id = name;
            this.telemetryClient.TrackEvent(evt);

            // Track a Metric
            var metric = new MetricTelemetry("Test Metric", DateTime.Now.Millisecond);
            metric.Context.User.Id = name;
            this.telemetryClient.TrackMetric(metric);

            // Track a Dependency
            var dependency = new DependencyTelemetry
            {
                Name = "GET api/planets/1/",
                Target = "swapi.co",
                Data = "https://swapi.co/api/planets/1/",
                Timestamp = start,
                Duration = DateTime.UtcNow - start,
                Success = true
            };
            dependency.Context.User.Id = name;
            this.telemetryClient.TrackDependency(dependency);

            return Task.FromResult<IActionResult>(new OkResult());
        }
    }
}

バージョン 1.xVersion 1.x

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 = 
            System.Environment.GetEnvironmentVariable(
                "APPINSIGHTS_INSTRUMENTATIONKEY", EnvironmentVariableTarget.Process);

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

        [FunctionName("HttpTrigger2")]
        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)
                .Value;

            // 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);
            telemetryClient.TrackEvent(evt);
            
            // Track a Metric
            var metric = new MetricTelemetry("Test Metric", DateTime.Now.Millisecond);
            UpdateTelemetryContext(metric.Context, context, name);
            telemetryClient.TrackMetric(metric);
            
            // Track a Dependency
            var dependency = new DependencyTelemetry
                {
                    Name = "GET api/planets/1/",
                    Target = "swapi.co",
                    Data = "https://swapi.co/api/planets/1/",
                    Timestamp = start,
                    Duration = DateTime.UtcNow - start,
                    Success = true
                };
            UpdateTelemetryContext(dependency.Context, context, name);
            telemetryClient.TrackDependency(dependency);
        }
        
        // Correlate 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 global setting causes incorrect correlation 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 method ensures that the telemetry has the correct correlation details for the current function invocation.

JavaScript 関数でカスタム テレメトリをログに記録するLog 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");
appInsights.setup();
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:{"ai.operation.id": context.invocationId}, properties: {customProperty2: "custom property value"}});
    client.trackException({exception: new Error("handled exceptions can be logged with this method"), tagOverrides:{"ai.operation.id": context.invocationId}});
    client.trackMetric({name: "custom metric", value: 3, tagOverrides:{"ai.operation.id": context.invocationId}});
    client.trackTrace({message: "trace message", tagOverrides:{"ai.operation.id": context.invocationId}});
    client.trackDependency({target:"http://dbname", name:"select customers proc", data:"SELECT * FROM Customers", duration:231, resultCode:0, success: true, dependencyTypeName: "ZSQL", tagOverrides:{"ai.operation.id": context.invocationId}});
    client.trackRequest({name:"GET /customers", url:"http://myserver/customers", duration:309, resultCode:200, success:true, tagOverrides:{"ai.operation.id": context.invocationId}});

    context.done();
};

tagOverrides パラメーターにより、関数の呼び出し ID に operation_Id を設定します。The tagOverrides parameter sets the 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.

依存関係Dependencies

Functions v2 は、HTTP 要求、ServiceBus、SQL の依存関係を自動的に収集します。Functions v2 automatically collects dependencies for HTTP requests, ServiceBus, and SQL.

依存関係を表示するようにカスタム コードを記述することができます。You can write custom code to show the dependencies. たとえば、C# カスタム テレメトリ セクションにあるサンプル コードを参照してください。For examples, see the sample code in the C# custom telemetry section. このサンプル コードでは、次のイメージのような Application Insights のアプリケーション マップが作成されます。The sample code results in an application map in Application Insights that looks like the following image:

アプリケーション マップ

レポートに関する問題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.

ストリーミング ログStreaming Logs

アプリケーションの開発中に、ログ情報をほぼリアルタイムで参照すると役立つことがよくあります。While developing an application, it is often useful to see logging information in near-real time. 関数によって生成されているログ ファイルのストリームは、Azure Portal またはローカル コンピューター上のコマンド ライン セッションで表示できます。You can view a stream of log files being generated by your functions either in the Azure portal or in a command-line session on your local computer.

これは、ローカル開発中に関数をデバッグするときに見られる出力と同等です。This is equivalent to the output seen when you debug your functions during local development. 詳細については、Azure App Service の Web アプリの診断ログの有効化に関するページをご覧ください。For more information, see How to stream logs.

注意

ストリーミング ログでは、Functions ホストの 1 つのインスタンスしかサポートされません。Streaming logs support only a single instance of the Functions host. 関数が複数のインスタンスにスケール調整されている場合、他のインスタンスからのデータはログ ストリームに表示されません。When your function is scaled to multiple instances, data from other instances are not shown in the log stream. Application Insights の Live Metrics Stream では、複数のインスタンスがサポートされます。The Live Metrics Stream in Application Insights does supported multiple instances. これもほぼリアルタイムですが、ストリーミング分析はサンプリングされたデータにも基づいています。While also in near real time, streaming analytics are also based on sampled data.

ポータルPortal

ポータルでストリーミング ログを表示するには、関数アプリで [プラットフォーム機能] タブを選択します。To view streaming logs in the portal, select the Platform features tab in your function app. 次に、 [監視][ログ ストリーミング] を選択します。Then, under Monitoring, choose Log streaming.

ポータルでストリーミング ログを有効にする

これにより、アプリがログ ストリーミング サービスに接続され、ウィンドウにアプリケーション ログが表示されます。This connects your app to the log streaming service and application logs are displayed in the window. [アプリケーション ログ][Web サーバー ログ] を切り替えることができます。You can toggle between Application logs and Web server logs.

ポータルでストリーミング ログを表示する

Azure CLIAzure CLI

Azure CLI を使用して、ストリーミング ログを有効にできます。You can enable streaming logs by using 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 --subscription <subscriptionNameOrId>
az webapp log tail --resource-group <RESOURCE_GROUP_NAME> --name <FUNCTION_APP_NAME>

Azure PowerShellAzure PowerShell

Azure PowerShell を使用して、ストリーミング ログを有効にすることができます。You can enable streaming logs by using Azure PowerShell. PowerShell の場合は、次のコマンドを使用して Azure アカウントを追加し、サブスクリプションを選択して、ログ ファイルをストリーミングします。For PowerShell, use the following commands to add your Azure account, choose your subscription, and stream log files:

Add-AzAccount
Get-AzSubscription
Get-AzSubscription -SubscriptionName "<subscription name>" | Select-AzSubscription
Get-AzWebSiteLog -Name <FUNCTION_APP_NAME> -Tail

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

Application Insights を有効にする場合は、Azure Storage を使用する組み込みログを無効にします。When you enable Application Insights, disable the built-in logging that uses Azure Storage. 組み込みログは軽量のワークロードには便利ですが、高負荷の実稼働環境での使用には向きません。The built-in logging is useful for testing with light workloads, but isn't intended for high-load production use. 実稼働環境の監視には、Application Insights をお勧めします。For production monitoring, we recommend Application Insights. 組み込みログを実稼働環境で使用すると、Azure Storage での調整のためにログ レコードが不完全になる場合があります。If built-in logging is used in production, the logging record might be incomplete because of 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 you delete the app setting, make sure no existing functions in the same function app use the setting for Azure Storage triggers or bindings.

次の手順Next steps

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