Ops エージェントの構成

このドキュメントでは、Ops エージェントのデフォルト構成とカスタム構成について詳しく説明します。次のいずれかに該当する場合は、このドキュメントをお読みください。

  • 次の目的のため、Ops エージェントの構成を変更する必要がある。

    • 組み込みのロギングまたは指標の取り込みをオフにします。

    • エージェントによるログの収集元となるログファイルのファイルパスをカスタマイズする。ロギング レシーバーをご覧ください。

    • JSON を解析するか、正規表現を使用して、エージェントがログエントリの処理に使用する構造化ログ形式をカスタマイズする。ロギング プロセッサをご覧ください。

    • 指標のサンプリング レートを変更する。指標レシーバーをご覧ください。

    • 有効にする指標グループまたはグループをカスタマイズする。エージェントはデフォルトで cpumemory などのすべてのシステム指標を収集します。指標プロセッサをご覧ください。

  • Ops エージェントの構成の技術的な詳細に興味がある。

Ops エージェントは、サポートされているサードパーティ アプリケーションから指標とログを収集するための構成手順も提供します。サポートされているアプリケーションのリストについては、サードパーティ アプリケーションのモニタリングをご覧ください。

構成モデル

Ops エージェントは、組み込みのデフォルト構成を使用します。この組み込み構成を直接変更することはできません。代わりに、エージェントの再起動時に組み込み構成とマージされるオーバーライドのファイルを作成します。

組み込み構成の構成要素は次のとおりです。

  • receivers: この要素はエージェントによって収集される内容を表します。
  • processors: この要素は、エージェントが収集した情報を変更する方法を記述します。
  • service: この要素は、レシーバーとプロセッサをリンクしてパイプラインと呼ばれるデータフローを作成します。service 要素には、複数のパイプラインを含めることができる pipelines 要素が含まれます。

組み込み構成はこれらの要素で構成され、同じ要素を使用して、その組み込み構成をオーバーライドします。

組み込み構成

Ops エージェントの組み込み構成では、ログと指標のデフォルト コレクションを定義します。Linux と Windows のそれぞれの場合の組み込み構成は、次のとおりです。

Linux

デフォルトでは、Ops エージェントはファイルベースの syslog ログとホスト指標を収集します。

収集された指標の詳細については、レシーバー タイプ別に取り込まれる指標をご覧ください。

logging:
  receivers:
    syslog:
      type: files
      include_paths:
      - /var/log/messages
      - /var/log/syslog
  service:
    pipelines:
      default_pipeline:
        receivers: [syslog]
metrics:
  receivers:
    hostmetrics:
      type: hostmetrics
      collection_interval: 60s
  processors:
    metrics_filter:
      type: exclude_metrics
      metrics_pattern: []
  service:
    pipelines:
      default_pipeline:
        receivers: [hostmetrics]
        processors: [metrics_filter]

Windows

デフォルトでは、Ops エージェントは SystemApplicationSecurity のチャンネル、ホスト指標、IIS 指標、SQL Server の指標から Windows イベントログを収集します。

収集された指標の詳細については、レシーバー タイプ別に取り込まれる指標をご覧ください。

logging:
  receivers:
    windows_event_log:
      type: windows_event_log
      channels: [System, Application, Security]
  service:
    pipelines:
      default_pipeline:
        receivers: [windows_event_log]
metrics:
  receivers:
    hostmetrics:
      type: hostmetrics
      collection_interval: 60s
    iis:
      type: iis
      collection_interval: 60s
    mssql:
      type: mssql
      collection_interval: 60s
  processors:
    metrics_filter:
      type: exclude_metrics
      metrics_pattern: []
  service:
    pipelines:
      default_pipeline:
        receivers: [hostmetrics, iis, mssql]
        processors: [metrics_filter]

これらの構成の詳細については、Logging 構成指標構成をご覧ください。

ユーザー指定の構成

