構成オプション: Azure Monitor Application Insights for Java

Note

インストルメンテーション キーのインジェストのサポートは、2025 年 3 月 31 日に終了します。 インストルメンテーション キーのインジェストは引き続き機能しますが、この機能の更新プログラムやサポートは提供されなくなります。 接続文字列に移行することで、新機能をご利用いただけます。

接続文字列とロール名

接続文字列とロール名は、作業を開始するために必要な最も一般的な設定です。

{
  "connectionString": "...",
  "role": {
    "name": "my cloud role name"
  }
}

接続文字列は必須です。 ロール名は、異なるアプリケーションから同じ Application Insights リソースにデータを送信する場合に常に重要です。

詳細と構成オプションについては、次のセクションを参照してください。

構成ファイルのパス

Application Insights Java 3.x は、既定では構成ファイルが applicationinsights.json という名前で、applicationinsights-agent-3.4.4.jar と同じディレクトリに配置されていることが想定されています。

次の 2 つのオプションのいずれかを使用して、独自の構成ファイル パスを指定できます。

  • APPLICATIONINSIGHTS_CONFIGURATION_FILE 環境変数
  • applicationinsights.configuration.file Java システム プロパティ

相対パスを指定すると、applicationinsights-agent-3.4.4.jar が配置されているディレクトリからの相対でパスが解決されます。

あるいは、構成ファイルを使用する代わりに、環境変数 APPLICATIONINSIGHTS_CONFIGURATION_CONTENT を使用して JSON 構成の内容全体を指定できます。

接続文字列

接続文字列は必須です。 接続文字列は、Application Insights リソースで確認できます。

Application Insights の接続文字列を示したスクリーンショット。

{
  "connectionString": "..."
}

環境変数 APPLICATIONINSIGHTS_CONNECTION_STRING を使用して、接続文字列を設定することもできます。 その場合、JSON 構成で指定された接続文字列より優先されます。

または、Java システム プロパティ applicationinsights.connection.string を使用して接続文字列を設定することもできます。 また、これは JSON 構成で指定された接続文字列より優先されます。

接続文字列を読み込むファイルを指定して、接続文字列を設定することもできます。

相対パスを指定すると、applicationinsights-agent-3.4.4.jar が配置されているディレクトリからの相対でパスが解決されます。

{
  "connectionString": "${file:connection-string-file.txt}"
}

ファイルには接続文字列のみが含まれている必要があります。

接続文字列を設定しないと、Java エージェントが無効になります。

同じ JVM に複数のアプリケーションがデプロイされていて、テレメトリを別のインストルメンテーション キーに送信させる場合は、「インストルメンテーション キーのオーバーライド (プレビュー)」を参照してください。

クラウド ロール名

クラウド ロール名は、アプリケーション マップのコンポーネントにラベルを付けるために使用します。

クラウド ロール名を設定する場合:

{
  "role": {   
    "name": "my cloud role name"
  }
}

クラウド ロール名が設定されていない場合は、アプリケーション マップのコンポーネントにラベルを付けるために、Application Insights リソースの名前が使用されます。

環境変数 APPLICATIONINSIGHTS_ROLE_NAME を使用して、クラウド ロール名を設定することもできます。 その場合、JSON 構成で指定されたクラウド ロール名より優先されます。

または、Java システム プロパティ applicationinsights.role.name を使用してクラウド ロール名を設定することもできます。 その場合も、JSON 構成で指定されたクラウド ロール名より優先されます。

同じ JVM に複数のアプリケーションがデプロイされていて、テレメトリを別のクラウド ロール名に送信させる場合は、「クラウド ロール名のオーバーライド (プレビュー)」を参照してください。

クラウド ロール インスタンス

クラウド ロール インスタンスの既定値は、コンピューター名です。

クラウド ロール インスタンスをコンピューター名以外のものに設定する場合は、次のように設定します。

{
  "role": {
    "name": "my cloud role name",
    "instance": "my cloud role instance"
  }
}

環境変数 APPLICATIONINSIGHTS_ROLE_INSTANCE を使用して、クラウド ロール インスタンスを設定することもできます。 その場合、JSON 構成で指定されたクラウド ロール インスタンスより優先されます。

または、Java システム プロパティ applicationinsights.role.instance を使用してクラウド ロール インスタンスを設定することもできます。 その場合も、JSON 構成で指定されたクラウド ロール インスタンスより優先されます。

