Configurar el agente de operaciones

En este documento se proporcionan detalles sobre las configuraciones predeterminadas y personalizadas del agente de Ops. Lee este documento si se da 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, crea un archivo de anulaciones que se combina con la configuración integrada cuando se reinicia el agente.

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

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

La configuración integrada se compone de estos elementos, y se usan los mismos elementos para anularla.

Configuración integrada

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

Linux

De forma predeterminada, el agente de operaciones recoge syslogregistros basados en archivos y métricas de host.

Para obtener más información sobre las métricas recogidas, consulta el artículo Métricas ingeridas 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 recoge registros de eventos de Windows de los canales System, Application y Security, así como métricas de host, métricas de IIS y métricas de SQL Server.

Para obtener más información sobre las métricas recogidas, consulta el artículo Métricas ingeridas 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 configuraciones se describen con más detalle en los artículos Configuración de registro y Configuración de métricas.

Configuración especificada por el usuario

Para anular la configuración integrada, añade nuevos elementos de configuración al archivo de configuración del usuario. Coloca la configuración del agente de operaciones en los siguientes archivos:

  • En Linux: /etc/google-cloud-ops-agent/config.yaml
  • En 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 se reinicia el agente.

Para anular un receptor, un procesador o una canalización integrados, vuelve a definirlos en el archivo config.yaml declarándolos con el mismo identificador. A partir de la versión 2.31.0 del agente de Ops, también puedes configurar la función de rotación de registros del agente. Para obtener más información, consulta Configurar la rotación de registros en el agente de Ops.

Por ejemplo, la configuración integrada de las métricas incluye un hostmetrics receptor que especifica un intervalo de recogida de 60 segundos. Para cambiar el intervalo de recogida de las métricas de host a 30 segundos, incluya un receptor de métricas llamado hostmetrics en su archivo config.yaml que asigne el valor collection_interval a 30 segundos, como se muestra en el siguiente ejemplo:

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

Para ver otros ejemplos de cómo cambiar las configuraciones integradas, consulta Configuración de registro y Configuración de métricas. También puedes desactivar la recogida de datos de registro o de métricas. Estos cambios se describen en los ejemplos de configuraciones de registro service y configuraciones de métricas service.

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

También puedes configurar la función de rotación de registros del agente mediante este archivo. Para obtener más información, consulta el artículo sobre cómo configurar la rotación de registros en el agente de operaciones.

No puedes configurar el agente de Ops para que exporte registros ni métricas a servicios que no sean Cloud Logging y Cloud Monitoring.

Configuraciones de registro

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

  • receivers: este elemento describe los datos que se deben recoger de los archivos de registro. Estos datos se asignan a un modelo <timestamp, record>.
  • processors: este elemento opcional describe cómo puede modificar el agente la información recogida.
  • service: este elemento vincula receptores y procesadores para crear flujos de datos, llamados pipelines. 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 Ops 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 el artículo Enrutar registros a destinos admitidos.

Receptores de registros

El elemento receivers contiene un conjunto de receptores, cada uno identificado por un RECEIVER_ID. Un receptor describe cómo obtener los registros; por ejemplo, mediante el seguimiento de archivos, mediante 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, e incluir un elemento type. Los tipos válidos son:

  • files: recoge los registros siguiendo los archivos del disco.
  • fluent_forward (versiones 2.12.0 y posteriores del Agente de operaciones): recoge los registros enviados a través del protocolo Fluent Forward por TCP.
  • tcp (versiones 2.3.0 y posteriores del agente de Ops): recoge registros en formato JSON escuchando un puerto TCP.
  • Solo Linux:
    • syslog: recoge mensajes Syslog a través de TCP o UDP.
    • systemd_journald (Agente de operaciones, versiones 2.4.0 y posteriores): recoge registros del journal de systemd del servicio systemd-journald.
  • Solo en Windows:
    • windows_event_log: recoge los registros de eventos de Windows mediante la API de registros de eventos de Windows.
  • Receptores de registros de aplicaciones de terceros

