Configurar 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:

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 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 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. A partir de la versión 2.31.0 del agente de operaciones, también puedes configurar la función de rotación de registros del agente. Para obtener más información, consulta Configura la rotación de registros en el agente de operaciones.

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.

Puedes usar este archivo para evitar que el agente recopile registros propios y los envíe a Cloud Logging. Para obtener más información, consulta Recopilación de registros propios.

También debes configurar la función de rotación de registros del agente mediante este archivo. Para obtener más información, consulta Configura la rotación de registros en el agente de operaciones.

No puedes configurar el Agente de operaciones para exportar registros o métricas a servicios que no sean Cloud Logging y Cloud Monitoring.

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.

El Agente de operaciones envía registros a Cloud Logging. No puedes configurarlo para exportar registros a otros servicios. Sin embargo, puedes configurar Cloud Logging para exportar registros. Para obtener más información, consulta Registros de ruta a destinos compatibles.

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.
  • fluent_forward (versiones 2.12.0 y posteriores del Agente de operaciones): recopila los registros enviados a través del protocolo Fluent Forward a través de TCP.
  • tcp (versiones 2.3.0 y posteriores del Agente de operaciones): recopila registros en formato JSON mediante la escucha en un puerto TCP.
  • Solo en Linux:
    • syslog: Recopila mensajes de Syslog a través de TCP o UDP.
    • systemd_journald (versiones 2.4.0 y posteriores del Agente de operaciones): Recopila registros del diario systemd desde el servicio systemd-journald.
  • Solo en Windows:
    • windows_event_log: Recopila los registros de eventos de Windows con la API de Windows Event Log.
  • Receptores de registros de aplicaciones de terceros

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 de acceso, por ejemplo, /var/log/*.log (Linux) o C:\logs\*.log (Windows).

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

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

    • record_log_file_path: Opcional Si se configura como true, la ruta al archivo específico desde el que se obtuvo el registro aparece en la entrada de registro de salida como el valor de la etiqueta agent.googleapis.com/log_file_path. Cuando se usa un comodín, solo se registra la ruta de acceso del archivo del que se obtuvo el registro.

    • 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 fluent_forward:

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

  • Receptores syslog (solo para Linux):

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

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

    • receiver_version: Opcional Controla qué API de Windows Event Log se usará. Los valores admitidos son 1 y 2. El valor predeterminado es 1.

    • render_as_xml: Opcional Si se configura como true, todos los campos del registro de eventos, excepto jsonPayload.Message y jsonPayload.StringInserts, se procesan como un documento XML en un campo de string llamado jsonPayload.raw_xml. El valor predeterminado es false. No se puede establecer como true cuando receiver_version es 1.

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]
    record_log_file_path: true

Receptor fluent_forward de ejemplo:

receivers:
  RECEIVER_ID:
    type: fluent_forward

    listen_host: 127.0.0.1
    listen_port: 24224

Receptor syslog de ejemplo (solo Linux):

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 windows_event_log de ejemplo que anula el receptor integrado para usar la versión 2:

receivers:
  windows_event_log:
    type: windows_event_log

    channels: [System,Application,Security]
    receiver_version: 2

Receptor systemd_journald de ejemplo:

receivers:
  RECEIVER_ID:
    type: systemd_journald

Campos especiales en cargas útiles estructuradas

Para los procesadores y receptores que pueden transferir datos estructurados (los receptores fluent_forward y tcp y el procesador parse_json), puedes configurar campos especiales en la entrada que se asignarán a campos específicos en el objeto LogEntry que el agente escribe en la API de Logging.

Cuando el agente de operaciones recibe datos de registro estructurados externos, coloca campos de nivel superior en el campo jsonPayload de la LogEntry, a menos que el nombre del campo aparezca en la siguiente tabla:

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) httpRequest
logging.googleapis.com/severity (cadena) severity
logging.googleapis.com/labels (struct de cadena:cadena) labels
logging.googleapis.com/operation (struct) operation
logging.googleapis.com/sourceLocation (struct) sourceLocation
logging.googleapis.com/trace (cadena) trace
logging.googleapis.com/spanId (cadena) spanId

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

Archivos de registro comunes de Linux

En la siguiente tabla, se enumeran los archivos de registro comunes para las aplicaciones de Linux 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 Para obtener información sobre los archivos de registro de Memcached, consulta Supervisa aplicaciones de terceros: Memcached.
mongodb Para obtener información sobre los archivos de registro de MongoDB, consulta Supervisa aplicaciones de terceros: MongoDB.
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 Para obtener información sobre los archivos de registro de PostgreSQL, consulta Supervisa aplicaciones de terceros: PostgreSQL.
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 Para obtener información sobre los archivos de registro de RabbitMQ, consulta Supervisa aplicaciones de terceros: RabbitMQ.
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 Para obtener información sobre los archivos de registro de Apache Solr, consulta Supervisa aplicaciones de terceros: Apache Solr.
sugarcrm /var/www/*/sugarcrm.log
syslog /var/log/syslog
/var/log/messages
Tomcat Para obtener información sobre los archivos de registro de Apache Tomcat, consulta Supervisa aplicaciones de terceros: Apache Tomcat.
zookeeper Para obtener información sobre los archivos de registro de Apache ZooKeeper, consulta Supervisa aplicaciones de terceros: Apache ZooKeeper.

