次の方法で共有


Azure Monitor Application Insights で Azure Functions を監視する

Azure Functions には、関数を監視する Application Insights との統合機能が組み込まれています。 .NET と .NET Core 以外の言語については、分散トレースの利点を最大限に活用するには、他の言語固有のワーカーや拡張機能が必要です。

Application Insights は、ログ、パフォーマンス、エラー データを収集し、パフォーマンスの異常を自動的に検出します。 Application Insights は、問題の診断や関数の使用状況の把握に役立つ強力な分析ツールを備えています。 アプリケーション データを可視化すると、パフォーマンスと使いやすさを継続的に向上させることができます。 ローカル関数アプリ プロジェクトの開発中に Application Insights を使用することもできます。

必要な Application Insights インストルメンテーションは、Azure Functions に組み込まれています。 必要なのは、関数アプリを Application Insights リソースに接続するための有効な接続文字列だけです。 接続文字列は、関数アプリのリソースが Azure で作成されるときに、アプリケーションの設定に追加する必要があります。 関数アプリにまだ接続文字列がない場合は、手動で設定できます。 詳細については、「Azure Functions での実行の監視」と「接続文字列」を参照してください。

注意

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

サポートされている自動インストルメンテーション シナリオの一覧については、「サポートされている環境、言語、リソース プロバイダー」を参照してください。

Java アプリケーションの分散トレース

注意

この機能は、以前は 8 秒から 9 秒のコールド スタートアップへの影響がありましたが、1 秒未満に短縮されました。 この機能の早期導入者 (たとえば、2023 年 2 月より前) の場合は、「トラブルシューティング」セクションを確認して現在のバージョンに更新すると、新しい高速スタートアップのメリットが得られます。

既定で収集されるよりも多くのデータを Java ベースの Azure Functions アプリケーションから表示するには、Application Insights Java 3.x エージェントを有効にします。 このエージェントを使用すると、Application Insights は、一般的なライブラリと Azure ソフトウェア開発キット (SDK) から依存関係、ログ、メトリックを自動的に収集して関連付けることができます。 このテレメトリは、Functions によって既に取得済みの要求テレメトリに加えられます。

アプリケーション マップを使用し、エンド ツー エンド トランザクションの全体像を把握することで、問題をより適切に診断できます。 平均パフォーマンスとエラー率と共に、システムの対話方法をトポロジー ビューで確認できます。 また、エンド ツー エンド診断用により多くのデータが得られます。 アプリケーション マップを使用して、信頼性の問題とパフォーマンスのボトルネックの根本原因を要求ごとに簡単に見つけることができます。

より高度なユース ケースでは、スパンの追加、スパンの状態の更新、スパン属性の追加によってテレメトリを変更できます。 標準 API を使用してカスタム テレメトリを送信することもできます。

Java 関数アプリの分散トレースを有効にする

関数アプリの [概要] ペインで、[Application Insights] に移動します。 [コレクション レベル] で、[推奨] を選択します。

AppInsights Java エージェントを有効にする方法を示すスクリーンショット。

構成

従量課金プランに含まれていない Azure Function App に対してこの機能を構成するには、[アプリの設定] に環境変数を追加します。 使用可能な構成については、「構成オプション: Azure Monitor Application Insights for Java」を参照してください。

従量課金プランの Azure Functions の場合、使用可能な構成オプションはAPPLICATIONINSIGHTS_INSTRUMENTATION_LOGGING_LEVEL と APPLICATIONINSIGHTS_SELF_DIAGNOSTICS_LEVEL に制限されます。 従量課金プランの Functions に追加の構成し、独自のエージェントをデプロイを行うには、Java Functions 用のカスタム分散トレース エージェントについての記事を参照してください。

独自のエージェントをデプロイすると、従量課金プランの Functions のコールド スタート時間が長くなることを意味します。

トラブルシューティング

2023 年 2 月より前にこの機能を導入した場合、Java Functions の起動時間が遅くなる可能性があります。 関数アプリの [概要] ペインで、左側のナビゲーション メニューの [構成] に移動します。 次に、[アプリケーションの設定] を選択し、次の手順に従って問題を解決します。

Windows

  1. 次の設定が存在するかどうかを確認し、削除します。

    XDT_MicrosoftApplicationInsights_Java -> 1
    ApplicationInsightsAgent_EXTENSION_VERSION -> ~2
    
  2. この設定を追加して、最新バージョンを有効にします。

    APPLICATIONINSIGHTS_ENABLE_AGENT: true
    