組み込みの構成をオーバーライドするには、ユーザー構成ファイルに新しい構成要素を追加します。Ops エージェントの構成を次のファイルに配置します。

  • Linux の場合: /etc/google-cloud-ops-agent/config.yaml

  • Windows の場合: C:\Program Files\Google\Cloud Operations\Ops Agent\config\config.yaml

ユーザー指定の構成は、エージェントの再起動時に組み込み構成とマージされます。

組み込みのレシーバー、プロセッサ、パイプラインをオーバーライドするには、config.yaml ファイルで同じ識別子で宣言して再定義します。

たとえば、指標の組み込み構成には、60 秒の収集間隔を指定する hostmetrics レシーバーが含まれています。ホスト指標の収集間隔を 30 秒に変更するには、次の例に示すように collection_interval 値を 30 秒に設定する hostmetrics という指標レシーバーを config.yaml ファイルに含めます。

metrics:
  receivers:
    hostmetrics:
      type: hostmetrics
      collection_interval: 30s

組み込み構成を変更するその他の例については、ロギング構成指標の構成をご覧ください。

ロギングまたは指標データの収集をオフにすることもできます。これらの変更については、ロギングの service 構成指標 service 構成の例で説明しています。

ロギング構成

logging 構成では、前述の構成モデルを使用します。

  • receivers: この要素は、ログファイルから収集するデータを記述します。このデータは <timestamp, record> モデルにマッピングされます。
  • processors: この省略可能な要素は、エージェントが収集した情報を変更する方法を記述します。
  • service: この要素は、レシーバーとプロセッサをリンクしてパイプラインと呼ばれるデータフローを作成します。service 要素には、複数のパイプライン定義を含めることができる pipelines 要素が含まれます。

各レシーバーと各プロセッサは、複数のパイプラインで使用できます。

以降のセクションで、これらの各要素について説明します。

ロギング レシーバー

receivers 要素には、RECEIVER_ID で識別される一連のレシーバーが含まれます。レシーバーは、ログを取得する方法を記述します。たとえば、tail ファイル、TCP ポート、Windows イベントログなどを使用します。

ロギング レシーバーの構造

各レシーバーには、識別子 RECEIVER_IDtype 要素を含める必要があります。有効な型は次のとおりです。

  • files: ディスク上のファイルをテーリングすることによってログを収集します。
  • syslog: TCP や UDP を介して syslog を収集します。
  • tcp(Ops エージェント バージョン 2.3.0 以降で使用可能): TCP ポートをリッスンして JSON 形式のログを収集します。
  • windows_event_log(Windows のみ): Windows のイベントログを収集します。
  • systemd_journald(Linux の Ops エージェント バージョン 2.4.0 以降で使用可能): systemd-journald サービスからログを収集します。

receivers 構造は次のようになります。

receivers:
  RECEIVER_ID:
    type: files
    ...
  RECEIVER_ID_2:
    type: syslog
    ...

