Configura el agente de operaciones

En este documento, se proporcionan detalles sobre las opciones de configuración personalizadas y predeterminadas del agente de operaciones. Lee este documento si te encuentras en alguna de las siguientes situaciones:

  • Quieres cambiar la configuración del agente de operaciones a fin de lograr estos objetivos:

  • Te interesa conocer los detalles técnicos de la configuración del agente de operaciones.

Modelo de configuración

El agente de operaciones usa una configuración predeterminada integrada. no puedes modificar directamente esta configuración integrada. En su lugar, cuando se reinicia el agente, creas un archivo de anulaciones que se combina con la configuración integrada.

Los componentes básicos de la configuración son los siguientes:

  • receivers: Este elemento describe lo que recopila el agente.
  • processors: Este elemento describe cómo el agente puede modificar la información recopilada.
  • service: Este elemento vincula receptores y procesadores para crear flujos de datos, llamados canalizaciones. El elemento service contiene un elemento pipelines, que puede contener varias canalizaciones.

La configuración integrada consta de estos elementos, y debes usar los mismos elementos para anular esa configuración integrada.

Configuración integrada

La configuración integrada del agente de operaciones define la colección predeterminada de los registros y las métricas. A continuación, se muestra la configuración integrada para Linux y Windows:

Linux

De forma predeterminada, el agente de operaciones recopila registros syslog basados en archivos y métricas de host.

Para obtener más información sobre las métricas recopiladas, consulta Métricas transferidas por los tipos de receptor.

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

De forma predeterminada, el agente de operaciones recopila registros de eventos de Windows de los canales System, Application y Security, así como las métricas del host, las de IIS y las de SQL Server.

Para obtener más información sobre las métricas recopiladas, consulta Métricas transferidas por los tipos de receptor.

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]

Esta configuración se analiza en más detalle en Configuración de Logging y Configuración de métricas.

Configuración especificada por el usuario

Para anular la configuración integrada, debes agregar elementos de configuración nuevos al archivo de configuración del usuario. Coloca la configuración para el agente de operaciones en los siguientes archivos:

  • Para Linux: /etc/google-cloud-ops-agent/config.yaml

  • Para Windows: C:\Program Files\Google\Cloud Operations\Ops Agent\config\config.yaml.

Cualquier configuración especificada por el usuario se combina con la configuración integrada cuando el agente se reinicia.

A fin de anular un receptor, un procesador o una canalización integrados, debes redefinir su definición en el archivo config.yaml; para ello, decláralo con el mismo identificador.

Por ejemplo, la configuración integrada para las métricas incluye un receptor hostmetrics que especifica un intervalo de recopilación de 60 segundos. A fin de cambiar el intervalo de recopilación para las métricas del host a 30 segundos, incluye un receptor de métricas llamado hostmetrics en tu archivo config.yaml que establezca el valor collection_interval en 30 segundos, como se muestra a continuación: se muestra en el siguiente ejemplo:

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

Para ver otros ejemplos de cambio de las opciones de configuración integradas, consulta Configuración de Logging y Configuración de métricas.

También puedes desactivar la recopilación de datos de registros o métricas. Estos cambios se describen en los ejemplos de configuración de service de registro y configuraciones de métricas service.

Opciones de configuración del registro

La configuración de logging usa el modelo de configuración descrito antes:

  • receivers: Este elemento describe los datos que se deben recopilar de los archivos de registro. Estos datos se mapean a un modelo <timestamp, record>.
  • processors: Este elemento opcional describe cómo el agente puede modificar la información recopilada.
  • service: Este elemento vincula receptores y procesadores para crear flujos de datos, llamados canalizaciones. El elemento service contiene un elemento pipelines, que puede incluir varias definiciones de canalización.

Cada receptor y cada procesador se pueden usar en varias canalizaciones.

En las siguientes secciones, se describe cada uno de estos elementos.

Receptores de registros

El elemento receivers contiene un conjunto de receptores, cada uno identificado por un RECEIVER_ID. Una app receptora describe cómo recuperar los registros. por ejemplo, mediante la visualización del final de los archivos, con un puerto TCP o desde el Registro de acontecimientos de Windows.

