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

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

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

エージェント構成ファイルは、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
}

JSON

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

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

.NET Agent for Linux では、Instrumentor や許可リストの指定などの拡張機能はサポートされていません。Windows 上の .NET Core エージェントから構成をコピーする場合は、これらの機能を指定しないでください。

設定オプション

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

次のファイルをアプリケーションで使用できるようにします。アプリケーションファイルの横または個別のフォルダに配置できます。
- AppDynamics.Agent.netstandard.dll
- libappdprofiler.so
- libappdprofiler_musl.so
- libappdprofiler_glibc.so

次の環境変数をアプリケーションに追加して、作成します。

環境変数名	値
CORECLR_PROFILER	{57e1aa68-2229-41aa-9931-a6e93bbc64d8}
CORECLR_ENABLE_PROFILING	1
CORECLR_PROFILER_PATH	`libappdprofilerdynamic` ライブラリへのパス。例：`<application_folder_path>/libappdprofiler.so` 「.NET Agent for Linux」を参照して、`libappdprofiler.so` ライブラリの場所を指定します。

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

環境変数はグローバルホストレベルから継承されます。
環境変数は親プロセスまたはサービスです。
環境変数は、シェルスクリプトなどを使用してアプリケーションを起動する前に設定されます。

エージェント構成ファイルを適切なバイナリの横に配置します。次の 2 つのオプションがサポートされています。

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

ローカル構成オプション

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

エージェントログ：ファイル名は Agent_%N.log で、デフォルトのログレベルは INFO です。
プロファイラログ：ファイル名は Profiler_%N.log で、デフォルトのログレベルは INFO です。
警告ログ：ファイル名は Warn_%N.log で、デフォルトのログレベルは WARN です。

すべての AppDynamicsConfig.json からのロギング設定の開始に失敗した場合、3 つのデフォルトのファイルロガー（Agent Log、Profiler Log、Warn Log）が開始されます。
Default File Loggers の開始に失敗した場合は、Console Logger が開始されます。

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

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

ログプロパティ	説明
`max_size`	保存されたファイルの最大合計サイズ（バイト単位）。デフォルト値は 10485760 バイト（10 MB）です。	ロガーあたりの最大容量は `max_size * max_files` です。ファイルサイズが `max_size` に達すると、ローテーションが行われます。たとえば、`max_size` と `max_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` という名前の新しいファイルが作成されます。ログディレクトリに前回の実行からのログファイルが含まれている場合、新しく開始されたエージェントは前回の実行からの増分値を使用してログファイルを作成します。たとえば、前回の実行で 2 つのエージェントログ（`Agent_0.log` と `Agent_1.log`）が作成された場合、新しく開始されたエージェントにより `Agent_3.log` が作成されます。
`max_files`	保存されたファイルの最大合計数。デフォルト値は 10 です。
`directory`	ルートディレクトリ。相対パスと絶対パスの両方を使用できます。ただし、環境変数は使用できません。デフォルト値は `%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`	最小ログレベル。`Trace`、`Debug`、`Info`、`Warn`、`Error`、および `Fatal` を使用できます。デフォルト値は `Info` です。これらの値では、大文字と小文字は区別されません。
`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

CODE

ここで、

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（プロファイラログの場合）が作成される場合があります。
いずれかのログファイルが最初に最大サイズに達すると、ファイル名に増分番号を追加して次のログファイルが作成されます。ログの順序付けは維持されず、プロセスごとに異なります。
Logs
```
Profiler_0.log 
Profiler_1.log 
Warn_0.log 
BusinessTransactionsLog_0.log 
....
.... 
.... 
Agent_0.log 
Agent_1.log 
Profiler_2.log 
.... 
.... 
.... 
Agent_2.log 
```
CODE

Supported Features

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

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

Log Order Rules Examples

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

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

例 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.*" }

JSON

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

  {"filename" : "REST", "level" : "Info", "channel" : "com.appdynamics.REST.*" },
  {"filename" : "RESTHeartbeat", "level" : "Info", "channel" : "com.appdynamics.REST.HeartBeatLog" }

JSON

"RESTHeartbeat" と "REST" のログはまったく同じチャネル名を持っていますが、最初のロガーの minLogLevel のみが考慮されます。この例では、"Info" です。

  {"filename" : "REST", "level" : "Info", "channel" : "com.appdynamics.REST.HeartBeatLog" },
  {"filename" : "RESTHeartbeat", "level" : "Trace", "channel" : "com.appdynamics.REST.HeartBeatLog" }

JSON

ロガー "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" : "*" }

JSON

ログ設定の例

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

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": "*"
    }
  ]
}

JSON

この例では、同じファイルの複数のログエントリを示します（ディレクトリとファイル名の両方が同じ値を持ちます）。ファイルログの設定では最初のエントリを使用し、max_size、max_files、および exclude_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.*"
    }
}

JSON