type 要素の値によっては、次のような他の構成オプションが存在する場合もあります。

  • files レシーバー

    • include_paths: 必須。ファイルのテーリングで読み込むファイルシステムのパスのリスト。パスには /var/log/*.log のように、ワイルドカード(*)を使用できます。

      一般的なアプリケーション ログファイルのリストについては、一般的なログファイルをご覧ください。

    • exclude_paths: 省略可。include_paths の照合で除外するファイルシステムのパスパターンのリスト。

    • wildcard_refresh_interval: 省略可。include_paths 内のワイルドカード ファイルパスの更新間隔。期間で指定します(例: 30s2m)。このプロパティは、ログファイルがデフォルトの間隔よりも速くローテーションされる、ロギングのスループットが高い場合に役立ちます。指定しない場合、デフォルトの間隔は 60 秒です。

  • syslog レシーバー

    • transport_protocol: 省略可。サポートされる値: tcpudpデフォルトは tcp です。

      transport_protocol の値が tcp の場合、次の追加オプションを使用できます。

      • listen_host: 省略可。リッスンする IP アドレス。 デフォルト値は 0.0.0.0 です。

      • listen_port: 省略可。リッスンするポート。 デフォルト値は 5140 です。

  • tcp レシーバー

    • format: 必須。ログ形式。サポートされている値: json

    • listen_host: 省略可。リッスンする IP アドレス。 デフォルト値は 127.0.0.1 です。

    • listen_port: 省略可。リッスンするポート。 デフォルト値は 5170 です。

  • windows_event_log レシーバー(Windows のみ):

    • channels: 必須。ログの読み取りを行う Windows イベント ログチャネルのリスト。

ロギング レシーバーの例

files シレーバーのサンプル:

receivers:
  RECEIVER_ID:
    type: files

    include_paths: [/var/log/*.log]
    exclude_paths: [/var/log/not-this-one.log]

syslog レシーバーの例:

receivers:
  RECEIVER_ID:
    type: syslog

    transport_protocol: tcp
    listen_host: 0.0.0.0
    listen_port: 5140

tcp レシーバーの例:

receivers:
  RECEIVER_ID:
    type: tcp

    format: json
    listen_host: 127.0.0.1
    listen_port: 5170

windows_event_log レシーバーの例(Windows のみ):

receivers:
  RECEIVER_ID:
    type: windows_event_log

    channels: [System,Application,Security]

systemd_journald レシーバーの例:

receivers:
  RECEIVER_ID:
    type: systemd_journald

ロギング プロセッサ

オプションの processors 要素には、PROCESSOR_ID で識別される一連の処理ディレクティブが含まれます。プロセッサは、レシーバーによって収集された情報を操作する方法を記述します。

ロギング プロセッサの構造

各プロセッサには一意の識別子があり、type 要素が含まれている必要があります。有効な型は次のとおりです。

  • parse_json
  • parse_regex

processors 構造は次のようになります。

processors:
  PROCESSOR_ID:
    type: parse_json
    ...
  PROCESSOR_ID_2:
    type: parse_regex
    ...

type 要素の値に応じて、次のような構成オプションを使用できます。

  • parse_json プロセッサと parse_regex プロセッサの両方:

    • field: 省略可。レコードで解析するフィールドの名前。 field オプションが指定されていない場合、プロセッサは message フィールドを解析します。

    • time_key: 省略可。ログエントリにタイムスタンプを含むフィールドがある場合、このオプションでそのフィールドの名前を指定します。抽出された値は、生成される LogEntrytimestamp フィールドの設定に使用され、ペイロードから削除されます。

      time_key オプションを指定する場合は、以下も指定する必要があります。

      • time_format: time_key を使用する場合は必須。このオプションで time_key フィールドの形式を指定すると、認識と分析が適切に行われます。フォーマットの詳細については、strptime(3) ガイドをご覧ください。
  • parse_regex プロセッサ

    • regex: 必須。フィールドの解析に使用される正規表現。式には、一致したサブ式のキー名(例: "^(?<time>[^ ]*) (?<severity>[^ ]*) (?<msg>.*)$")を含める必要があります。

      ログファイルから情報を抽出する一連の正規表現については、一般的なログファイルをご覧ください。

ロギング プロセッサの例

parse_json プロセッサの例:

processors:
  PROCESSOR_ID:
    type: parse_json

    field:       message
    time_key:    time
    time_format: "%Y-%m-%dT%H:%M:%S.%L%Z"

parse_regex プロセッサの例:

processors:
  PROCESSOR_ID:
    type: parse_regex

    field:       message
    regex:       "^(?<time>[^ ]*) (?<severity>[^ ]*) (?<msg>.*)$"
    time_key:    time
    time_format: "%Y-%m-%dT%H:%M:%S.%L%Z"

構造化ペイロードの特殊フィールド

エージェントが Logging API に書き込む LogEntry オブジェクトに特定のフィールドを設定できます。 構造化ログレコードの場合、Ops エージェントは、次の表に示すフィールドを jsonPayload 構造から削除します。

レコード フィールド LogEntry フィールド

オプション 1



"timestamp": {
  "seconds": CURRENT_SECONDS,
  "nanos": CURRENT_NANOS,
}

オプション 2



{
  "timestampSeconds": CURRENT_SECONDS,
  "timestampNanos": CURRENT_NANOS,
}
timestamp
receiver_id(レコード フィールドではない) logName
logging.googleapis.com/severity severity
logging.googleapis.com/labels labels
logging.googleapis.com/operation operation
logging.googleapis.com/sourceLocation sourceLocation

残りの構造化レコードのフィールドは、jsonPayload 構造の一部として残ります。

ロギング サービス

このロギング サービスは、Ops エージェント自身のログの詳細度をカスタマイズし、ロギングのレシーバーとプロセッサをパイプラインにリンクします。service セクションには、log_levelpipelines という 2 つの要素があります。

ログの詳細レベル

log_level(Ops エージェント バージョン 2.6.0 以降で利用可能)は、Ops エージェント ロギングのサブモジュール自体のログの詳細度をカスタマイズします。デフォルトは info です。使用できるオプションは errorwarninfodebugtrace です。

ロギング パイプライン

pipelines には、複数のパイプライン ID と定義を含めることができます。各 pipeline 定義は、次の要素で構成されます。

  • receivers: 新しいパイプラインで必要です。ロギング レシーバーで説明されているレシーバー ID のリストです。リスト内のレシーバー ID の順序に意味はありません。パイプラインは、リストされたすべてのレシーバーからデータを収集します。

  • processors: 省略可。ロギング プロセッサで説明されているプロセッサ ID のリストです。リスト内のプロセッサ ID の順序は重要です。各レコードは、リストに記載された順序でプロセッサによって実行されます。

ロギングの service 構成の例

service 構成の構造は次のとおりです。

service:
  log_level: CUSTOM_LOG_LEVEL
  pipelines:
    PIPELINE_ID:
      receivers:  [...]
      processors: [...]
    PIPELINE_ID_2:
      receivers:  [...]
      processors: [...]

組み込みのロギング取り込みを無効にするには、空の receivers リストでデフォルトのパイプラインを再定義します。プロセッサは設定しません。ロギング構成全体は、次のようになります。

logging:
  service:
    pipelines:
      default_pipeline:
        receivers: []

次の service 構成は、ID が custom_pipeline であるパイプラインを定義します。

logging:
  service:
    pipelines:
      custom_pipeline:
        receivers:
        - RECEIVER_ID
        processors:
        - PROCESSOR_ID

次の service 構成では、ログのサブモジュールのログの詳細度が debug になるようにカスタマイズします。

logging:
  service:
    log_level: debug

一般的なログファイル

次の表は、よく使用されるアプリケーションの一般的なログファイルを示したものです。

アプリケーション 一般的なログファイル
apache Apache のログファイルについては、サードパーティ アプリケーションのモニタリング: Apache ウェブサーバーをご覧ください。
cassandra Cassandra のログファイルについては、サードパーティ アプリケーションのモニタリング: Cassandra をご覧ください。
Chef /var/log/chef-server/bookshelf/current
/var/log/chef-server/chef-expander/current
/var/log/chef-server/chef-pedant/http-traffic.log
/var/log/chef-server/chef-server-webui/current
/var/log/chef-server/chef-solr/current
/var/log/chef-server/erchef/current
/var/log/chef-server/erchef/erchef.log.1
/var/log/chef-server/nginx/access.log
/var/log/chef-server/nginx/error.log
/var/log/chef-server/nginx/rewrite-port-80.log
/var/log/chef-server/postgresql/current
GitLab /home/git/gitlab/log/application.log
/home/git/gitlab/log/githost.log
/home/git/gitlab/log/production.log
/home/git/gitlab/log/satellites.log
/home/git/gitlab/log/sidekiq.log
/home/git/gitlab/log/unicorn.stderr.log
/home/git/gitlab/log/unicorn.stdout.log
/home/git/gitlab-shell/gitlab-shell.log
Jenkins /var/log/jenkins/jenkins.log
jetty /var/log/jetty/out.log
/var/log/jetty/*.request.log
/var/log/jetty/*.stderrout.log
joomla /var/www/joomla/logs/*.log
magento /var/www/magento/var/log/exception.log
/var/www/magento/var/log/system.log
/var/www/magento/var/report/*
mediawiki /var/log/mediawiki/*.log
memcached /var/log/memcached.log
MongoDB /var/log/mongodb/*.log
mysql MySQL のログファイルについては、サードパーティ アプリケーションのモニタリング: MySQL をご覧ください。
nginx nginx ログファイルについては、サードパーティ アプリケーションのモニタリング: nginx をご覧ください。
postgres /var/log/postgres*/*.log
/var/log/pgsql/*.log
Puppet /var/log/puppet/http.log
/var/log/puppet/masterhttp.log
puppet-enterprise /var/log/pe-activemq/activemq.log
/var/log/pe-activemq/wrapper.log
/var/log/pe-console-auth/auth.log
/var/log/pe-console-auth/cas_client.log
/var/log/pe-console-auth/cas.log
/var/log/pe-httpd/access.log
/var/log/pe-httpd/error.log
/var/log/pe-httpd/other_vhosts_access.log
/var/log/pe-httpd/puppetdashboard.access.log
/var/log/pe-httpd/puppetdashboard.error.log
/var/log/pe-httpd/puppetmasteraccess.log
/var/log/pe-mcollective/mcollective_audit.log
/var/log/pe-mcollective/mcollective.log
/var/log/pe-puppet-dashboard/certificate_manager.log
/var/log/pe-puppet-dashboard/event-inspector.log
/var/log/pe-puppet-dashboard/failed_reports.log
/var/log/pe-puppet-dashboard/live-management.log
/var/log/pe-puppet-dashboard/mcollective_client.log
/var/log/pe-puppet-dashboard/production.log
/var/log/pe-puppetdb/pe-puppetdb.log
/var/log/pe-puppet/masterhttp.log
/var/log/pe-puppet/rails.log
rabbitmq /var/log/rabbitmq/*.log
/var/log/rabbitmq/*-sasl.log
/var/log/rabbitmq/startup_err
/var/log/rabbitmq/startup_log
redis Redis のログファイルについては、サードパーティ アプリケーションのモニタリング: Redis をご覧ください。
redmine /var/log/redmine/*.log
salt /var/log/salt/key
/var/log/salt/master
/var/log/salt/minion
/var/log/salt/syndic.loc
solr /var/log/solr/*.log
sugarcrm /var/www/*/sugarcrm.log
syslog /var/log/syslog/var/log/messages
tomcat /var/log/tomcat*/catalina.out
/var/log/tomcat*/localhost.*.log
/var/log/tomcat*/localhost_access_log.%Y-%m-%d.txt
zookeeper /var/log/zookeeper/zookeeper.log
/var/log/zookeeper/zookeeper_trace.log

