Configura el agente de operaciones

En este documento, se proporcionan detalles sobre las opciones de configuración personalizada y predeterminada del agente de operaciones. Lee este documento si se aplica 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.

El agente de operaciones también proporciona instrucciones de configuración para recopilar métricas y registros de aplicaciones de terceros admitidas. Consulta Supervisa aplicaciones de terceros para obtener la lista de las aplicaciones compatibles.

Modelo de configuración

El agente de operaciones usa una configuración predeterminada integrada, no puedes modificarla directamente. En su lugar, debes crear un archivo de anulaciones que se combine con la configuración integrada cuando el agente se reinicie.

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

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

La configuración integrada consta de estos elementos, y debes usar los mismos elementos si deseas anularla.

Configuración integrada

La configuración integrada del agente de operaciones define la colección predeterminada para 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 receptores.

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 métricas de IIS y las métricas de SQL Server.

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

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]

Estas opciones de configuración se analizan con 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, agrega elementos de configuración nuevos al archivo de configuración del usuario. Configura 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.

Para anular un receptor, procesador o canalización integrados, vuelve a definirlo en tu archivo config.yaml mediante la declaración 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. Para cambiar el intervalo de recopilación de las métricas de host a 30 segundos, incluye un receptor de métricas llamado hostmetrics en el archivo config.yaml que establezca el valor collection_interval en 30 segundos, como se muestra en el siguiente ejemplo:

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

Para ver otros ejemplos de cambios en 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 registro o métricas. Estos cambios se describen en los ejemplos de registros de opciones de configuración del service y Opciones de configuración de métricas de 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 recopilarán de los archivos de registro. Estos datos se asignan a un modelo <timestamp, record>.
  • processors: En este elemento opcional, se describe cómo el agente puede modificar la información recopilada.
  • service: En este elemento, se vinculan los receptores y los 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. Un receptor describe cómo recuperar los registros; por ejemplo, mediante la visualización del final de los archivos, un puerto TCP o desde el registro de eventos de Windows.

Estructura de los receptores de registros

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

  • files: Recopila registros mediante la visualización del final de los archivos en el disco.
  • syslog: Recopila registros del sistema a través de TCP o UDP.
  • tcp (disponible con las versiones 2.3.0 y posteriores del agente de operaciones): recopila registros de formatos JSON mediante la escucha en un puerto TCP.
  • windows_event_log (solo Windows): Recopila los registros de eventos de Windows.
  • systemd_journald (disponible con las versiones 2.4.0 y posteriores del agente de operaciones) en Linux: recopila registros del servicio de systemd-journald.

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, de la siguiente manera:

  • 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.

      Si deseas obtener una lista de los 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.

    • wildcard_refresh_interval: Opcional El intervalo en el que se actualizan las rutas de acceso de archivos comodín en include_paths. Se proporciona como una duración, por ejemplo, 30s, 2m. Esta propiedad puede ser útil en el caso de una capacidad de procesamiento de registro alta en la que los archivos de registro se rotan más rápido que el intervalo predeterminado. Si no se especifica, el intervalo predeterminado es de 60 segundos.

  • Receptores syslog:

    • transport_protocol: Opcional Valores admitidos: tcp, udp. El valor 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 tcp:

    • format: Obligatorio. Formato de registro. Valor admitido: json.

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

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

  • Receptores windows_event_log (solo para Windows):

    • channels: Obligatorio. Una lista de canales de registros de eventos de Windows desde los cuales se leen los registros.

Ejemplos de receptores de registros

Receptor files de ejemplo:

receivers:
  RECEIVER_ID:
    type: files

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

Receptor syslog de ejemplo:

receivers:
  RECEIVER_ID:
    type: syslog

    transport_protocol: tcp
    listen_host: 0.0.0.0
    listen_port: 5140

Receptor tcp de ejemplo:

receivers:
  RECEIVER_ID:
    type: tcp

    format: json
    listen_host: 127.0.0.1
    listen_port: 5170

Receptor windows_event_log de ejemplo (solo Windows):

receivers:
  RECEIVER_ID:
    type: windows_event_log

    channels: [System,Application,Security]

Receptor systemd_journald de ejemplo:

receivers:
  RECEIVER_ID:
    type: systemd_journald

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 registro

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 que se muestran a continuación:

  • 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: 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 deseas obtener un conjunto de expresiones regulares para extraer información de los archivos de registro, consulta Archivos de registro comunes.

Ejemplos de procesadores de registro

Procesador parse_json de ejemplo:

processors:
  PROCESSOR_ID:
    type: parse_json

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

Procesador parse_regex de ejemplo:

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/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 personaliza la verbosidad de los registros y agentes del receptor del agente de operaciones y los vincula en canalizaciones. En la sección service, existen dos elementos: log_level y pipelines.

Nivel de verbosidad del registro