Etiquetas transferidas predeterminadas

Los registros pueden contener las siguientes etiquetas de forma predeterminada en el LogEntry:

Campo Valor de muestra Descripción
labels."compute.googleapis.com/resource_name" test_vm El nombre de la máquina virtual desde la que se origina este registro. Escrito para todos los registros.
labels."logging.googleapis.com/instrumentation_source" agent.googleapis.com/apache_access El valor del receptor type desde el que se origina el registro, con el prefijo agent.googleapis.com/. Escrito solo por receptores de integraciones de terceros.

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.

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

  • parse_json: Analiza los registros estructurados con formato JSON.
  • parse_multiline: Analiza los registros de varias líneas. (Solo en Linux)
  • parse_regex: Analiza los registros con formato de texto a través de patrones de regex para convertirlos en registros estructurados con formato JSON.
  • exclude_logs: Excluye los registros que coinciden con las reglas especificadas (a partir de 2.9.0).
  • modify_fields: Establece o transforma campos en entradas de registro (a partir de 2.14.0).

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.

Procesador parse_json

Estructura de la configuración

processors:
  PROCESSOR_ID:
    type: parse_json

    time_key:    <field name within jsonPayload>
    time_format: <strptime format string>

El procesador parse_json analiza el JSON de entrada en el campo jsonPayload de LogEntry. Otras partes de LogEntry se pueden analizar si configuras ciertos campos especiales de nivel superior.

  • 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).
Configuración de ejemplo
processors:
  PROCESSOR_ID:
    type: parse_json

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

Procesador parse_multiline

Estructura de la configuración

processors:
  PROCESSOR_ID:
    type: parse_multiline

    match_any:
    - type: <type of the exceptions>
      language: <language name>

  • match_any: Obligatorio. Una lista de una o más reglas.

    • type: Obligatorio. Solo se admite un único valor:

      • language_exceptions: Permite que el procesador concatene excepciones en una LogEntry, según el valor de la opción language.

    • language: Obligatorio. Solo se admite un único valor:

      • java: Concatena excepciones de Java comunes en una LogEntry.
      • python: Concatena excepciones de Python comunes en una LogEntry.
      • go: Concatena excepciones de Go comunes en un LogEntry.
Configuración de ejemplo
logging:
  receivers:
    custom_file1:
      type: files
      include_paths:
      - /tmp/test-multiline28
  processors:
    parse_java_multiline:
      type: parse_multiline
      match_any:
      - type: language_exceptions
        language: java
    extract_structure:
      type: parse_regex
      field: message
      regex: "^(?<time>[\d-]*T[\d:.Z]*) (?<severity>[^ ]*) (?<file>[^ :]*):(?<line>[\d]*) - (?<message>(.|\\n)*)$"
      time_key: time
      time_format: "%Y-%m-%dT%H:%M:%S.%L"
    move_severity:
      type: modify_fields
      fields:
        severity:
          move_from: jsonPayload.severity
  service:
    pipelines:
      pipeline1:
        receivers: [custom_file1]
        processors: [parse_java_multiline, extract_structure, move_severity]