次の表は、ログの解析に役立つ正規表現を示したものです。

アプリケーション 正規表現
MongoDB ^(?<time>[^ ]*)\s+(?<severity>\w)\s+(?<component>[^ ]+)\s+\[(?<context>[^\]]+)]\s+(?<message>.*?) *(?<ms>(\d+))?(:?ms)?$

指標の構成

metrics 構成では、前述の構成モデルを使用します。

  • receivers: レシーバー定義のリスト。receiver は指標のソースを記述します。(cpumemory などのシステム指標など)。 このリストのレシーバーは、複数のパイプラインで共有できます。
  • processors: プロセッサ定義のリスト。processor は、レシーバーによって収集された指標を変更する方法を表します。
  • service: pipeline 定義のリストである pipelines セクションが含まれます。pipeline は、receivers のリストと processors のリストを接続して、データフローを形成します。

以降のセクションで、これらの各要素について説明します。

指標レシーバー

receivers 要素にはレシーバー定義のセットが含まれます。レシーバーは、cpumemory など、指標を取得する場所を記述します。レシーバーは複数のパイプラインで共有できます。

指標レシーバーの構造

各レシーバーには、識別子 RECEIVER_IDtype 要素を含める必要があります。有効な型は次のとおりです。

  • hostmetrics
  • iis(Windows のみ)
  • mssql(Windows のみ)