La estructura receivers tiene el siguiente aspecto:

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

En función del valor del elemento type, puede haber otras opciones de configuración, como se indica a continuación:

  • files receptores:

    • include_paths: obligatorio. Lista de rutas del sistema de archivos que se van a leer siguiendo cada archivo. Se puede usar un carácter comodín (*) en las rutas; por ejemplo, /var/log/*.log (Linux) o C:\logs\*.log (Windows).

      Para ver una lista de los archivos de registro de aplicaciones de Linux habituales, consulta Archivos de registro de Linux habituales.

    • exclude_paths: opcional. Lista de patrones de ruta del sistema de archivos que se excluirán del conjunto que coincida con include_paths.

    • record_log_file_path: opcional. Si se asigna el valor true, la ruta al archivo específico del que se ha obtenido el registro de 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 del archivo del que se ha obtenido el registro.

    • wildcard_refresh_interval: opcional. Intervalo en el que se actualizan las rutas de archivos con comodines en include_paths. Se indica como una duración, por ejemplo, 30s o 2m. Esta propiedad puede ser útil cuando el rendimiento de registro es alto y 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.

  • fluent_forward receptores:

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

    • listen_port: opcional. Puerto en el que se va a escuchar. El valor predeterminado es 24224.

  • Receptores syslog (solo para Linux):

    • transport_protocol: valores admitidos: tcp y udp.

    • listen_host: una dirección IP en la que escuchar.

    • listen_port: puerto en el que se va a escuchar.

  • tcp receptores:

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

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

    • listen_port: opcional. Puerto en el que se va a escuchar. El valor predeterminado es 5170.

  • windows_event_log (solo para Windows):

    • channels: obligatorio. Lista de canales del registro de eventos de Windows desde los que se leen los registros.

    • receiver_version: opcional. Controla qué API de registro de eventos de Windows se va a usar. Los valores posibles son 1 y 2. El valor predeterminado es 1.

    • render_as_xml: opcional. Si se asigna el valor true, todos los campos de registro de eventos, excepto jsonPayload.Message y jsonPayload.StringInserts, se representan como un documento XML en un campo de cadena llamado jsonPayload.raw_xml. El valor predeterminado es false. No se puede definir como true cuando receiver_version es 1.

Ejemplos de receptores de registro

Receptor de 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 de fluent_forward de ejemplo:

receivers:
  RECEIVER_ID:
    type: fluent_forward

    listen_host: 127.0.0.1
    listen_port: 24224

Receptor de muestra de syslog (solo Linux):

receivers:
  RECEIVER_ID:
    type: syslog

    transport_protocol: tcp
    listen_host: 0.0.0.0
    listen_port: 5140

Receptor de tcp de ejemplo:

receivers:
  RECEIVER_ID:
    type: tcp

    format: json
    listen_host: 127.0.0.1
    listen_port: 5170

Receptor de muestra windows_event_log (solo en Windows):

receivers:
  RECEIVER_ID:
    type: windows_event_log

    channels: [System,Application,Security]

Ejemplo de receptor windows_event_log 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 de systemd_journald de ejemplo:

receivers:
  RECEIVER_ID:
    type: systemd_journald

Campos especiales en cargas útiles estructuradas

En el caso de los procesadores y receptores que pueden ingerir datos estructurados (los receptores fluent_forward y tcp, y el procesador parse_json), puede definir campos especiales en la entrada que se asignarán a campos específicos del objeto LogEntry que el agente escribe en la API Logging.

Cuando Ops Agent recibe datos de registro estructurados externos, coloca los campos de nivel superior en el campo jsonPayload de 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 (estructura 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 campos de registro estructurado que queden seguirán formando parte de la jsonPayload estructura.

Archivos de registro comunes de Linux

En la siguiente tabla se enumeran los archivos de registro habituales de las aplicaciones de Linux que se usan con frecuencia:

Aplicación Archivos de registro comunes
apache Para obtener información sobre los archivos de registro de Apache, consulta el artículo Monitorizar aplicaciones de terceros: servidor web Apache.
cassandra Para obtener información sobre los archivos de registro de Cassandra, consulta Monitorizar 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
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 Para obtener información sobre los archivos de registro de Memcached, consulta el artículo Monitorizar aplicaciones de terceros: Memcached.
mongodb Para obtener información sobre los archivos de registro de MongoDB, consulta Monitorizar aplicaciones de terceros: MongoDB.
mysql Para obtener información sobre los archivos de registro de MySQL, consulta Monitorizar aplicaciones de terceros: MySQL.
Nginx Para obtener información sobre los archivos de registro de nginx, consulta el artículo Monitorizar aplicaciones de terceros: nginx.
postgres Para obtener información sobre los archivos de registro de PostgreSQL, consulta Monitorizar aplicaciones de terceros: PostgreSQL.
marioneta /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 el artículo Monitorizar aplicaciones de terceros: RabbitMQ.
redis Para obtener información sobre los archivos de registro de Redis, consulta Monitorizar aplicaciones de terceros: Redis.
redmine /var/log/redmine/*.log
sal /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 Monitorizar 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 el artículo Monitorizar aplicaciones de terceros: Apache Tomcat.
cuidador del zoo Para obtener información sobre los archivos de registro de Apache ZooKeeper, consulta Monitorizar aplicaciones de terceros: Apache ZooKeeper.

Etiquetas predeterminadas insertadas

De forma predeterminada, los registros pueden contener las siguientes etiquetas en LogEntry:

Campo Valor de ejemplo Descripción
labels."compute.googleapis.com/resource_name" test_vm Nombre de la máquina virtual de la que procede este registro. Escrito para todos los registros.
labels."logging.googleapis.com/instrumentation_source" agent.googleapis.com/apache_access El valor del receptor type del que procede este registro, con el prefijo agent.googleapis.com/. Solo lo escriben los receptores de integraciones de terceros.

Procesadores de registros

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

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

  • parse_json: analiza registros estructurados en formato JSON.
  • parse_multiline: analiza registros multilínea. Solo en Linux
  • parse_regex: analiza los registros con formato de texto mediante patrones de expresiones regulares para convertirlos en registros estructurados con formato JSON.
  • exclude_logs: excluye los registros que coincidan con las reglas especificadas (a partir de la versión 2.9.0).
  • modify_fields: Define o transforma campos en entradas de registro (a partir de la versión 2.14.0).

La estructura processors tiene el siguiente aspecto:

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

En función del valor del elemento type, hay otras opciones de configuración, como se indica a continuación.

Procesador parse_json

Estructura de 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 del LogEntry se pueden analizar configurando 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 definir el campo timestamp del LogEntry resultante y se elimina de la carga útil.

    Si se especifica la opción time_key, también debe 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 correctamente. Para obtener información sobre el formato, consulta la guía 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 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 varias reglas.

    • type: obligatorio. Solo se admite un valor:

      • language_exceptions: permite al procesador concatenar excepciones en un LogEntry, en función del valor de la opción language.

    • language: obligatorio. Solo se admite un valor:

      • java: concatena excepciones comunes de Java en un LogEntry.
      • python: concatena excepciones comunes de Python en una LogEntry.
      • go: concatena las excepciones comunes de Go en un solo 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]

En el procesador extract_structure, la instrucción field: message significa que la expresión regular se aplica al campo jsonPayload.message de la entrada de registro. De forma predeterminada, el receptor de archivos coloca cada línea del archivo de registro en una entrada de registro con un solo campo de carga útil llamado jsonPayload.message.

El procesador extract_structure coloca los campos extraídos en subcampos del campo LogEntry.jsonPayload. Otras instrucciones del archivo YAML provocan que se muevan dos de los campos extraídos, time y severity. La instrucción time_key: time extrae el campo LogEntry.jsonPayload.time, analiza la marca de tiempo y, a continuación, añade el campo LogEntry.timestamp. El procesador move_severity mueve el campo de gravedad del campo LogEntry.jsonPayload.severity al campo LogEntry.severity.

Ejemplo de archivo de registro:

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 ingiere cada línea del archivo de registro en Cloud Logging con 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 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 definir el campo timestamp del LogEntry resultante y se elimina de la carga útil.

    Si se especifica la opción time_key, también debe 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 correctamente. Para obtener información sobre el formato, consulta la guía strptime(3).

  • regex: obligatorio. Expresión regular para analizar el campo. La expresión debe incluir nombres de clave para las subexpresiones coincidentes; 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 añadir estructura adicional a tus registros, usa el procesador modify_fields.

    Para ver un conjunto de expresiones regulares que permiten extraer información de archivos de registro de aplicaciones de Linux habituales, consulta Archivos de registro de Linux habituales.

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 de este procesador contiene un solo campo, match_any, que contiene una lista de reglas de filtro.

  • match_any: obligatorio. Una lista de una o varias reglas. Si una entrada de registro coincide con alguna regla, el agente de Ops no la ingiere.

    Los registros que ingiere el agente de operaciones siguen la LogEntryestructura. En los nombres de los campos se distingue entre mayúsculas y minúsculas. Solo puede 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 cadenas.
    • Operador de navegación: .. Por ejemplo, jsonPayload.message.
    • Operadores booleanos: AND, OR y NOT.
    • Agrupar expresiones 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"'

modify_fields Encargado del tratamiento

El procesador modify_fields permite personalizar la estructura y el contenido de las entradas de registro.

Estructura de 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 de este procesador contiene un solo campo, fields, que contiene un mapa de nombres de campos de salida y las traducciones correspondientes. Para cada campo de salida, se aplica un origen 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 original y, por lo tanto, no pueden hacer referencia al nuevo valor de ningún otro campo que esté modificando el mismo procesador.

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

  • No se ha especificado ninguna fuente

    Si no se especifica ningún valor de origen, se modificará el valor del campo de destino.

  • move_from: <source field>

    El valor de <source field> se usará como origen del campo de destino. Además, <source field> se eliminará de la entrada del registro. Si se hace referencia a un campo de origen tanto en move_from como en copy_from, el campo de origen se eliminará igualmente.

  • copy_from: <source field>

    El valor de <source field> se usará como origen del campo de destino. <source field> no se eliminará de la entrada de registro a menos que también se haga referencia a ella en una operación move_from o se modifique de otro modo.

  • static_value: <string>

    La cadena estática <string> se usará como origen del 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 salida se establecerá en <string>. Si el campo de origen ya existe (aunque contenga una cadena vacía), el valor original no se modifica.

  2. map_values: <map>

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

  3. map_values_exclusive: {true|false}

    Si el valor de <source field> no coincide con ninguna de las claves especificadas en los pares map_values, el campo de destino se anulará de forma forzosa si map_values_exclusive es true o se dejará sin modificar si map_values_exclusive es false.

  4. type: {integer|float}

    El valor de entrada se convertirá en un número entero o un número de coma flotante. Si la cadena no se puede convertir en un número, el valor de salida no se definirá. Si la cadena contiene un número decimal, pero el tipo se especifica como integer, el número se truncará a un entero.

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

  5. omit_if: <filter>

    Si el filtro coincide con el registro de entrada, el campo de salida no se definirá. Se puede usar para quitar valores de marcador de posición, como los siguientes:

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

Configuraciones de ejemplo

El procesador parse_json transformaría un archivo JSON que contuviera

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

en una estructura LogEntry con este aspecto:

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

Después, se podría transformar con modify_fields en este 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 = "-"
  service:
    pipelines:
      pipeline:
        receivers: [in]
        processors: [parse_json, set_http_request]

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

Servicio de registro

El servicio de registro personaliza la verbosidad de los propios registros del agente de Ops y vincula los receptores y procesadores de registro en las canalizaciones. La sección service tiene los siguientes elementos:

  • log_level
  • pipelines

Nivel de verbosidad de los registros

El campo log_level, disponible en las versiones 2.6.0 y posteriores del agente de operaciones, personaliza el nivel de detalle de los registros del submódulo de registro del agente de operaciones. El valor predeterminado es info. Las opciones disponibles son: error, warn, info, debug y trace.

La siguiente configuración personaliza la verbosidad del registro del submódulo de registro para que sea debug:

logging:
  service:
    log_level: debug

Registrar flujos de procesamiento

El campo pipelines puede contener varios IDs y definiciones de canalización. Cada valor de pipeline consta de los siguientes elementos:

  • receivers: es obligatorio para las nuevas canalizaciones. Lista de IDs de receptor, tal como se describe en Registrar receptores. El orden de los IDs de los receptores en la lista no importa. La canalización recoge datos de todos los receptores que se indican.

  • processors: opcional. Lista de IDs de procesadores, tal como se describe en Procesadores de registro. El orden de los IDs de procesador de la lista es importante. Cada registro se procesa en el orden indicado.

Ejemplos de configuraciones de registro 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 recoja y envíe entradas de /var/log/message o /var/log/syslog, redefine 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 recoger registros del subcomponente de monitorización. La configuración de registro vacía completa tiene el siguiente aspecto:

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

Configuraciones de métricas

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

  • receivers: una lista de definiciones de receptor. Un receiver describe la fuente de las métricas; por ejemplo, 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 recogidas por un receptor.
  • service: contiene una sección pipelines que es una lista de definiciones de pipeline. Un 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 configurarlo para que exporte métricas a otros servicios.

Receptores de métricas

El elemento receivers contiene un conjunto de definiciones de receptor. Un receptor describe de dónde se deben obtener 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, e incluir un elemento type. Los tipos integrados válidos son:

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

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

Cada uno de estos tipos de receptor recoge un conjunto de métricas. Para obtener información sobre las métricas específicas que se incluyen, consulta Métricas ingeridas por los receptores.

Solo puedes crear un receptor de cada tipo. Por ejemplo, no puedes definir dos receptores de tipo hostmetrics.

Cambiar el intervalo de recogida en los receptores de métricas

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

Por ejemplo, el siguiente receptor cambia el intervalo de recogida de 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 recogida de los receptores de métricas de Windows iis y mssql con la misma técnica.

Métricas ingeridas por los receptores

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

El receptor de hostmetrics

El receptor hostmetrics ingiere 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 el estado de la CPU
disk Bytes leídos del disco, con la etiqueta del dispositivo
Bytes escritos en el disco, con la etiqueta del dispositivo
Tiempo de E/S del disco, con la etiqueta del dispositivo
Tiempo de E/S ponderado del disco, con la etiqueta del dispositivo
Operaciones pendientes del disco, con la etiqueta del dispositivo
Operaciones combinadas del disco, con las etiquetas del dispositivo y la dirección
Operaciones del disco, con las etiquetas del dispositivo y la dirección
Tiempo de operación del disco, con las etiquetas del dispositivo y la dirección
Uso del disco, con las etiquetas del dispositivo y el estado
Utilización del disco, con las etiquetas del dispositivo y el estado
gpu
Solo para Linux. Consulta Información sobre las métricas gpu para obtener otros datos importantes. 		Número actual de bytes de memoria de la GPU usados, por estado
Cantidad máxima de memoria de la GPU, en bytes, que ha asignado el proceso
Porcentaje del tiempo de vida del proceso en el que se han ejecutado uno o varios kernels en la GPU
Porcentaje del tiempo, desde la última muestra, en el que la GPU ha estado activa
interface
Solo en Linux 		Número total de errores de red
Número total de paquetes enviados a través de la red
Número total de bytes enviados a través de la red
memory Uso de memoria, con una etiqueta que indica el estado (almacenada en búfer, almacenada en caché, libre, losa o usada)
Porcentaje de uso de memoria, con una etiqueta que indica el estado (almacenada en búfer, almacenada en caché, libre, losa o usada)
network Número de conexiones TCP, con etiquetas de puerto y estado TCP.
swap Intercambiar operaciones de E/S, con etiquetas de dirección
Intercambiar bytes usados, con etiquetas de dispositivo y estado
Intercambiar porcentaje usado, con etiquetas de dispositivo y estado
pagefile
Solo en Windows 		Porcentaje actual de archivo de paginación usado por estado
processes Número de procesos, con la etiqueta del estado
Número de procesos bifurcados
E/S de lectura de disco por proceso, con etiquetas del nombre del proceso y otros datos
E/S de escritura de disco por proceso, con etiquetas del nombre del proceso y otros datos
Uso de RSS por proceso, con etiquetas del nombre del proceso y otros datos
Uso de VM por proceso, con etiquetas del nombre del proceso y otros datos
El iis receptor (solo en Windows)

El receptor iis (solo Windows) ingiere 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 mssql receptor (solo en Windows)

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

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

Procesadores de métricas

El elemento processor contiene un conjunto de definiciones de procesador. Un procesador describe las métricas del tipo de receptor que se van a excluir. El único tipo admitido es exclude_metrics, que usa la opción metrics_pattern. El valor es una lista de globs que coinciden con los tipos de métricas del agente de operaciones que quieres excluir del grupo recogido por un receptor. Por ejemplo:

Procesador de métricas de ejemplo

En el ejemplo siguiente 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 recogida de todas las métricas de procesos por parte del agente de operaciones, añade lo siguiente al archivo config.yaml:

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

De esta forma, se excluyen las métricas de procesos de la recogida en el metrics_filterprocesador que se aplica a la canalización predeterminada del 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 Ops y vincula los receptores y procesadores de métricas en las canalizaciones. La sección service tiene dos elementos: log_level y pipelines.

Nivel de detalle de las métricas

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

Flujos de procesamiento de métricas

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

  • receivers: es obligatorio para las nuevas canalizaciones. Lista de IDs de receptor, tal como se describe en Receptores de métricas. El orden de los IDs de los destinatarios de la lista no importa. La canalización recoge datos de todos los receptores que se indican.

  • processors: opcional. Lista de IDs de procesadores, tal como se describe en Procesadores de métricas. El orden de los IDs de procesador de la lista sí importa. Cada punto de métrica se procesa en el orden indicado.

Ejemplos de configuraciones 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 ingestión integrada de métricas de host, redefine la canalización predeterminada con una lista receivers vacía y sin procesadores. La configuración completa de las métricas es la siguiente:

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

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

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

La siguiente configuración de service personaliza el nivel de detalle de los registros del submódulo de métricas para que sea debug:

metrics:
  service:
    log_level: debug

Recogida de registros propios

De forma predeterminada, los registros automáticos de Fluent Bit del agente de Ops se envían a Cloud Logging. Estos registros pueden incluir mucha información y el volumen adicional puede aumentar los costes de uso de Cloud Logging.

Puedes inhabilitar la recogida de estos registros automáticos, a partir de la versión 2.44.0 del agente de operaciones, mediante la opción default_self_log_file_collection.

Para inhabilitar la recogida de registros automáticos, añade una sección global al archivo de configuración que especifique el usuario y asigna el valor false a la opción default_self_log_file_collection:

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

Configuración de rotación de registros

A partir de la versión 2.31.0 de Ops Agent, 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 Configurar la rotación de registros en el agente de Ops.