Si usas la configuración anterior y tienes un archivo de registro con el siguiente contenido:

2022-10-17T22:00:00.187512963Z ERROR HelloWorld:16 - javax.servlet.ServletException: Something bad happened
    at com.example.myproject.OpenSessionInViewFilter.doFilter(OpenSessionInViewFilter.java:60)
    at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1157)
    at com.example.myproject.ExceptionHandlerFilter.doFilter(ExceptionHandlerFilter.java:28)
    at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1157)
    at com.example.myproject.OutputBufferFilter.doFilter(OutputBufferFilter.java:33)
Caused by: com.example.myproject.MyProjectServletException
    at com.example.myproject.MyServlet.doPost(MyServlet.java:169)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:727)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
    at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:511)
    at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1166)
    at com.example.myproject.OpenSessionInViewFilter.doFilter(OpenSessionInViewFilter.java:30)
    ... 27 common frames omitted

el agente transfiere los registros a Cloud Logging en el siguiente formato:

{
  "insertId": "...",
  "jsonPayload": {
    "line": "16",
    "message": "javax.servlet.ServletException: Something bad happened\n    at com.example.myproject.OpenSessionInViewFilter.doFilter(OpenSessionInViewFilter.java:60)\n    at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1157)\n    at com.example.myproject.ExceptionHandlerFilter.doFilter(ExceptionHandlerFilter.java:28)\n    at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1157)\n    at com.example.myproject.OutputBufferFilter.doFilter(OutputBufferFilter.java:33)\nCaused by: com.example.myproject.MyProjectServletException\n    at com.example.myproject.MyServlet.doPost(MyServlet.java:169)\n    at javax.servlet.http.HttpServlet.service(HttpServlet.java:727)\n    at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)\n    at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:511)\n    at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1166)\n    at com.example.myproject.OpenSessionInViewFilter.doFilter(OpenSessionInViewFilter.java:30)\n    ... 27 common frames omitted\n",
    "file": "HelloWorld"
  },
  "resource": {
    "type": "gce_instance",
    "labels": {
      "instance_id": "...",
      "project_id": "...",
      "zone": "..."
    }
  },
  "timestamp": "2022-10-17T22:00:00.187512963Z",
  "severity": "ERROR",
  "labels": {
    "compute.googleapis.com/resource_name": "..."
  },
  "logName": "projects/.../logs/custom_file",
  "receiveTimestamp": "2022-10-18T03:12:38.430364391Z"
}

Procesador parse_regex

Estructura de la configuración

processors:
  PROCESSOR_ID:
    type: parse_regex

    regex: <regular expression>

    time_key:    <field name within jsonPayload>
    time_format: <format string>

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

  • 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>.*)$".

    El texto que coincida con los grupos de captura con nombre se colocará en los campos del campo jsonPayload de LogEntry. Para agregar estructura adicional a tus registros, usa el procesador modify_fields.

    Si deseas obtener un conjunto de expresiones regulares para extraer información de los archivos de registro de la aplicación de Linux comunes, consulta Archivos de registro comunes de Linux.

Configuración de ejemplo
processors:
  PROCESSOR_ID:
    type: parse_regex

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

Procesador exclude_logs

Estructura de la configuración:

type: exclude_logs
match_any:
  - <filter>
  - <filter>

La configuración de nivel superior para este procesador contiene un único campo, match_any, que contiene una lista de reglas de filtro.

  • match_any: Obligatorio. Una lista de una o más reglas. Si una entrada de registro coincide con alguna regla, el agente de operaciones no la transfiere.

    Los registros que transfiere el agente de operaciones siguen la estructura LogEntry. Los nombres de campo distinguen mayúsculas de minúsculas. Solo puedes especificar reglas basadas en los siguientes campos y sus subcampos:

    • httpRequest
    • jsonPayload
    • labels
    • operation
    • severity
    • sourceLocation
    • trace
    • spanId

    La siguiente regla de ejemplo

    severity =~ "(DEBUG|INFO)"

    usa una expresión regular para excluir todos los registros de nivel DEBUG y INFO.

    Las reglas siguen la sintaxis del lenguaje de consulta de Cloud Logging, pero solo admiten un subconjunto de las funciones que admite el lenguaje de consulta de Logging:

    • Operadores de comparación: =, !=, :, =~ y !~. Solo se admiten comparaciones de strings.
    • Operador de navegación: .. Por ejemplo, jsonPayload.message.
    • Operadores booleanos: AND, OR, NOT.
    • Expresiones de agrupación con ( ).