レシーバーは、オペレーションの collection_interval オプションも指定できます。この値は期間の形式です(例: 30s2m)。デフォルト値は 60s です。

これらのレシーバー タイプはそれぞれ、一連の指標を収集します。含まれる特定の指標の詳細については、レシーバー タイプによって取り込まれる指標をご覧ください。

レシーバーはタイプごとに 1 つのみ作成できます。たとえば、hostmetrics タイプのレシーバーを 2 つ定義することはできません。

指標レシーバーでの収集間隔の変更

重要なワークロードの中には、迅速なアラートを必要とするものがあります。指標の収集間隔を短くすることで、より感度の高いアラートを構成できます。アラートの評価方法については、アラートの動作をご覧ください。

たとえば、次のレシーバーは、ホスト指標(レシーバー ID は hostmetrics)の収集間隔をデフォルトの 60 秒から 10 秒に変更します。

metrics:
  receivers:
    hostmetrics:
      type: hostmetrics
      collection_interval: 10s

同じ手法を使用して、Windows の iismssql の指標レシーバーで収集間隔をオーバーライドすることもできます。

レシーバーによって取り込まれた指標

Ops エージェントによって取り込まれた指標には、agent.googleapis.com/GROUP のパターンで始まる識別子が含まれています。GROUP コンポーネントは、関連する一連の指標を識別します。これらには cpunetwork などの値があります。