サンプリング

注意

サンプリングは、Application Insights のコストを削減する場合にお勧めの方法です。 ユース ケースに合わせてサンプリング構成を適切に設定してください。

サンプリングは要求に基づきます。つまり、要求がキャプチャ (サンプリング) される場合は、その依存関係、ログ、例外もキャプチャされます。

サンプリングはトレース ID にも基づくため、異なるサービス間で一貫したサンプリングの判断を下すことができます。

レート制限付きサンプリング

3.4.0 以降、レート制限付きサンプリングを使用できるようになり、現在は既定値になりました。

サンプリングを構成していない場合、既定値は、最大で毎秒 (およそ) 5 つの要求と、それらの要求に関するすべての依存関係とログをキャプチャするように構成されたレート制限付きサンプリングになりました。

この構成は、すべての要求をキャプチャするという以前の既定値に置き換わるものです。 今後もすべての要求をキャプチャする必要がある場合は、固定率のサンプリングを使い、サンプリング率を 100 に設定してください。

注意

レート制限付きサンプリングは概算値です。これは、各テレメトリ レコードで正確な項目カウントを出力するために、内部的に「固定の」サンプリング率を調整する必要があるためです。 レート制限付きサンプリングは、新しいアプリケーションの読み込みにすばやく (0.1 秒) 適合するように内部的に調整されます。 このため、構成されたレートを大きく超えたり、非常に長くなったりすることはありません。

この例では、1 秒間に最大で (約) 1 要求をキャプチャするようにサンプリングを設定する方法を示します。

{
  "sampling": {
    "requestsPerSecond": 1.0
  }
}

requestsPerSecond には小数を指定できる点に注意してください。そのため、必要に応じて、1 秒間に 1 要求未満をキャプチャするように構成できます。 たとえば、0.5 という値は、最大で 2 秒に 1 つの要求をキャプチャすることを意味します。

環境変数 APPLICATIONINSIGHTS_SAMPLING_REQUESTS_PER_SECOND を使用してサンプリング率を設定することもできます。 その場合、JSON 構成で指定されたレート制限より優先されます。

固定率のサンプリング

この例では、すべての要求の約 3 分の 1 をキャプチャするようにサンプリングを設定する方法を示します。

{
  "sampling": {
    "percentage": 33.333
  }
}

環境変数 APPLICATIONINSIGHTS_SAMPLING_PERCENTAGE を使用してサンプリング率を設定することもできます。 その場合、JSON 構成で指定されたサンプリング率より優先されます。

注意

サンプリング率には、N を整数として 100/N に近い割合を選択します。 サンプリングでは現在、その他の値はサポートされていません。

サンプリング オーバーライド (プレビュー)

3\.0.3 以降、この機能はプレビュー段階にあります。

サンプリング オーバーライドを使用すると、既定のサンプリング率をオーバーライドできます。 たとえば、次のように操作できます。

  • ノイズの多い正常性チェックでは、サンプリング率を 0 (または小さい値) に設定します。
  • ノイズの多い依存関係呼び出しでは、サンプリング率を 0 (または小さい値) に設定します。
  • 重要な要求の種類では、サンプリング率を 100 に設定します。 たとえば、既定のサンプリングが低い値に構成されている場合でも、/login を使用できます。

詳細については、サンプリング オーバーライドに関するドキュメントを参照してください。

JMX メトリック

その他の JMX メトリックを収集する場合は、次のようにします。

{
  "jmxMetrics": [
    {
      "name": "JVM uptime (millis)",
      "objectName": "java.lang:type=Runtime",
      "attribute": "Uptime"
    },
    {
      "name": "MetaSpace Used",
      "objectName": "java.lang:type=MemoryPool,name=Metaspace",
      "attribute": "Usage.used"
    }
  ]
}

上記の構成例では、次のようになっています。

  • name は、この JMX メトリックに割り当てられるメトリック名です (何でもかまいません)。
  • objectName は、収集する JMX MBean のobjectNameです。
  • attribute は、収集する JMX MBean 内の属性名です。

数値とブール型の JMX メトリック値がサポートされています。 ブール型の JMX メトリックは、false の場合は 0 に、true の場合は 1 にマップされます。

カスタム ディメンション

すべてのテレメトリにカスタム ディメンションを追加する場合は、次のようにします。