Estructura de los receptores de registros

Cada receptor debe tener un identificador, RECEIVER_ID, y debe incluir un elemento type. Los tipos válidos son los siguientes:

  • files
  • syslog
  • windows_event_log (solo para Windows)

La estructura receivers se ve de la siguiente manera:

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

Según el valor del elemento type, puede haber otras opciones de configuración, como las siguientes:

  • Receptores files:

    • include_paths: Obligatorio. Una lista de rutas de acceso del sistema de archivos que se leerán mediante la visualización del final de cada archivo. Se puede usar un comodín (*) en las rutas. por ejemplo, /var/log/*.log.

      Para obtener una lista de archivos de registro de aplicaciones comunes, consulta Archivos de registro comunes.

    • exclude_paths: Opcional Una lista de patrones de ruta de acceso del sistema de archivos que se excluirán del conjunto que coincide con include_paths.

  • Receptores syslog:

    • transport_protocol: Opcional Valores admitidos: tcp y udp. El predeterminado es tcp.

      Si el valor de transport_protocol es tcp, se pueden usar las siguientes opciones adicionales:

      • listen_host: Opcional Una dirección IP en la que se escuchará. El valor predeterminado es 0.0.0.0.

      • listen_port: Opcional Un puerto en el que se escuchará. El valor predeterminado es 5140.

  • Receptores de windows_event_log (solo para Windows):

    • channels: Obligatorio. Una lista de canales de registros de acontecimientos de Windows desde los que se leen los registros.

Ejemplos de receptores de registros

Ejemplo de receptor files:

receivers:
  RECEIVER_ID:
    type: files

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

Ejemplo de receptor syslog:

receivers:
  RECEIVER_ID:
    type: syslog

    transport_protocol: tcp
    listen_host: 0.0.0.0
    listen_port: 5140

Ejemplo de receptor windows_event_log (solo para Windows):

receivers:
  RECEIVER_ID:
    type: windows_event_log

    channels: [System,Application,Security]

Procesadores de registros

El elemento opcional processors contiene un conjunto de directivas de procesamiento, cada una identificada por una PROCESSOR_ID. Un procesador describe cómo manipular la información que recopila un receptor.

Estructura de los procesadores de registros

Cada procesador debe tener un identificador único e incluir un elemento type. Los tipos válidos son los siguientes:

  • parse_json
  • parse_regex

La estructura processors se ve de la siguiente manera:

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

Según el valor del elemento type, existen otras opciones de configuración, como las siguientes:

  • Procesadores parse_json y parse_regex:

    • field: Opcional El nombre del campo en el registro que se analizará. Si no se especifica la opción field, el procesador analiza el campo message.

    • time_key: Opcional Si la entrada de registro proporciona un campo con una marca de tiempo, esta opción especifica el nombre de ese campo. El valor extraído se usa para establecer el campo timestamp del LogEntry resultante y se quita de la carga útil.

      Si se especifica la opción time_key, también debes especificar lo siguiente:

      • time_format: Es obligatorio si se usa time_key. Esta opción especifica el formato del campo time_key para que se pueda reconocer y analizar de forma adecuada. Para obtener detalles del formato, consulta la guía de strptime(3).
  • Procesadores parse_regex:

    • regex: Obligatorio. La expresión regular para analizar el campo. La expresión debe incluir nombres de clave para las subexpresiones que coincidan; por ejemplo, "^(?<time>[^ ]*) (?<severity>[^ ]*) (?<msg>.*)$".

      Si quieres obtener un conjunto de expresiones regulares para extraer información de archivos de registro, consulta Archivos de registro comunes.

Ejemplos de procesadores de registros

Procesador de muestra parse_json:

processors:
  PROCESSOR_ID:
    type: parse_json

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

Procesador de muestra 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"

Campos especiales en cargas útiles estructuradas

Puedes configurar campos específicos en el objeto LogEntry que el agente escribe en la API de Logging. Para los registros estructurados, el agente de operaciones quita los campos enumerados en la siguiente tabla de la estructura jsonPayload:

Campo de registro Campo LogEntry

Opción 1



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

Opción 2



{
  "timestampSeconds": CURRENT_SECONDS,
  "timestampNanos": CURRENT_NANOS,
}
timestamp
receiver_id (no es un campo de registro) logName
logging.googleapis.com/httpRequest httpRequest
logging.googleapis.com/severity severity
logging.googleapis.com/labels labels
logging.googleapis.com/operation operation
logging.googleapis.com/sourceLocation sourceLocation

Los demás campos de registro estructurado formarán parte de la estructura jsonPayload.

Servicio de registros

El servicio de registro vincula los receptores y los procesadores de registros en canalizaciones.

La sección service tiene un solo elemento, pipelines, que puede contener varios ID de canalización y definiciones. Cada definición de pipeline consta de los siguientes elementos:

  • receivers: Es obligatorio para canalizaciones nuevas. Una lista de ID de receptores, como se describe en Receptores de registros No importa el orden de los ID de receptores en la lista. La canalización recopila datos de todos los receptores enumerados.

  • processors: Opcional Una lista de ID de procesadores, como se describe en Procesadores de registros. El orden de los ID de procesador de la lista es importante. Cada registro se ejecuta a través de los procesadores en el orden indicado.

Una configuración de service tiene la siguiente estructura:

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

Ejemplo de registros de configuraciones de service

Para desactivar la transferencia de registros incorporada, redefine la canalización predeterminada con una lista receivers vacía y sin procesadores. Toda la configuración de registro se ve de la siguiente manera:

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

La siguiente configuración de service define una canalización con el ID custom_pipeline:

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

Archivos de registro comunes

En la siguiente tabla, se enumeran los archivos de registro comunes para las aplicaciones de uso frecuente:

Aplicación Archivos de registro comunes
Apache /var/log/apache*/access.log
/var/log/httpd/access_log
/var/log/apache*/error.log
/var/log/httpd/error_log
cassandra /var/log/cassandra/cassandra.log
/var/log/cassandra/output.log
/var/log/cassandra/system.log
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
muelle /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 /var/log/mysql.log
/var/log/mysql/mysql.log
/var/log/mysql/mysql-slow.log
nginx /var/log/nginx/access.log
/var/log/nginx/error.log
postgres /var/log/postgres*/*.log
/var/log/pgsql/*.log
marioneta /var/log/puppet/http.log
/var/log/puppet/masterhttp.log
títeres-empresa /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
conejo mq /var/log/rabbitmq/*.log
/var/log/rabbitmq/*-sasl.log
/var/log/rabbitmq/startup_err
/var/log/rabbitmq/startup_log
Redis /var/log/redis*.log
/var/log/redis/*.log
Redmine /var/log/redmine/*.log
sal /var/log/salt/key
/var/log/salt/master
/var/log/salt/minion
/var/log/salt/syndic.loc
solr /var/log/solr/*.log
Crema de azúcar /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

En la siguiente tabla, se enumeran algunas expresiones regulares que son útiles para analizar registros:

Aplicación Expresión regular
Apache ^(?<host>[^ ]*) [^ ]* (?<user>[^ ]*) \[(?<time>[^\]]*)\] "(?<method>\S+)(?: +(?<path>[^\"]*?)(?: +\S*)?)?" (?<code>[^ ]*) (?<size>[^ ]*)(?: "(?<referer>[^\"]*)" "(?<agent>[^\"]*)")?$
Apache2 ^(?<host>[^ ]*) [^ ]* (?<user>[^ ]*) \[(?<time>[^\]]*)\] "(?<method>\S+)(?: +(?<path>[^ ]*) +\S*)?" (?<code>[^ ]*) (?<size>[^ ]*)(?: "(?<referer>[^\"]*)" "(?<agent>.*)")?$
error apache_error ^\[[^ ]* (?<time>[^\]]*)\] \[(?<level>[^\]]*)\](?: \[pid (?<pid>[^\]]*)\])?( \[client (?<client>[^\]]*)\])? (?<message>.*)$
mongodb ^(?<time>[^ ]*)\s+(?<severity>\w)\s+(?<component>[^ ]+)\s+\[(?<context>[^\]]+)]\s+(?<message>.*?) *(?<ms>(\d+))?(:?ms)?$
nginx ^(?<remote>[^ ]*) (?<host>[^ ]*) (?<user>[^ ]*) \[(?<time>[^\]]*)\] "(?<method>\S+)(?: +(?<path>[^\"]*?)(?: +\S*)?)?" (?<code>[^ ]*) (?<size>[^ ]*)(?: "(?<referer>[^\"]*)" "(?<agent>[^\"]*)")

Opciones de configuración de métricas

La configuración de metrics usa el modelo de configuración descrito antes:

  • receivers: Una lista de definiciones de receptores. Un receiver describe el origen de las métricas. por ejemplo, las métricas del sistema, como cpu o memory. Los receptores de esta lista se pueden compartir entre varias canalizaciones.
  • processors: Una lista de definiciones de procesadores. Un processor describe cómo modificar las métricas que recopila un receptor.
  • service: Contiene una sección pipelines que es una lista de definiciones de pipeline. Una pipeline conecta una lista de receivers y una lista de processors para formar el flujo de datos.

En las siguientes secciones, se describe cada uno de estos elementos.

Receptores de métricas

El elemento receivers contiene un conjunto de definiciones de receptor. Un receptor describe desde dónde recuperar las métricas, como cpu y memory. Un receptor se puede compartir entre varias canalizaciones.

Estructura de los receptores de métricas

Cada receptor debe tener un identificador, RECEIVER_ID, y debe incluir un elemento type. Los tipos válidos son los siguientes:

  • hostmetrics
  • iis (solo para Windows)
  • mssql (solo para Windows)

Un receptor también puede especificar la opción collection_interval de la operación. El valor tiene el formato de duración, por ejemplo, 30s o 2m. El valor predeterminado es 60s.

Cada uno de estos tipos de receptor recopila un conjunto de métricas. a fin de obtener información sobre las métricas específicas incluidas, consulta Métricas que transfieren los tipos de receptores.

Puedes crear solo un receptor para cada tipo. Por ejemplo, no puedes definir dos receptores del tipo hostmetrics.

Cambia el intervalo de recopilación en los receptores de métricas

Algunas cargas de trabajo críticas pueden requerir alertas rápidas. Si reduces el intervalo de recopilación para las métricas, puedes configurar alertas más sensibles. Para obtener información sobre cómo se evalúan las alertas, consulta Comportamiento de las alertas.

Por ejemplo, el siguiente receptor cambia el intervalo de recopilación para las métricas del host (el ID del receptor es hostmetrics) del valor predeterminado de 60 segundos a 10 segundos:

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

También puedes anular el intervalo de recopilación para los receptores de métricas iis y mssql de Windows mediante la misma técnica.

Métricas transferidas por los receptores

Las métricas que transfiere el agente de operaciones tienen identificadores que comienzan con el siguiente patrón: agent.googleapis.com/GROUP. El componente GROUP identifica un conjunto de métricas relacionadas. Tiene valores como cpu, network y otros.

La app receptora hostmetrics transfiere los siguientes grupos de métricas. Para obtener más información, consulta la sección vinculada de cada grupo en la página Métricas del agente de operaciones.

Grupo Métrica
cpu Carga de CPU en intervalos de 1 minuto
Carga de CPU en intervalos de 5 minutos
Carga de CPU en intervalos de 15 minutos
Uso de CPU, con etiquetas para el número y el estado de la CPU
Porcentaje de uso de CPU, con etiquetas para el número y estado de la CPU
disk Bytes de lectura del disco, con etiqueta para el dispositivo
Bytes de disco escritos, con etiqueta para el dispositivo
Tiempo de E/S del disco, con etiqueta para el dispositivo
Disco ponderado I/O tiempo, con etiqueta para el dispositivo
Operaciones pendientes del disco, con etiqueta para el dispositivo
Operaciones combinadas de disco, con etiquetas para el dispositivo y la dirección
Operaciones de disco, con etiquetas para el dispositivo y la dirección
Tiempo de operación del disco, con etiquetas para el dispositivo y la dirección
Uso del disco, con etiquetas para el dispositivo y el estado
Uso del disco, con etiquetas para el dispositivo y el estado
interface
Solo en Linux
Recuento total de errores de red
Recuento total de paquetes enviados en la red
Cantidad total de bytes enviados de la red
memory Uso de memoria, con etiqueta para el estado (almacenado en búfer, almacenado en caché, libre, en bloque, usada)
Porcentaje de uso de memoria, con etiqueta para el estado (almacenado en búfer, almacenado en caché, libre, en bloque, usada)
network Recuento de conexiones TCP, con etiquetas para el puerto y estado TCP
swap Operaciones de intercambio de E/S, con etiqueta para la dirección
Bytes de intercambio usados, con etiquetas para el dispositivo y el estado
Porcentaje de intercambio usado, con etiquetas para el dispositivo y el estado
pagefile
Solo en Windows
Porcentaje actual del archivo de paginación que usa el estado
processes Recuento de procesos, con etiqueta para el estado
Recuento de procesos bifurcados
E/S de lectura de disco por proceso, con etiquetas para el nombre del proceso y otros
Por proceso E/S de escritura del disco, con etiquetas para el nombre del proceso y otros
Uso de RSS por proceso, con etiquetas para el nombre del proceso y otros
Uso de VM por proceso, con etiquetas para el proceso nombre y otros

El receptor iis (solo en Windows) transfiere las métricas del grupo iis. Para obtener más información, consulta la página Métricas del agente.

Grupo Métrica
iis
Solo en Windows
Conexiones abiertas actualmente a IIS
Bytes de red transferidos por IIS
Conexiones abiertas a IIS
Solicitudes realizadas a IIS

El receptor mssql (solo en Windows) transfiere métricas del grupo mssql. Para obtener más información, consulta la página Métricas del agente de operaciones.

Grupo Métrica
mssql
Solo en Windows
Conexiones abiertas actualmente a SQL Server
Total de transacciones de SQL Server por segundo
Transacciones de escritura de SQL Server por segundo

Procesadores de métricas

El elemento processor contiene un conjunto de definiciones de procesador. Un procesador describe las métricas del tipo de receptor para excluir. El único tipo admitido es exclude_metrics, que toma una opción metrics_pattern. El valor es una lista de globs que coinciden con los tipos de métricas que deseas excluir del grupo que recopila un receptor. por ejemplo, agent.googleapis.com/cpu/* o agent.googleapis.com/processes/*. Para encontrar los nombres completamente calificados de las métricas individuales, consulta la tabla del grupo en la página Métricas del agente de operaciones.

Procesador de métricas de muestra

En el siguiente ejemplo, se muestra el procesador exclude_metrics proporcionado en las configuraciones integradas. Este procesador proporciona un valor metrics_pattern vacío, por lo que no excluye ninguna métrica.

processors:
  metrics_filter:
    type: exclude_metrics
    metrics_pattern: []

Para inhabilitar la recopilación de todas las métricas de procesos del agente de operaciones, agrega lo siguiente al archivo config.yaml:

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

Esto excluye las métricas de procesos de la recopilación en el procesador metrics_filter que se aplica a la canalización predeterminada en el servicio metrics.

Servicio de métricas

El servicio de métricas vincula los receptores y los procesadores de métricas en canalizaciones.

La sección service tiene un solo elemento, pipelines, que puede contener varios ID de canalización y definiciones. Cada definición de pipeline consta de los siguientes elementos:

  • receivers: Es obligatorio para canalizaciones nuevas. Una lista de ID de receptores, como se describe en Receptores de métricas No importa el orden de los ID de receptores en la lista. La canalización recopila datos de todos los receptores enumerados.

  • processors: Opcional Una lista de ID de procesadores, como se describe en Procesadores de métricas. El orden de los ID de procesador de la lista es importante. Cada punto de métrica se ejecuta a través de los procesadores en el orden indicado.

Una configuración de service tiene la siguiente estructura:

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

Configuración de ejemplo de métricas service

Para desactivar la transferencia integrada de las métricas del host, redefine la canalización predeterminada con una lista receivers vacía y sin procesadores. Toda la configuración de las métricas se ve de la siguiente manera:

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

En el siguiente ejemplo, se muestra la configuración integrada service para Windows:

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