hostmetrics レシーバは、次の指標グループを取得します。詳しくは、Ops エージェント指標ページの各グループのリンク先のセクションをご覧ください。

グループ 指標
cpu 1 分間隔の CPU 負荷
5 分間隔の CPU 負荷
15 分間隔の CPU 負荷
CPU の使用量(CPU 番号と状態のラベル付き)
CPU の使用率(CPU 番号と状態のラベル付き)
disk ディスク読み取りバイト数(デバイスラベル付き)
ディスク書き込みバイト数(デバイスラベル付き)
ディスク I/O 時間(デバイスラベル付き)
ディスク総所要 I/O 時間(デバイスラベル付き)
ディスクの保留中の処理(デバイスラベル付き)
ディスクマージ処理(デバイスと方向のラベル付き)
ディスク処理(デバイスと方向のラベル付き)
ディスク処理時間(デバイスと方向のラベル付き)
デバイス使用量(ディスクと状態のラベル付き)
ディスク使用率(デバイスと状態のラベル付き)
interface
Linux のみ
ネットワーク エラーの合計数
ネットワーク上で送信されたパケットの合計数
ネットワーク上で送信されたバイトの合計数
memory メモリ使用量、状態(buffered、cached、free、slab、used)のラベル付き
メモリ使用率、状態(buffered、cached、free、slab、used)のラベル付き
network TCP 接続数(ポートと TCP の状態のラベル付き)
swap スワップ I/O 処理(方向のラベル付き)
スワップ使用バイト数(デバイスと状態のラベル付き)
スワップ使用率(デバイスと状態のラベル付き)
pagefile
Windows のみ
状態で使用されるページファイルの現在の割合
processes プロセス数(状態ラベル付き)
プロセス フォーク数
プロセスごとのディスク読み取り I/O(プロセス名 + その他のラベル付き)
プロセスごとディスク書き込み I/O(プロセス名 + その他のラベル付き)
プロセスごとの RSS 使用量(プロセス名 + その他のラベル付き)
プロセスごとの VM 使用量(プロセス名 + その他のラベル付き)