{
  "customDimensions": {
    "mytag": "my value",
    "anothertag": "${ANOTHER_VALUE}"
  }
}

${...} を使用すると、起動時に指定した環境変数から値を読み取ることができます。

Note

バージョン 3.0.2 以降では、service.version という名前のカスタム ディメンションを追加した場合、値はカスタム ディメンションとしてではなく、Application Insights ログ テーブルの application_Version 列に格納されます。

継承された属性 (プレビュー)

バージョン 3.2.0 以降で、要求テレメトリでカスタム ディメンションをプログラムによって設定し、次に続く依存関係テレメトリに継承させたい場合は、次のようにします。

{
  "inheritedAttributes": [
    {
      "key": "mycustomer",
      "type": "string"
    }
  ]
}

接続文字列のオーバーライド (プレビュー)

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

接続文字列のオーバーライドを使うと、既定の接続文字列をオーバーライドできます。 たとえば、次のように操作できます。

  • 1 つの HTTP パス プレフィックス /myapp1 に対して 1 つの接続文字列を設定します。
  • もう 1 つの HTTP パス プレフィックス /myapp2/ に対しては別の接続文字列を設定します。
{
  "preview": {
    "connectionStringOverrides": [
      {
        "httpPathPrefix": "/myapp1",
        "connectionString": "..."
      },
      {
        "httpPathPrefix": "/myapp2",
        "connectionString": "..."
      }
    ]
  }
}

インストルメンテーション キーのオーバーライド (プレビュー)

3\.2.3 以降、この機能はプレビュー段階にあります。

インストルメンテーション キーのオーバーライドを使用すると、既定のインストルメンテーション キーをオーバーライドできます。 たとえば、次のように操作できます。

  • 1 つの HTTP パス プレフィックス /myapp1 に対して 1 つのインストルメンテーション キーを設定します。
  • もう 1 つの HTTP パス プレフィックス /myapp2/ に対しては別のインストルメンテーション キーを設定します。
{
  "preview": {
    "instrumentationKeyOverrides": [
      {
        "httpPathPrefix": "/myapp1",
        "instrumentationKey": "12345678-0000-0000-0000-0FEEDDADBEEF"
      },
      {
        "httpPathPrefix": "/myapp2",
        "instrumentationKey": "87654321-0000-0000-0000-0FEEDDADBEEF"
      }
    ]
  }
}

クラウド ロール名のオーバーライド (プレビュー)

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

クラウド ロール名のオーバーライドを使用すると、既定のクラウド ロール名をオーバーライドできます。 たとえば、次のように操作できます。

  • 1 つの HTTP パス プレフィックス /myapp1 に対して 1 つのクラウド ロール名を設定します。
  • もう 1 つの HTTP パス プレフィックス /myapp2/ に対しては別のクラウド ロール名を設定します。
{
  "preview": {
    "roleNameOverrides": [
      {
        "httpPathPrefix": "/myapp1",
        "roleName": "Role A"
      },
      {
        "httpPathPrefix": "/myapp2",
        "roleName": "Role B"
      }
    ]
  }
}

InProc 依存関係の自動収集 (プレビュー)

バージョン 3.2.0 以降で、コントローラーの "InProc" の依存関係をキャプチャする場合は、次の構成を使用してください。

{
  "preview": {
    "captureControllerSpans": true
  }
}

テレメトリ プロセッサ (プレビュー)

テレメトリ プロセッサを使用して、要求、依存関係、トレースのテレメトリに適用されるルールを構成できます。 たとえば、次のように操作できます。

  • 機密データをマスクする。
  • 条件付きでカスタム ディメンションを追加する。
  • スパン名を更新する。これは、Azure portal で同様のテレメトリを集計するために使用されます。
  • インジェスト コストを制御するために特定のスパン属性を削除する。

詳細については、テレメトリ プロセッサに関するドキュメントを参照してください。

注意

インジェスト コストを制御するために特定の (全体の) スパンを削除する必要がある場合は、「サンプリング オーバーライド」を参照してください。

自動収集されるログ

Log4j、Logback、JBoss ログ、java. util. ログは自動でインストルメント化されます。 これらのログ記録フレームワークを介して実行されるログは、自動収集されます。