Configuración de ejemplo

processors:
  PROCESSOR_ID:
    type: exclude_logs
    match_any:
    - '(jsonPayload.message =~ "log spam 1" OR jsonPayload.message =~ "log spam 2") AND severity = "ERROR"'
    - 'jsonPayload.application = "foo" AND severity = "INFO"'

Procesador modify_fields

El procesador modify_fields permite la personalización de la estructura y el contenido de las entradas de registro.

Estructura de la configuración

type: modify_fields
fields:
  <destination field>:
    # Source
    move_from: <source field>
    copy_from: <source field>
    static_value: <string>
    
    # Mutation
    default_value: <string>
    map_values:
      <old value>: <new value>
    type: {integer|float}
    omit_if: <filter>

La configuración de nivel superior para este procesador contiene un campo único, fields, que contiene un mapa de nombres de campo de salida y las traducciones correspondientes. Para cada campo de salida, se aplican una fuente opcional y cero o más operaciones de mutación.

Todos los nombres de campo usan la sintaxis separada por puntos del lenguaje de consulta de Cloud Logging. Los filtros usan el lenguaje de consulta de Cloud Logging.

Todas las transformaciones se aplican en paralelo, lo que significa que las fuentes y los filtros operan en la entrada de registro de entrada original y, por lo tanto, no pueden hacer referencia al valor nuevo de ningún otro campo que el mismo procesador modifique.

Opciones de origen: Como máximo, se permite un origen especificado.

  • No se especificó ninguna fuente

    Si no se especifica un valor de origen, el valor existente en el campo de destino se modificará.

  • move_from: <source field>

    El valor de <source field> se usará como el origen del campo de destino. Además, <source field> se quitará de la entrada de registro. Si move_from y copy_from hacen referencia a un campo de origen, se quitará el campo de origen.

  • copy_from: <source field>

    El valor de <source field> se usará como el origen del campo de destino. <source field> no se quitará de la entrada de registro, a menos que también haga referencia a él una operación move_from o que se modifique.

  • static_value: <string>

    Se usará la string estática <string> como origen para el campo de destino.

Opciones de mutación: Se pueden aplicar cero o más operadores de mutación a un solo campo. Si se proporcionan varios operadores, siempre se aplicarán en el siguiente orden.

  1. default_value: <string>

    Si el campo de origen no existía, el valor de resultado se establecerá en <string>. Si el campo de origen ya existe (incluso si contiene una string vacía), el valor original no se modifica.

  2. map_values: <map>

    Si el valor de entrada coincide con una de las claves en <map>, el valor de salida se reemplazará por el valor correspondiente del mapa.

  3. map_values_exclusive: {true|false}

    En caso de que el valor de <source field> no coincida con ninguna clave especificada en los pares map_values, el campo de destino se inhabilitará forzadamente simap_values_exclusive es verdadero o no se toca si map_values_exclusive es falso.

  4. type: {integer|float}

    El valor de entrada se convertirá en un número entero o un número de punto flotante. Si la string no se puede convertir en un número, se anulará el valor de salida. Si la string contiene un número de punto flotante, pero el tipo se especifica como integer, el número se truncará como un número entero.

    Ten en cuenta que la API de Cloud Logging usa JSON y, por lo tanto, no es compatible con un número entero de 64 bits completo. Si se necesita un número entero de 64 bits (o más grande), debe almacenarse como una string en la entrada de registro.

  5. omit_if: <filter>

    Si el filtro coincide con el registro de entrada, se anulará el campo de salida. Esto se puede usar para quitar valores de marcadores de posición, como los siguientes:

    httpRequest.referer:
  move_from: jsonPayload.referer
  omit_if: httpRequest.referer = "-"