log_level, disponible con las versiones 2.6.0 y posteriores del agente de operaciones, personaliza la verbosidad para los propios registros del submódulo de registro del agente de operaciones. El predeterminado es info. Las opciones disponibles son las siguientes: error, warn, info, debug y trace.

Canalizaciones de registro

pipelines puede contener varios ID y canalizaciones de canalización. 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 procesador, como se describe en Procesadores de registros. El orden de los ID de procesador en la lista es importante. Cada registro se ejecuta a través de los procesadores en el orden en el que aparecen en la lista.

Ejemplos de opciones de configuración de registros service

Una configuración de service tiene la siguiente estructura:

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

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:

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

En la siguiente configuración de service, se personaliza la verbosidad del registro para que el submódulo de registro sea debug en su lugar:

logging:
  service:
    log_level: debug

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 Para obtener información sobre los archivos de registro de Apache, consulta Supervisa aplicaciones de terceros: Apache Web Server.
cassandra Para obtener información sobre los archivos de registro de Cassandra, consulta Supervisa aplicaciones de terceros: 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 Para obtener información sobre los archivos de registro de MySQL, consulta Supervisa aplicaciones de terceros: MySQL.
nginx Para obtener información sobre los archivos de registro de nginx, consulta Supervisa aplicaciones de terceros: 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 Para obtener información sobre los archivos de registro de Redis, consulta Supervisa aplicaciones de terceros: 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

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

Aplicación Expresión regular
mongodb ^(?<time>[^ ]*)\s+(?<severity>\w)\s+(?<component>[^ ]+)\s+\[(?<context>[^\]]+)]\s+(?<message>.*?) *(?<ms>(\d+))?(:?ms)?$

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 la fuente de las métricas. Por ejemplo, métricas de 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, además, 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 está en el formato de una duración, por ejemplo, 30s o 2m. El valor predeterminado es 60s.

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

Puedes crear solo un receptor para cada tipo. Por ejemplo, no puedes definir dos receptores de 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 de las métricas, puedes configurar alertas más sensibles. Si deseas obtener más información para evaluar las alertas, consulta Comportamiento de alertas.

Por ejemplo, el siguiente receptor cambia el intervalo de recopilación para las métricas de 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.

El receptor 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 a intervalos de 1 minuto
Carga de CPU a intervalos de 5 minutos
Carga de CPU a intervalos de 15 minutos
Uso de CPU, con etiquetas para el número de y el estado de CPU
Porcentaje de uso de CPU, con etiquetas para el número y estado de CPU
disk Bytes del disco leídos, 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
Tiempo de E/S ponderado del disco, con etiqueta para el dispositivo
Operaciones del disco pendientes, con etiqueta para el dispositivo
Operaciones combinadas del 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
Cantidad total de paquetes enviados a través de la red
Cantidad total de bytes enviados en 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 el 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 para Windows
Porcentaje actual del archivo de paginación que usa el estado
processes Recuento de procesos, con etiqueta para el estado
Recuento bifurcado de procesos
E/S de lectura por disco de proceso, con etiquetas para el nombre del proceso y otros
Por proceso E/S de escritura del disco, con etiquetas para el nombre de proceso y otros
Uso de RSS por proceso, con etiquetas para el nombre de proceso y otros
Uso de VM por proceso, con etiquetas para el proceso nombre y otros

El receptor iis (solo 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 para Windows
Conexiones abiertas actualmente a IIS
Bytes de red transferidos por IIS
Conexiones abiertas a IIS
Solicitudes realizadas en IIS

El receptor mssql (solo 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 para Windows
Conexiones abiertas actualmente a SQL
Transacciones totales de SQL Server por segundo
Transacciones de escritura de SQL Server por segundo

Procesadores de métrica

El elemento processor contiene un conjunto de definiciones de procesador. Un procesador describe las métricas del tipo de receptor que se 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 recopilado por 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 ejemplo

En el siguiente ejemplo, se muestra el procesador exclude_metrics que se proporcionan en las opciones de configuración 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 personaliza la verbosidad de los registros y receptores de las métricas del agente de operaciones de agente y vincula los receptores y procesadores de métricas en canalizaciones. En la sección service, existen dos elementos: log_level y pipelines.

Nivel de verbosidad de las métricas

log_level, disponible con las versiones 2.6.0 y posteriores del agente de operaciones, personaliza la verbosidad para los propios registros del submódulo de métricas del agente de operaciones. El predeterminado es info. Las opciones disponibles son las siguientes: error, warn, info y debug.

Canalizaciones de métricas

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 procesador, como se describe en Procesadores de métricas. El orden de los ID de procesador en la lista es importante. Cada punto de métrica se ejecuta a través de los procesadores en el orden en el que aparecen en la lista.

Ejemplos de opciones de configuración de métricas service

Una configuración de service tiene la siguiente estructura:

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

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

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

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

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

En la siguiente configuración de service, se personaliza la verbosidad del registro para que el submódulo de métricas sea debug en su lugar:

metrics:
  service:
    log_level: debug