.NET Agent for Linuxの高度な構成オプション

このページでは、.NET Agent for Linux の高度な設定プロパティについて説明します。これは、.NET エージェントが Docker なしで動作できるようにするために使用します。.NET エージェントを使用してアプリケーションのインストゥルメント化を開始する前に、.NET Core 2.0 以降の最新バージョンを使用する必要があります。「.NET エージェントの構成プロパティ」を参照してください。

エージェント構成ファイル

注: エージェント構成ファイルは、Windows 上で .NET Core エージェントを構成するために使用される構成ファイルと似ています。

エージェントを展開したら、アプリケーションのインストルメンテーションをカスタマイズできます。

次の情報を使用して AppDynamicsConfig.json ファイルを編集できます。

{
  "controller": {
    "host": "controller.saas.appdynamics.com",
    "port": 443,
    "account": "account-name",
    "password": "access-key",
    "ssl": true
    "proxy" : {
        "host": "proxy-host",
        "port": 9090,
           "authentication": {
              "username": "proxy-user",
              "password": "proxy-password"
         }
      }
  },
  "application": {
    "name": "My Application",
    "tier": "Sample tier",
    "node": "Instance1",
	"reusenodename": "true",
	"nodenameprefix": "prefix"
  },
  "analytics": {
	"host": "localhost",
	"port": 9090
}
注:

Linux 用の .NET エージェントはノード名設定を再利用し、期間が短い CLR が多数存在するモニタリング環境を管理できます。CLR ノード名は、Splunk AppDynamics で異なる名前のノードが急増しないように再利用されます。特定のノード名を指定せずに、nodenameprefix を使用してノード名を再利用するには、「reusenodename」を「true」に、「nodenameprefix」を 「prefix」にした構成を含めます。

また、ENV APPDYNAMICS_AGENT_REUSE_NODE_NAME=true および ENV APPDYNAMICS_AGENT_REUSE_NODE_NAME_PREFIX=<prefix> などの環境変数を使用して、ノード名の再利用を設定することもできます。

.

設定オプション

Docker なしで動作するようにエージェントを設定できます。ただし、現在のエージェントで OS がサポートされている必要があります。

  1. 次のファイルをアプリケーションで使用できるようにします。アプリケーションファイルの横または個別のフォルダに配置できます。

    • AppDynamics.Agent.netstandard.dll
    • libappdprofiler.so
    • libappdprofiler_musl.so
    • libappdprofiler_glibc.so
  2. 次の環境変数をアプリケーションに追加して、作成します。

    環境変数名
    CORECLR_PROFILER{57e1aa68-2229-41aa-9931-a6e93bbc64d8}
    CORECLR_ENABLE_PROFILING1
    CORECLR_PROFILER_PATHlibappdprofilerdynamic ライブラリへのパス。例:<application_folder_path> /libappdprofiler.solibappdprofiler.so ライブラリの場所を確認するには、「.NET Agent for Linux」を参照してください。

    複数のレベルで環境変数を作成できるため、モニタリング対象アプリケーションのコンテキストでこれらを設定することが重要です。

    • 環境変数はグローバルホストレベルから継承されます。
    • 環境変数は親プロセスまたはサービスです。
    • 環境変数は、シェルスクリプトなどを使用してアプリケーションを起動する前に設定されます。
  3. エージェント構成ファイルを適切なバイナリの横に配置します。次の 2 つのオプションがサポートされています。

    • グローバルエージェント構成ファイル:AppDynamicsConfig.json ファイルをエージェントバイナリとともに配置できます。これにより、構成済みの各アプリケーションをモニタするためのデフォルトオプションがエージェントで使用されます。

      警告: .NET Agent for Linuxでは、エージェント構成でのノード名のオーバーライドがサポートされていません。したがって、グローバル構成を使用して同じホスト上で複数のアプリケーションをモニタリングすることはサポートされていません。最初のアプリケーションでのみレポートが行われます。
    • ローカルエージェント構成:[appname].AppDynamicsConfig.json ファイルをアプリケーションバイナリとともに配置できます。[appname] がアプリケーションの DLL/EXE 名と一致する必要があります。このオプションを使用して、Splunk AppDynamics 構成をアプリケーションパッケージにアタッチし、バンドルとして展開できます。適切な環境変数が設定され、エージェントバイナリが存在する場合にアクティブになります。

      注: ローカルエージェント構成は、グローバル構成よりも優先されます。

ローカル構成オプション

デフォルトでは、プロファイラと .NET エージェントの両方に Boost Log を使用できます。ログファイルが存在しない場合でも、ロギングが実行されます。デフォルトでは、次の 3 つのログファイルが作成されます。

  • エージェントログ:ファイル名は Agent_%N.log で、デフォルトのログレベルは INFO です。
  • プロファイラログ:ファイル名は Profiler_%N.log で、デフォルトのログレベルは INFO です。
  • 警告ログ:ファイル名は Warn_%N.log で、デフォルトのログレベルは WARN です。
警告:
  • AppDynamicsConfig.json のすべてのロギング構成が起動に失敗した場合、デフォルトで 3 つのファイルロガー(エージェントログプロファイラログ警告ログ)が起動します。
  • デフォルトのファイルロガーの起動に失敗した場合はコンソールロガーが起動します。

ログ構成は、プロファイラの初期化中に読み取られます。ログ構成が読み取られる前に、一部のログがコンソールに出力されます。

次の表に、ログ構成ファイルで設定できるプロパティを示します。

ログプロパティ説明
max_size保存されたファイルの最大合計サイズ(バイト単位)。デフォルト値は 10485760 バイト(10 MB)です。
  • 各ロガーの最大容量は max_size * max_files で指定されます。
  • ファイルサイズが max_size に達するとローテーションが行われます。

たとえば、max_sizemax_files のデフォルト値を使用してエージェントログを構成する場合は、次のようになります。

  • ログファイル(Agent_0.log)が max_size(10 MB)に達すると、新規ファイル(Agent_1.log)が作成されます。
  • ファイルの最大数に達すると、古いファイルが削除され、新しいファイルが作成されます。ログディレクトリが新しい一連のファイル [Agent_1.log, Agent_2.log,....Agent_9.log、Agent_10.log] が存在する場合、Agent_0.log が削除され、新たに Agent_10.log というファイルが作成されます。

ログディレクトリに前回の実行からのログファイルが含まれている場合、新しく開始されたエージェントは前回の実行からの増分値を使用してログファイルを作成します。たとえば、前回の実行で Agent_0.logAgent_1.log の 2 つのエージェントログが存在していた場合、新しく起動したエージェントは Agent_3.log を作成します。

max_files保存されたファイルの最大合計数。デフォルト値は 10 です。
ディレクトリ

ルートディレクトリ。相対パスと絶対パスの両方を使用できます。ただし、環境変数は使用できません。デフォルト値は %TEMP%/appd/dotnet

filename

ファイル名。デフォルトでは、ファイル名にプロセス ID は含まれません。ただし、プロセス ID(%P)をファイル名に含めて設定できます。たとえば、Log_%P_%N.log のファイル名で構成されたファイルは、Log_1123_0.Log の名称で表示されます(1123 はプロセス ID を表します)。デフォルト値は Agent_%N.log です(%N は 0 から始まる増分値を表します)。

exclude_tidログファイルにネイティブスレッド ID を含めるかどうかを指定します。デフォルト値は false
level

最小ログレベル。次の値を受け入れます。TraceDebugInfoWarnError、および Fatal。デフォルトは Info。これらの値では、大文字と小文字は区別されません。

注: Warn レベルのロガーがロガーリストの最後に存在することを確認します。
channel

このフィールドには、次の値を使用できます。

  • 完全修飾クラス名。
  • 名前の先頭、末尾、または両端にワイルドカード(*)を使用したクラス名。
  • 空のチャネル名、または .* または *。これらの値は、デフォルトのチャネル名として使用されます。
注: ロギング設定に加えた変更を組み込むには、アプリケーションを再起動する必要があります。ロギング設定の自動リロード機能はサポートされていません。

ログの内容の例

以下のログ例は Agent_0.log のファイルコンテンツを示します。

Agent_0.log

2021-05-24 15:26:03.741862 2056 11672 3 INFO [com.appdynamics.LifetimeManager] Initializing via agent bootstrap

ここで、

  • 2021-05-24 15:26:03.741862 はタイムスタンプです。
  • 2056 はプロセス ID です。
  • 11672 はネイティブスレッド ID です。
  • 3 は管理対象スレッド ID です。
  • INFO はログレベルです。
  • com.appdynamics.LifetimeManager はチャネル名です。
  • Initializing via agent bootstrap はログコンテンツです。

ログの構造

このログの例には、11120 と 76890 の 2 つのプロセスが含まれています。ログ設定に基づいて、各プロセスには独自のログファイルのセットがあります。

  • プロセス 11120 の初回起動時には Agent_0.log(エージェントログ)および Profiler_0.log(プロファイラログ)が作成されます。
  • プロセス 76890 の起動時には Agent_1.log(エージェントログ)および Profiler_1.log(プロファイラログ)が作成されます。
  • いずれかのログファイルが最初に最大サイズに達すると、ファイル名に増分番号を追加して次のログファイルが作成されます。ログの順序付けは維持されず、プロセスごとに異なります。

    ログ

    Profiler_0.log 
    Profiler_1.log 
    Warn_0.log 
    BusinessTransactionsLog_0.log 
    ....
    .... 
    .... 
    Agent_0.log 
    Agent_1.log 
    Profiler_2.log 
    .... 
    .... 
    .... 
    Agent_2.log 

サポートされる機能

次の表に、サポートされている Boost Log 機能を示します。

特長説明

ログ順序ルール

最後のルールが一致した後は、ルールは処理されません。

ルールの適用条件は次のとおりです。

  • AppDynamicsConfig.json ファイル内のロギング構成の順序に基づきます。
  • ログメッセージのチャネル名がログ設定のチャネル名と一致する。
  • ログメッセージのシビラティ(重大度)が、ログ設定のレベル以下である。
注: ただし、最初のロガーを使用してログが書き込まれ、2 番目のロガーとワイルドカードを使用してチャネル名が一致した場合、2 番目のロガーはログファイルにメッセージを書き込みません。
levelログに記録する最小レベル。
ワイルドカード文字(*)
  • ワイルドカードが単語の途中にある場合(例:com.*.test)、デフォルトのチャネル名(*)として使用されます。
  • ワイルドカードは次の場所に含めることができます。
    • 先頭(例:*.appdynamics.test)。
    • 末尾(例:com.appdynamics.*)
    • 先頭と末尾の両方(例:*.appdynamics.*)

ログ順序ルールの例

このログ順序ルールの例では、logger1、logger2 ... loggerN の N 個のロガーがあります。

ここで、loggerN は logger(N-1) ... logger1 に依存し、logger(N-1) は logger(N-2) ...logger1 に依存します。これ以降も同様です。

  1. 例 A:「ByteCode」ログは「AgentLog」の一部です。そのため、ByteCode ロガーによるロギングは行われません。これは、AppDynamicsConfig.json ファイル内のロギング設定の順序に基づきます。

      {"filename" : "RESTHearbeat", "level" : "Info", "channel" : "com.appdynamics.REST.HeartBeatLog" },
      {"filename" : "AgentLog", "level" : "Info", "channel" : "*" },
      {"filename" : "ByteCode","level" : "Info","channel" : "com.appdynamics.bci.*" }

    例 B:「RESTHeartbeat」ログは「REST」の一部です。そのため、「RESTHeartbeat」ログは無視されます。

      {"filename" : "REST", "level" : "Info", "channel" : "com.appdynamics.REST.*" },
      {"filename" : "RESTHeartbeat", "level" : "Info", "channel" : "com.appdynamics.REST.HeartBeatLog" }
  2. RESTHeartbeat」と「REST」のログはまったく同じチャネル名を持っていますが、最初のロガーの minLogLevel のみが考慮されます。この場合は「Info」です。

      {"filename" : "REST", "level" : "Info", "channel" : "com.appdynamics.REST.HeartBeatLog" },
      {"filename" : "RESTHeartbeat", "level" : "Trace", "channel" : "com.appdynamics.REST.HeartBeatLog" }
  3. ロガー「RESTHearbeat」および「ByteCode」を介して書き込まれないチャネルは、「AgentLog」ロガーを介して書き込まれます。

    警告: AgentLog には、 RESTHeartbeat または ByteCodeからのエントリはありません。
      {"filename" : "RESTHearbeat", "level" : "Info", "channel" : "com.appdynamics.REST.HeartBeatLog" },
      {"filename" : "ByteCode", "level" : "Info", "channel" : "com.appdynamics.bci.*" }, 
      {"filename" : "AgentLog","level" : "Info","channel" : "*" }

ログ設定の例

次に、ロギング設定の例を示します。各ログファイルには、独自の設定セットを含めることができます。

AppDynamicsConfig.json

{
  "controller": {
    "host": "......"
  },
  "application": {
    "name": "..."
  },
  "log": [
    {
      "filename": "Profiler",
      "level": "INFO",
      "directory": "/tmp/appd/logs",
      "channel": "appd.agent.profiler"
    },
    {
      "filename": "BusinessTransactionsLog",
      "level": "INFO",
      "channel": "com.appdynamics.BusinessTransactions"
    },
    {
      "filename": "RESTHearbeat",
      "level": "INFO",
      "channel": "com.appdynamics.REST.HeartBeatLog"
    },
    {
      "filename": "ByteCode",
      "level": "INFO",
      "channel": "com.appdynamics.bci.*"
    },
    {
      "filename": "RESTCommunications",
      "level": "INFO",
      "channel": "com.appdynamics.REST.*"
    },
    {
      "filename": "RESTCommunications",
      "level": "INFO",
      "channel": "com.appdynamics.METRICS.MetricSender"
    },
    {
      "filename": "SamplingTrace",
      "level": "TRACE",
      "channel": "com.appdynamics.ManagedAgentAPI.DumpStats"
    },
    {
      "filename": "Analytics",
      "level": "INFO",
      "channel": "com.appdynamics.ee.service.analytics.Analytics",
      "max_size": 31457280,
      "max_files": 2,
      "directory": "./logs",
      "exclude_tid": false
    },
    {
      "filename": "Agent",
      "level": "INFO",
      "channel": "*"
    },
    {
      "filename": "Warn",
      "level": "WARN",
      "channel": "*"
    }
  ]
}

この例では、同じファイルの複数のログエントリを示します(ディレクトリとファイル名の両方が同じ値を持ちます)。ファイルログの設定では最初のエントリを使用し、max_sizemax_filesexclude_tid のそれ以降の設定はすべて無視されます。

AppDynamicsConfig.json

{
     "filename": "agent",
     "level": "TRACE",
     "max_size":1000000,
     "max_files":2,
     "channel": "com.appdynamics.METRICS.MetricSender"
    },
    {
     "filename": "agent",
     "level": "DEBUG",
     "max_size":2000000,
     "max_files":2,
     "channel": "com.appdynamics.METRICS.*"
    },
    {
     "filename": "agent",
     "level": "INFO",
     "max_size":3000000,
     "max_files":1,
     "channel": "com.appdynamics.*"
    }
}