ログは、次の場合にのみキャプチャされます。

  • ログ記録フレームワーク用に構成されているレベルを満たしている。
  • Application Insights 用に構成されているレベルも満たしている。

たとえば、パッケージ com.example から WARN (以上) をログに記録するようにログ記録フレームワークが構成されており、INFO (以上) をキャプチャするように Application Insights が構成されている場合、Application Insights では、パッケージ com.example から WARN (以上) しかキャプチャされません。

Application Insights に構成されている既定のレベルは INFO です。 このレベルを変更する場合:

{
  "instrumentation": {
    "logging": {
      "level": "WARN"
    }
  }
}

環境変数 APPLICATIONINSIGHTS_INSTRUMENTATION_LOGGING_LEVEL を使用してレベルを設定することもできます。 その場合、JSON 構成で指定されたレベルより優先されます。

これらの有効な level 値を使用して、applicationinsights.json ファイルで指定できます。 この表では、さまざまなログ記録フレームワークのログ レベルにどのように対応するかを示しています。

Level Log4j Logback JBoss JUL
OFF OFF OFF OFF OFF
FATAL FATAL ERROR FATAL SEVERE
ERROR (または SEVERE) ERROR ERROR ERROR SEVERE
WARN (または WARNING) WARN WARN WARN WARNING
INFO INFO INFO INFO INFO
CONFIG DEBUG DEBUG DEBUG CONFIG
DEBUG (または FINE) DEBUG DEBUG DEBUG FINE
FINER DEBUG DEBUG DEBUG FINER
TRACE (または FINEST) TRACE TRACE TRACE FINEST
ALL ALL ALL ALL ALL

Note

ロガーに例外オブジェクトが渡されると、Azure portal 内で traces テーブルではなく exceptions テーブルの下にログ メッセージ (例外オブジェクトの詳細を含む) が表示されます。 tracesexceptions の両方のテーブルでログ メッセージを表示する場合は、Logs (Kusto) クエリを作成して、それらを結合できます。 次に例を示します。

union traces, (exceptions | extend message = outerMessage)
| project timestamp, message, itemType

ログ マーカー (プレビュー)

3.4.2 以降、Logback と Log4j 2 のログ マーカーをキャプチャできます。

{
  "preview": {
    "captureLogbackMarker":  true,
    "captureLog4jMarker":  true
  }
}

Logback の追加のログ属性 (プレビュー)

3.4.3 以降、Logback の FileNameClassNameMethodNameLineNumber をキャプチャできます。

{
  "preview": {
    "captureLogbackCodeAttributes": true
  }
}

警告

これらの追加のログ属性をキャプチャすると、パフォーマンスのオーバーヘッドが増加する可能性があります。

カスタム ディメンションとしてのログ レベル

バージョン 3.3.0 以降は、既定では、LoggingLevel はトレースのカスタム ディメンションの一部としてキャプチャされません。このデータは既に SeverityLevel フィールドでキャプチャされているためです。

必要に応じて、一時的に前の動作を再び有効にすることができます。

{
  "preview": {
    "captureLoggingLevelAsCustomDimension": true
  }
}

自動収集される Micrometer メトリック (Spring Boot アクチュエータ メトリックを含む)

アプリケーションで Micrometer が使用されている場合、Micrometer のグローバル レジストリに送信されたメトリックは自動収集されます。

また、アプリケーションで Spring Boot アクチュエータが使用されている場合、Spring Boot アクチュエータによって構成されたメトリックも自動収集されます。

Micrometer メトリックと Spring Boot アクチュエータ メトリックの自動収集を無効にするには、次のようにします。

注意

カスタム メトリックの料金は別途請求されるため、追加のコストが発生する可能性があります。 必ず価格情報を確認してください。 Micrometer と Spring Boot Actuator のメトリックを無効にするには、以下の構成を構成ファイルに追加します。

{
  "instrumentation": {
    "micrometer": {
      "enabled": false
    }
  }
}

JDBC クエリ マスク

JDBC クエリ内のリテラル値は、機密データが誤ってキャプチャされないように、既定でマスクされています。

3.4.0 以降では、この動作を無効にできます。 次に例を示します。

{
  "instrumentation": {
    "jdbc": {
      "masking": {
        "enabled": false
      }
    }
  }
}

Mongo クエリ マスク

Mongo クエリ内のリテラル値は、機密データが誤ってキャプチャされないように、既定でマスクされています。

