各ログソースは、ジョブファイルで示されます。ジョブファイルは、以下を指定する構成ファイルです。

• ソースログファイルの場所
• ログファイルからレコードをキャプチャするためのパターン
• キャプチャされたログレコードからデータを構造化するためのパターン
• ログソースからレコードをキャプチャするためのその他のオプション

ソースを定義するには、分析エージェントの構成ディレクトリにジョブファイルを作成します（または、いずれかのサンプルを変更します）。分析エージェントには、Glassfish、OSX ログなどのサンプルのジョブファイルが含まれています。また、分析エージェントは GZIP ファイル（末尾が .gz のログファイル）を収集して解析できます。

ジョブファイルは、次のディレクトリにあります。

• <Analytics_Agent_Home>/conf/job/

エージェントはディレクトリ内のジョブファイルを動的に読み取るため、エージェントを再起動せずにジョブファイルをディレクトリに追加できます。

ジョブファイルを設定するには、ファイルで次の構成可能な設定を使用します。

• enabled：このログソースがアクティブかどうかを決定します。このログソースから分析データをキャプチャするには、値を true に設定します。
• source：ログのソースを指定します。
  • type：ログソースのタイプを指定します。file と syslog の 2 つのタイプがあります。その他のパラメータは、[type] の値によって異なります。
    • file：ログソースとして機能するログファイルの場所と名前。場所は、analytics-agent と同じマシン上にある必要があります。ファイルには、次のパラメータがあります。
      • path：ログファイルが書き込まれるディレクトリへの絶対パス。Windows では、次のように Unix 環境の場合と同じくパスを指定する必要があります。
      • 例：demo/logs
      • 例：C:/app/logs
      • nameGlob：ログファイル名での照合に使用する文字列。ワイルドカードを使用できます。また、1 レベル深いファイルと照合するか、パスディレクトリ構造内のすべてのログファイルと照合するかどうかを指定できます。ワイルドカードが nameGlob の値で始まる場合は、値を引用符で囲む必要があります。
      • 複数レベルの照合の例は次の通りです。

        path：/var/lognameGlob：'**/*.log'これは /var/log/apache2/logs/error.log と /var/log/cassandra/system.log の両方に一致します。

      • 1 レベルの照合の例：path：/var/lognameglob：'*/*.log'これは、/var/log ディレクトリ内を 1 レベルの深さで .log ファイルを検索します（/var/log/cassandra/system.log と一致しますが、/var/log/apache2/logs/error.log とは一致しません）。

      • startAtEnd：true に設定すると、ファイルの末尾からの照合を許可します。
    • syslog：「Syslog メッセージからのログ分析データの収集」を参照してください。
  • multiline：複数行にまたがる（複数の改行を含む）ログレコードが含まれているログファイルの場合は、multiline プロパティを設定し、ログファイル内の個々のレコードを識別する方法を指定します。複数行のログレコードの典型的な例は、Java 例外を含むレコードです。複数行のログレコードの行を識別するには、multiline プロパティで 2 つのオプションのいずれかを使用できます。

    • startsWith：複数行のログレコードの先頭に一致する単純なプレフィックス。 例 1：次の複数行ログを 1 つのレコードとしてキャプチャする方法：

      [#|2015-09-24T06:33:31.574-0700|INFO|glassfish3.1.2|com.appdynamics.METRICS.WRITE|_ThreadID=206;_ThreadName=Thread-2;|NODE PURGER Completed in 14 ms|#]

      以下を使用できます。

      multiline:
      startsWith: "[#|"

      例 2：次の複数行ログを 1 つのレコードとしてキャプチャする方法：

      May 5, 2016 6:07:02 AM com.appdynamics.test.payments.plugin.testsource.testPaymentClient deposit(pluginContext, financialTransaction, retry)
      INFO: Source deposit requested amount:245.43000
      May 5, 2016 6:07:02 AM com.appdynamics.test.payments.plugin.testsource.testPaymentClient deposit(pluginContext, financialTransaction, retry)
      INFO: Source deposit currency:USD
      May 5, 2016 6:07:02 AM com.appdynamics.test.payments.plugin.testsource.testPaymentClient deposit(pluginContext, financialTransaction, retry)
      INFO: Source deposit payment method:Master Card
      May 5, 2016 6:07:03 AM com.appdynamics.test.payments.plugin.testsource.testPaymentClient deposit(pluginContext, financialTransaction, retry)
      INFO: Source deposit decision:ACCEPT
      May 5, 2016 6:07:03 AM com.appdynamics.test.payments.plugin.testsource.testPaymentClient deposit(pluginContext, financialTransaction, retry)
      INFO: Source deposit reason code:200
      May 5, 2016 6:07:03 AM com.appdynamics.test.payments.plugin.testsource.testPaymentClient deposit(pluginContext, financialTransaction, retry)
      INFO: Source deposit orderId:7654
      May 5, 2016 6:07:03 AM com.appdynamics.test.payments.plugin.testsource.testPaymentClient deposit(pluginContext, financialTransaction, retry)
      INFO: Source deposit piId:1234B
      May 5, 2016 6:07:03 AM com.appdynamics.test.payments.plugin.testsource.testPaymentClient deposit(pluginContext, financialTransaction, retry)
      INFO: Source deposit referenceNumber:4620346703956702001
      May 5, 2016 6:07:03 AM com.appdynamics.test.payments.plugin.testsource.testPaymentClient deposit(pluginContext, financialTransaction, retry)
      INFO: Source deposit extData requestToken:alf/7wSR9PBh3zSMQ+++IYTRlk3Ys2DOxOmM5jWLRTyFJaSggCTyFJaSgjSB1/2v0wyTWRV0ekb0X

      以下を使用できます。

      multiline:
      startsWith: "INFO: Source deposit requested amount"

    • regex：複数行のログレコードに一致する正規表現。たとえば、この複数行ログを 1 つのレコードとしてキャプチャするには、次のようにします。

      2016-06-01 16:28:21.035 WebContainer : 8 TRANSTART> =======================================
      2016-06-01 16:28:21.036 WebContainer : 8 MERCHCFG > merchantID=appD, sendToProduction=true, targetAPIVersion=1.00, keyFilename=(null), serverURL=(null), namespaceURI=(null), enableLog=true, logDirectory=logs, logFilename=(null), logMaximumSize=10, useHttpClient=false, timeout=130
      2016-06-01 16:28:21.037 WebContainer : 8 REQUEST  >
      merchantID=appD
      davService_run=true
      clientLibraryVersion=2.0.1
      clientEnvironment=OS/400/V7R1M0/LINUX
      application_id=ff22
      exportService_addressWeight=medium
      merchantReferenceCode=appD
      clientLibrary=Java Basic
      billTo_customer=xxxxxxxxx
      billTo_finance=true
      billTo_postalCode=94105
      billTo_country=US

      次の正規表現設定を使用すると、各「レコード」の開始を識別できます。

      multiline:
      regex: "^\d{4}-\d{2}-\d{2} \d{2}:\d{2}:\d{2}\.\d{3} WebContainer : \d+ TRANSTART\u003E =======================================$"

      この regex は、行が、4 桁（2016）、2 桁（01）、スペース、2 桁（16）、「:」2 桁（28）「:」2 桁（21）「.」3 桁（035）、スペース、「WebContainer」、スペース、数字、「TRANSTART」、「>」に一致することを記述しています。

      ログテーラーは、行の先頭で一致パターンを確認するたびに新しい照合を開始し、以前に収集されたデータを 1 つのログレコードとして渡します。それぞれの一致パターンは、一致パターンが別のレコードの先頭で再度検出されるまで、バッファ内へのログ行の累積を開始するタイミングを識別します。

    複数行のログファイルの特定の形式で、正規表現による信頼できる連続行の照合が許可されていない場合は、単一行の形式を使用することもできます。ほとんどのタイプのログでは、これによりほとんどのログレコードがキャプチャされることになります。
• fields：フィールドは、アプリケーション名、ティア名などによってコントローラ UI でのログデータのコンテキストを指定するために使用されます。フィールドは、自由形式のキーと値のペアとして指定します。

• grok：grok パラメータは、非構造化ログレコード内のデータが構造化分析フィールドにマッピングされるパターンを指定します。名前付き grok 式（lib/analytics-shared-pipeline-core.jar 内にバンドルされている .grok ファイルで定義されている）を、エージェントによって構造化されたデータのフィールドに関連付けます。例：

  grok:
  patterns:
  - "\\[%{LOGLEVEL:logLevel}%{SPACE}\\]  \\[%{DATA:threadName}\\]  \\[%{JAVACLASS:class}\\]  %{GREEDYDATA}"
  - "pattern 2"
  ...

  この場合、grok-pattern 名 LOGLEVEL は、logLevel という名前の分析データフィールドと一致します。LOGLEVEL という名前で指定された正規表現は、 ディレクトリ内のファイル grok-patterns.grok で定義されています。Grok 式の指定。以前のバージョンのログ分析では、パターンリストではなく単一の「パターン」が使用されていました。このモードは、下位互換性を維持するために引き続きサポートされています。ログ分析 grok プロセッサでは、フィールド名に下線を使用できません。たとえば、フィールド名「log_fields」は機能しません。代わりに、「logfields」などを使用します。

• keyValue：keyValue パラメータは、ログを解析し、ユーザー定義の区切り文字を使用してキーと値のペアを識別する方法を指定します。これにより、「Key1 = Value1 Key2 = Value 2」というタイプのメッセージの解析を設定できます。「キーと値のペアの指定」を参照してください。
• transform：このパラメータは、grok または keyValue パラメータによってログから抽出されたフィールドのタイプまたはエイリアス名を変更する方法を指定します。

• eventTimestamp：この設定は、キャプチャしたデータに関連付けられているタイムスタンプのパターンを定義します。

非構造化ログレコード内のデータをログ分析のために構造化分析フィールドにマッピングする方法を指定するには、ジョブファイルで設定を指定します。非構造化ログデータは、次の方法でマッピングできます。

• grok パターン
• キーと値のペア
• トランスフォーム

unzip -l ./lib/analytics-shared-pipeline-core.jar|grep "\.grok"

unzip -p ./lib/analytics-shared-pipeline-core.jar grok/grok-patterns.grok

grok: patterns: - '\[%{DATESTAMP:TIME}%{SPACE}CET\]%{SPACE}%{NOTSPACE:appId}%{SPACE}%{NOTSPACE:appName}%{SPACE}%{NOTSPACE:Severity}%{SPACE}%{NOTSPACE:messageId}:%{SPACE}%{GREEDYDATA}'

Was: grok: patterns: - "%{DATE:happenedAt},%{NUMBER:quantity} Update job to: grok: patterns: - "%{DATE:happenedAt},%{NUMBER:quantity_new} Was: grok: patterns: - "%{DATE:happenedAt},%{DATA:howMany} Update job to: grok: patterns: - "%{DATE:happenedAt},%{POSINT:howManyInt}

ジョブファイルでログソースを設定することに加えて、conf ディレクトリ内にある analytics-agent.properties ファイルの値を確認する必要があります。次のプロパティ値を確認します。

• http.event.endpoint はイベントサービスの場所である必要があります。
  • SaaS コントローラの場合、URL は次のいずれかになります。
    • https://analytics.api.appdynamics.com:443（北米）
    • https://fra-ana-api.saas.appdynamics.com:443（欧州）
    • https://syd-ana-api.saas.appdynamics.com:443 APAC
  • オンプレミスインストールの場合、ユーザーが設定したホストとポートを使用します。クラスタ環境では、多くの場合、これはロードバランサです。
• http.event.accountName および http.event.accessKey 設定は、ログを関連付ける必要があるコントローラ UI 内のアカウントの名前およびキーに設定する必要があります。デフォルトでは、1 つのテナントコントローラの組み込みアカウントに設定されます。
• pipeline.poll.dir 設定は、ログ設定ファイルの場所を指定します。これは通常、ファイルを別の場所に保存しない場合は変更されません。
• ad.controller.url は AppDynamics コントローラの URL およびポートと一致している必要があります。Splunk AppDynamics

If log capture is working correctly, logs should start appearing in the Log tab in the Analytics UI. It can take some time for logs to start accumulating. Note the following troubleshooting points:

• If nothing appears in the log view, try searching over the past 24 hours.
• Timezone discrepancies between the logs and the local machine can cause log entries to be incorrectly excluded based on the selected timeframe in the Controller UI. To remediate, try setting the log files and system time to UTC or logging the timezone with the log message to verify.
• An inherent delay in indexing may result in the "last minute" view in the UI consistently yielding no logs. Increase the time range if you encounter this issue.