iis レシーバー(Windows のみ)が、iis グループの指標を取り込みます。詳しくは、エージェントの指標ページをご覧ください。

グループ 指標
iis
Windows のみ
現在の IIS へのオープン接続
IIS によって転送されたネットワーク バイト
IIS に開かれた接続
IIS に対して行われたリクエスト

mssql レシーバー(Windows のみ)が、mssql グループの指標を取り込みます。詳細については、エージェントの指標ページをご覧ください。

グループ 指標
mssql
Windows のみ
現在の SQL Server へのオープン接続
SQL Server の 1 秒あたりのトランザクション合計数
SQL Server の 1 秒あたりの書き込みトランザクション

指標プロセッサ

processor 要素には、一連のプロセッサ定義が含まれます。プロセッサは、除外するレシーバー タイプの指標を記述します。サポートされているタイプは、exclude_metrics のみで、metrics_pattern オプションが指定されます。この値は、レシーバーによって収集されたグループから除外する指標タイプに一致する glob のリストです(例: agent.googleapis.com/cpu/*agent.googleapis.com/processes/*)。個々の指標の完全修飾名を確認するには、Ops エージェントの指標ページのグループの表をご覧ください。

指標プロセッサの例

次の例は、組み込み構成で指定される exclude_metrics プロセッサを示します。このプロセッサは空の metrics_pattern 値を指定するため、指標は除外されません。

processors:
  metrics_filter:
    type: exclude_metrics
    metrics_pattern: []

Ops エージェントによるすべてのプロセス指標の収集を無効にするには、次の行を config.yaml ファイルに追加します。

metrics:
  processors:
    metrics_filter:
      type: exclude_metrics
      metrics_pattern:
      - agent.googleapis.com/processes/*

この場合、metrics サービスのデフォルト パイプラインに適用される metrics_filter プロセッサ内のコレクションから、プロセス指標が除外されます。

指標サービス

指標サービスは、Ops エージェントの指標モジュール自体のログの詳細度をカスタマイズし、指標レシーバーとプロセッサをパイプラインにリンクします。service セクションには、log_levelpipelines という 2 つの要素があります。

指標の詳細レベル

log_level(Ops エージェント バージョン 2.6.0 以降で利用可能)は、Ops エージェントの指標のサブモジュール自体のログの詳細度をカスタマイズします。デフォルトは info です。使用できるオプションは errorwarninfodebug です。

指標パイプライン

service セクションには、複数のパイプライン ID と定義を含む単一の要素 pipelines があります。各 pipeline 定義は、次の要素で構成されます。

  • receivers: 新しいパイプラインで必要です。指標レシーバーで説明されているレシーバー ID のリストです。リスト内のレシーバー ID の順序に意味はありません。パイプラインは、リストされたすべてのレシーバーからデータを収集します。

  • processors: 省略可。指標プロセッサで説明されているプロセッサ ID のリストです。リスト内のプロセッサ ID の順序は重要です。各指標ポイントは、リストに記載された順序でプロセッサによって実行されます。

指標 service の構成例

service 構成の構造は次のとおりです。

service:
  log_level: CUSTOM_LOG_LEVEL
  pipelines:
    PIPELINE_ID:
      receivers:  [...]
      processors: [...]
    PIPELINE_ID_2:
      receivers:  [...]
      processors: [...]

ホスト指標の組み込みの取り込みを無効にするには、空の receivers リストを使用してデフォルトのパイプラインを再定義します。プロセッサは設定しません。指標の構成全体は、次のようになります。

metrics:
  service:
    pipelines:
      default_pipeline:
        receivers: []

次の例では、Windows 用の組み込みの service 構成を示します。

metrics:
  service:
    pipelines:
      default_pipeline:
        receivers:
        - hostmetrics
        - iis
        - mssql
        processors:
        - metrics_filter

次の service 構成では、指標のサブモジュールのログの詳細度が debug になるようにカスタマイズします。

metrics:
  service:
    log_level: debug