3.4.0 以降では、この動作を無効にできます。 次に例を示します。

{
  "instrumentation": {
    "mongo": {
      "masking": {
        "enabled": false
      }
    }
  }
}

HTTP ヘッダー

バージョン 3.3.0 以降、サーバー (要求) テレメトリで要求および応答ヘッダーをキャプチャできます。

{
  "preview": {
    "captureHttpServerHeaders": {
      "requestHeaders": [
        "My-Header-A"
      ],
      "responseHeaders": [
        "My-Header-B"
      ]
    }
  }
}

ヘッダー名は大文字と小文字が区別されます。

上記の例は、プロパティ名の http.request.header.my_header_ahttp.response.header.my_header_b でキャプチャされます。

同様に、クライアント (依存関係) テレメトリで要求および応答ヘッダーをキャプチャできます。

{
  "preview": {
    "captureHttpClientHeaders": {
      "requestHeaders": [
        "My-Header-C"
      ],
      "responseHeaders": [
        "My-Header-D"
      ]
    }
  }
}

ここでも、ヘッダー名は大文字と小文字が区別されます。 上記の例は、プロパティ名の http.request.header.my_header_chttp.response.header.my_header_d でキャプチャされます。

HTTP サーバー 4xx 応答コード

既定で、4xx 応答コードを生成する HTTP サーバー要求はエラーとしてキャプチャされます。

バージョン 3.3.0 以降では、それらを成功としてキャプチャするように、この動作を変更できます。

{
  "preview": {
    "captureHttpServer4xxAsError": false
  }
}

特定の自動収集テレメトリの抑制

バージョン 3.0.3 以降では、これらの構成オプションを使用して、特定の自動収集テレメトリを抑制できます。

{
  "instrumentation": {
    "azureSdk": {
      "enabled": false
    },
    "cassandra": {
      "enabled": false
    },
    "jdbc": {
      "enabled": false
    },
    "jms": {
      "enabled": false
    },
    "kafka": {
      "enabled": false
    },
    "micrometer": {
      "enabled": false
    },
    "mongo": {
      "enabled": false
    },
    "quartz": {
      "enabled": false
    },
    "rabbitmq": {
      "enabled": false
    },
    "redis": {
      "enabled": false
    },
    "springScheduling": {
      "enabled": false
    }
  }
}

これらの環境変数を false に設定することで、これらのインストルメンテーションを抑制することもできます。

  • APPLICATIONINSIGHTS_INSTRUMENTATION_AZURE_SDK_ENABLED
  • APPLICATIONINSIGHTS_INSTRUMENTATION_CASSANDRA_ENABLED
  • APPLICATIONINSIGHTS_INSTRUMENTATION_JDBC_ENABLED
  • APPLICATIONINSIGHTS_INSTRUMENTATION_JMS_ENABLED
  • APPLICATIONINSIGHTS_INSTRUMENTATION_KAFKA_ENABLED
  • APPLICATIONINSIGHTS_INSTRUMENTATION_MICROMETER_ENABLED
  • APPLICATIONINSIGHTS_INSTRUMENTATION_MONGO_ENABLED
  • APPLICATIONINSIGHTS_INSTRUMENTATION_RABBITMQ_ENABLED
  • APPLICATIONINSIGHTS_INSTRUMENTATION_REDIS_ENABLED
  • APPLICATIONINSIGHTS_INSTRUMENTATION_SPRING_SCHEDULING_ENABLED

これらの変数は、JSON 構成で指定された有効な変数より優先されます。

注意

より細かい制御を検討している (たとえば、すべての Redis 呼び出しではなく、一部の Redis 呼び出しを抑制する) 場合は、サンプリング オーバーライドを参照してください。

プレビュー インストルメンテーション

バージョン 3.2.0 以降では、次のプレビュー インストルメンテーションを有効にすることができます。

{
  "preview": {
    "instrumentation": {
      "akka": {
        "enabled": true
      },
      "apacheCamel": {
        "enabled": true
      },
      "grizzly": {
        "enabled": true
      },
      "play": {
        "enabled": true
      },
      "springIntegration": {
        "enabled": true
      },
      "vertx": {
        "enabled": true
      }
    }
  }
}

注意

Akka インストルメンテーションはバージョン 3.2.2 から使用できます。 Vertx HTTP ライブラリのインストルメンテーションはバージョン 3.3.0 から使用できます。