Configuraciones de muestra

El procesador parse_json transformaría un archivo JSON que contiene lo siguiente:

{
  "http_status": "400",
  "path": "/index.html",
  "referer": "-"
}

en una estructura LogEntry similar a lo siguiente:

{
  "jsonPayload": {
    "http_status": "400",
    "path": "/index.html",
    "referer": "-"
  }
}

Esto podría transformarse con modify_fields en esta LogEntry:

{
  "httpRequest": {
    "status": 400,
    "requestUrl": "/index.html",
  }
}

con esta configuración del agente de operaciones:

logging:
  receivers:
    in:
      type: files
      include_paths:
      - /var/log/http.json
  processors:
    parse_json:
      type: parse_json
    set_http_request:
      type: modify_fields
      fields:
        httpRequest.status:
          move_from: jsonPayload.http_status
          type: integer
        httpRequest.requestUrl:
          move_from: jsonPayload.path
        httpRequest.referer:
          move_from: jsonPayload.referer
          omit_if: jsonPayload.referer = "-"
  pipelines:
    pipeline:
      receivers: [in]
      processors: [parse_json, set_http_request]

Esta configuración lee los registros con formato JSON de /var/log/http.json y propaga parte de la estructura httpRequest de los campos en los registros.

Servicio de registros

El servicio de registro personaliza la verbosidad de los registros del agente de operaciones y vincula receptores y encargados del tratamiento de datos de registro en canalizaciones. En la sección service, se mencionan los siguientes elementos:

  • log_level
  • pipelines

Nivel de verbosidad del registro

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

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

logging:
  service:
    log_level: debug

Canalizaciones de registro

El campo pipelines puede contener varios ID de canalización y definiciones. Cada valor 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 IDs de procesadores 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 evitar que el agente recopile y envíe las entradas /var/log/message o /var/log/syslog, vuelve a definir la canalización predeterminada con una lista receivers vacía y sin procesadores. Esta configuración no detiene el subcomponente de registro del agente, ya que el agente debe poder recopilar registros para el subcomponente de supervisión. 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

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.

El Agente de operaciones envía métricas a Cloud Monitoring. No puedes configurarla para exportar métricas a otros servicios.

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 integrados 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 receptores.

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. Para obtener información sobre cómo se evalúan las alertas, consulta Comportamiento de las políticas de alertas basadas en métricas.

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

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
gpu
Solo en Linux; consulta Acerca de las métricas gpu para obtener más información importante. 		Cantidad actual de bytes de memoria de GPU usados, por estado
Cantidad máxima de memoria de GPU, en bytes, que asignó el proceso
Porcentaje de tiempo en la vida útil del proceso que se ejecutaron uno o más kernels en la GPU
Porcentaje de tiempo, desde la última muestra, en que la GPU estuvo activa
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 para Windows)

El receptor iis (solo Windows) transfiere 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 para Windows)

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 del agente de operaciones que deseas excluir del grupo recopilado por un receptor. Por ejemplo:

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 del módulo de métricas del agente de operaciones y vincula los receptores y los 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 sí 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

Colección de registros propios

De forma predeterminada, los registros propios de Fluent Bit del agente de operaciones se envían a Cloud Logging. Estos registros pueden incluir mucha información y el volumen adicional puede aumentar tus costos para usar Cloud Logging.

Puedes inhabilitar la recopilación de estos registros propios, a partir de la versión 2.44.0 del agente de operaciones, con la opción default_self_log_file_collection.

Para inhabilitar la recopilación automática, agrega una sección global al archivo de configuración especificado por el usuario y establece la opción default_self_log_file_collection en el valor false:

logging:  ...
metrics:  ...
global:
  default_self_log_file_collection: false

Configuración de la rotación de registros

A partir de la versión 2.31.0 del agente de operaciones, también puedes configurar la función de rotación de registros del agente mediante los archivos de configuración. Para obtener más información, consulta Configura la rotación de registros en el agente de operaciones.