Linux Dedicated/Premium

  1. 次の設定が存在するかどうかを確認し、削除します。

    ApplicationInsightsAgent_EXTENSION_VERSION -> ~3
    
  2. この設定を追加して、最新バージョンを有効にします。

    APPLICATIONINSIGHTS_ENABLE_AGENT: true
    

注意

最新バージョンの Application Insights Java エージェントが Azure Functions で使用できない場合は、次の手順に従って手動でアップロードします。

アプリケーション ホストとインジェスト サービスの間の接続をテストする

Application Insights SDK とエージェントからテレメトリが送信され、インジェスト エンドポイントへの REST 呼び出しとして取り込まれます。 Web サーバーまたはアプリケーション ホスト マシンからインジェスト サービス エンドポイントへの接続は、PowerShell の生の REST クライアントを使用するか、curl コマンドを使用してテストできます。 「Azure Monitor Application Insights でアプリケーション テレメトリが見つからない場合のトラブルシューティング」をご覧ください。

ログの重複

コンソールのログ記録に log4j または logback を使用している場合は、Java Functions の分散トレースによってログが重複して作成されます。 これらの重複するログは、その後、Application Insights に送信されます。 この動作を回避するには、次の回避策を使用します。

Log4j

log4j.xml に次のフィルターを追加します。

<Filters>
  <ThresholdFilter level="ALL" onMatch="DENY" onMismatch="NEUTRAL"/>
</Filters>

例:

<?xml version="1.0" encoding="UTF-8"?>
<Configuration status="WARN">
  <Appenders>
    <Console name="Console" target="SYSTEM_OUT">
      <PatternLayout pattern="%d{HH:mm:ss.SSS} [%t] %-5level %logger{36} - %msg%n"/>
      <Filters>
        <ThresholdFilter level="ALL" onMatch="DENY" onMismatch="NEUTRAL"/>
      </Filters>
    </Console>
  </Appenders>
  <Loggers>
    <Root level="error">
      <AppenderRef ref="Console"/>
    </Root>
  </Loggers>
</Configuration>
Logback

logback.xml に次のフィルターを追加します。

<filter class="ch.qos.logback.classic.filter.ThresholdFilter">
  <level>OFF</level>
</filter>  

例:

<configuration debug="true">
  <appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender">
    <!-- encoders are  by default assigned the type
         ch.qos.logback.classic.encoder.PatternLayoutEncoder -->
    <encoder>
      <pattern>%d{HH:mm:ss.SSS} [%thread] %-5level %logger{36} -%kvp- %msg%n</pattern>
      <filter class="ch.qos.logback.classic.filter.ThresholdFilter">
        <level>OFF</level>
      </filter>  
    </encoder>
  </appender>
  <root level="debug">
    <appender-ref ref="STDOUT" />
  </root>
</configuration>

Node.js 関数アプリの分散トレース

既定で収集されるデータよりも多くのデータを Node Azure Functions アプリケーションから表示するには、Azure Monitor OpenTelemetry Distro を使用して関数をインストルメント化します。

Python 関数アプリの分散トレース

Requests、urllib3、httpx、PsycoPG2 などのサービスからテレメトリを収集するには、Azure Monitor OpenTelemetry Distro を使用します。 Azure Functions でホストされている Python アプリケーションに送信されるトラッキングされた受信要求は、そのアプリケーション中でトラッキングされているテレメトリとは自動的に関連付けされません。 トレースの相関付けを手動で実現するには、以下のように TraceContext を直接抽出します。

import azure.functions as func

from azure.monitor.opentelemetry import configure_azure_monitor
from opentelemetry import trace
from opentelemetry.propagate import extract

# Configure Azure monitor collection telemetry pipeline
configure_azure_monitor()

def main(req: func.HttpRequest, context) -> func.HttpResponse:
   ...
   # Store current TraceContext in dictionary format
   carrier = {
      "traceparent": context.trace_context.Traceparent,
      "tracestate": context.trace_context.Tracestate,
   }
   tracer = trace.get_tracer(__name__)
   # Start a span using the current context
   with tracer.start_as_current_span(
      "http_trigger_span",
      context=extract(carrier),
   ):
      ...

次のステップ