メトリックの間隔

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

既定では、メトリックは 60 秒ごとにキャプチャされます。

バージョン 3.0.3 以降では、この間隔を変更できます。

{
  "preview": {
    "metricIntervalSeconds": 300
  }
}

この設定は、次のメトリックに適用されます。

Heartbeat

Application Insights Java 3.x は、既定では 15 分ごとにハートビート メトリックを送信します。 ハートビート メトリックを使用してアラートをトリガーする場合は、このハートビートの頻度を増やすことができます。

{
  "heartbeat": {
    "intervalSeconds": 60
  }
}

注意

ハートビート データは Application Insights の使用状況の追跡にも使用されるため、間隔を 15 分より長くすることはできません。

認証 (プレビュー)

Note

認証機能は、3.2.0 バージョン以降で利用できます。

認証を使用して、Azure Active Directory 認証に必要なトークン資格情報を生成するエージェントを設定できます。 詳細については、認証に関するドキュメントを参照してください。

HTTP プロキシ

アプリケーションがファイアウォールの背後にあり、Application Insights に直接接続できない場合 (Application Insights によって使用される IP アドレスに関するページを参照)、HTTP プロキシを使用するように Application Insights Java 3.x を構成できます。

{
  "proxy": {
    "host": "myproxy",
    "port": 8080
  }
}

Application Insights Java 3.x では、グローバル システム プロパティの https.proxyHosthttps.proxyPort (および必要に応じて http.nonProxyHosts) が設定されている場合、それらも考慮されます。

インジェストの失敗からの復旧

Application Insights サービスへのテレメトリの送信が失敗した場合、Application Insights Java 3.x はテレメトリをディスクに格納し、ディスクからの再試行を続行します。

ディスク永続化の既定の制限は 50 Mb です。 テレメトリ ボリュームが大きい場合、またはネットワークまたはインジェスト サービスの長い停止から復旧できるようにしておく必要がある場合、バージョン 3.3.0 以降ではこの制限を引き上げることができます。

{
  "preview": {
    "diskPersistenceMaxSizeMb": 50
  }
}

自己診断

"自己診断" では、Application Insights Java 3.x からの内部ログを参照します。 この機能は、Application Insights 自体の問題を発見して診断する場合に役立ちます。

Application Insights Java 3.x は、既定では applicationinsights.log ファイルとコンソールの両方に INFO レベルでログを記録します。これらは次の構成に対応します。

{
  "selfDiagnostics": {
    "destination": "file+console",
    "level": "INFO",
    "file": {
      "path": "applicationinsights.log",
      "maxSizeMb": 5,
      "maxHistory": 1
    }
  }
}

上記の構成例では、次のようになっています。

  • level には、OFFERRORWARNINFODEBUGTRACE のいずれかを指定できます。
  • path には、絶対パスまたは相対パスを指定できます。 相対パスは、applicationinsights-agent-3.4.4.jar があるディレクトリを基準にして解決されます。

バージョン 3.0.2 以降では、環境変数 APPLICATIONINSIGHTS_SELF_DIAGNOSTICS_LEVEL を使用して自己診断 level を設定することもできます。 これは、JSON 構成で指定されている自己診断レベルより優先されます。

バージョン 3.0.3 以降では、環境変数 APPLICATIONINSIGHTS_SELF_DIAGNOSTICS_FILE_PATH を使用して自己診断ファイルの場所を設定することもできます。 これは、JSON 構成で指定されている自己診断ファイル パスより優先されます。

使用例

この例では、複数のコンポーネントを含む構成ファイルがどのように表示されるかを示します。 各自のニーズに基づいて特定のオプションを構成してください。

{
  "connectionString": "...",
  "role": {
    "name": "my cloud role name"
  },
  "sampling": {
    "percentage": 100
  },
  "jmxMetrics": [
  ],
  "customDimensions": {
  },
  "instrumentation": {
    "logging": {
      "level": "INFO"
    },
    "micrometer": {
      "enabled": true
    }
  },
  "proxy": {
  },
  "preview": {
    "processors": [
    ]
  },
  "selfDiagnostics": {
    "destination": "file+console",
    "level": "INFO",
    "file": {
      "path": "applicationinsights.log",
      "maxSizeMb": 5,
      "maxHistory": 1
    }
  }
}