Recopilación de logs del Agent del host

Documentos > Agent > Recopilación de logs del Agent del host

Para recopilar logs con el Datadog Agent es necesario disponer de la versión 6.0 o posterior. Las versiones anteriores del Agent no incluyen la interfaz log collection. Si todavía no utilizas el Agent, sigue las instrucciones de instalación del Agent.

Consulta Observability Pipelines si quieres enviar logs utilizando el Collector o Forwarder de otro proveedor, o si quieres procesar previamente los datos de los logs dentro de tu entorno antes del envío.

Activar la recopilación de logs

La recopilación de logs no está activada por defecto en el Datadog Agent. Si estás ejecutando el Agent en un entorno Kubernetes o Docker, consulta la documentación sobre recopilación de logs de Kubernetes o recopilación de logs de Docker específica.

Para habilitar la recopilación de logs con un Agent ejecutándose en el host, cambia logs_enabled: false por logs_enabled: true en el archivo principal de configuración (datadog.yaml) del Agent.

datadog.yaml

## @param logs_enabled - boolean - optional - default: false
## @env DD_LOGS_ENABLED - boolean - optional - default: false
## Enable Datadog Agent log collection by setting logs_enabled to true.
logs_enabled: false

## @param logs_config - custom object - optional
## Enter specific configurations for your Log collection.
## Uncomment this parameter and the one below to enable them.
## See https://docs.datadoghq.com/agent/logs/
logs_config:

  ## @param container_collect_all - boolean - optional - default: false
  ## @env DD_LOGS_CONFIG_CONTAINER_COLLECT_ALL - boolean - optional - default: false
  ## Enable container log collection for all the containers (see ac_exclude to filter out containers)
  container_collect_all: false

  ## @param logs_dd_url - string - optional
  ## @env DD_LOGS_CONFIG_LOGS_DD_URL - string - optional
  ## Define the endpoint and port to hit when using a proxy for logs. The logs are forwarded in TCP
  ## therefore the proxy must be able to handle TCP connections.
  logs_dd_url: <ENDPOINT>:<PORT>

  ## @param logs_no_ssl - boolean - optional - default: false
  ## @env DD_LOGS_CONFIG_LOGS_NO_SSL - optional - default: false
  ## Disable the SSL encryption. This parameter should only be used when logs are
  ## forwarded locally to a proxy. It is highly recommended to then handle the SSL encryption
  ## on the proxy side.
  logs_no_ssl: false

  ## @param processing_rules - list of custom objects - optional
  ## @env DD_LOGS_CONFIG_PROCESSING_RULES - list of custom objects - optional
  ## Global processing rules that are applied to all logs. The available rules are
  ## "exclude_at_match", "include_at_match" and "mask_sequences". More information in Datadog documentation:
  ## https://docs.datadoghq.com/agent/logs/advanced_log_collection/#global-processing-rules
  processing_rules:
    - type: <RULE_TYPE>
      name: <RULE_NAME>
      pattern: <RULE_PATTERN>

  ## @param force_use_http - boolean - optional - default: false
  ## @env DD_LOGS_CONFIG_FORCE_USE_HTTP - boolean - optional - default: false
  ## By default, the Agent sends logs in HTTPS batches to port 443 if HTTPS connectivity can
  ## be established at Agent startup, and falls back to TCP otherwise. Set this parameter to `true` to
  ## always send logs with HTTPS (recommended).
  ## Warning: force_use_http means HTTP over TCP, not HTTP over HTTPS. Please use logs_no_ssl for HTTP over HTTPS.
  force_use_http: true

  ## @param force_use_tcp - boolean - optional - default: false
  ## @env DD_LOGS_CONFIG_FORCE_USE_TCP - boolean - optional - default: false
  ## By default, logs are sent through HTTPS if possible, set this parameter
  ## to `true` to always send logs via TCP. If `force_use_http` is set to `true`, this parameter
  ## is ignored.
  force_use_tcp: true

  ## @param use_compression - boolean - optional - default: true
  ## @env DD_LOGS_CONFIG_USE_COMPRESSION - boolean - optional - default: true
  ## This parameter is available when sending logs with HTTPS. If enabled, the Agent
  ## compresses logs before sending them.
  use_compression: true

  ## @param compression_level - integer - optional - default: 6
  ## @env DD_LOGS_CONFIG_COMPRESSION_LEVEL - boolean - optional - default: false
  ## The compression_level parameter accepts values from 0 (no compression)
  ## to 9 (maximum compression but higher resource usage). Only takes effect if
  ## `use_compression` is set to `true`.
  compression_level: 6

  ## @param batch_wait - integer - optional - default: 5
  ## @env DD_LOGS_CONFIG_BATCH_WAIT - integer - optional - default: 5
  ## The maximum time (in seconds) the Datadog Agent waits to fill each batch of logs before sending.
  batch_wait: 5

  ## @param open_files_limit - integer - optional - default: 500
  ## @env DD_LOGS_CONFIG_OPEN_FILES_LIMIT - integer - optional - default: 500
  ## The maximum number of files that can be tailed in parallel.
  ## Note: the default for Mac OS is 200. The default for
  ## all other systems is 500.
  open_files_limit: 500

  ## @param file_wildcard_selection_mode - string - optional - default: `by_name`
  ## @env DD_LOGS_CONFIG_FILE_WILDCARD_SELECTION_MODE - string - optional - default: `by_name`
  ## The strategy used to prioritize wildcard matches if they exceed the open file limit.
  ##
  ## Choices are `by_name` and `by_modification_time`.
  ##
  ## `by_name` means that each log source is considered and the matching files are ordered
  ## in reverse name order. While there are less than `logs_config.open_files_limit` files
  ## being tailed, this process repeats, collecting from each configured source.
  ##
  ## `by_modification_time` takes all log sources and first adds any log sources that
  ## point to a specific file. Next, it finds matches for all wildcard sources.
  ## This resulting list is ordered by which files have been most recently modified
  ## and the top `logs_config.open_files_limit` most recently modified files are
  ## chosen for tailing.
  ##
  ## WARNING: `by_modification_time` is less performant than `by_name` and will trigger
  ## more disk I/O at the configured wildcard log paths.
  file_wildcard_selection_mode: by_name

  ## @param max_message_size_bytes - integer - optional - default: 256000
  ## @env DD_LOGS_CONFIG_MAX_MESSAGE_SIZE_BYTES - integer - optional - default : 256000
  ## The maximum size of single log message in bytes. If maxMessageSizeBytes exceeds
  ## the documented API limit of 1MB - any payloads larger than 1MB will be dropped by the intake.
  https://docs.datadoghq.com/api/latest/logs/
  max_message_size_bytes: 256000

  ## @param integrations_logs_files_max_size - integer - optional - default: 10
  ## @env DD_LOGS_CONFIG_INTEGRATIONS_LOGS_FILES_MAX_SIZE - integer - optional - default: 10
  ## The max size in MB that an integration logs file is allowed to use
  integrations_logs_files_max_size

  ## @param integrations_logs_total_usage - integer - optional - default: 100
  ## @env DD_LOGS_CONFIG_INTEGRATIONS_LOGS_TOTAL_USAGE - integer - optional - default: 100
  ## The total combined usage all integrations logs files can use
  integrations_logs_total_usage

A partir del Agent v6.19/v7.19 o posteriores, HTTPS es el transporte utilizado por defecto. Para obtener más detalles sobre cómo aplicar el transporte HTTPS/TCP, consulta la documentación sobre transporte del Agent.

Para enviar logs con variables de entorno, configura lo siguiente:

DD_LOGS_ENABLED=true

Después de activar la recopilación de logs, el Agent podrá reenviarlos a Datadog. A continuación, configura el Agent para indicarle desde dónde debe recopilar los logs.

Recopilación de logs personalizada

El Datadog Agent v6 puede recopilar logs y reenviarlos a Datadog desde archivos, la red (TCP o UDP), journald y canales de Windows:

En el directorio conf.d/ en la raíz del directorio de configuración del Agent, crea una nueva carpeta <CUSTOM_LOG_SOURCE>.d/ que sea accesible para el usuario de Datadog.
En ella, crea un archivo conf.yaml nuevo.
Añade un grupo de configuración de recopilación de logs personalizada con los parámetros que se detallan a continuación.
Reinicia el Agent para añadir esta nueva configuración.
Ejecuta el subcomando de estado del Agent y busca <CUSTOM_LOG_SOURCE> en la sección de checks.

Si se producen errores de permisos, consulta Problemas de permisos para el rastreo de archivos de logs para solucionar el problema.

A continuación, encontrarás ejemplos de una configuración de recopilación de logs personalizada:

Para recopilar logs de tu aplicación <APP_NAME> almacenada en <PATH_LOG_FILE>/<LOG_FILE_NAME>.log, crea un archivo <APP_NAME>.d/conf.yaml en la raíz del directorio de configuración del Agent que incluya lo siguiente:

logs:
  - type: file
    path: "<PATH_LOG_FILE>/<LOG_FILE_NAME>.log"
    service: "<APP_NAME>"
    source: "<SOURCE>"

En Windows, utiliza la ruta <DRIVE_LETTER>:\<PATH_LOG_FILE>\<LOG_FILE_NAME>.log y verifica que el usuario ddagentuser tenga permiso de lectura y escritura en el archivo de log.

Nota: Una línea de logs debe terminar con un carácter de nueva línea, \n o \r\n, de lo contrario el Agent espera indefinidamente y no envía la línea de logs.

Para recopilar logs de tu aplicación <APP_NAME>, que los transfiere a través del puerto TCP 10518, crea un archivo <APP_NAME>.d/conf.yaml en la raíz del directorio de configuración del Agent que incluya lo siguiente:

logs:
  - type: tcp
    port: 10518
    service: "<APP_NAME>"
    source: "<CUSTOM_SOURCE>"

Si utilizas Serilog, puedes usar Serilog.Sinks.Network para conectarte a través de UDP.

En versiones del Agent 7.31.0 y posteriores, la conexión TCP permanece abierta de forma indefinida, incluso en reposo.

Notas:

El Agent admite cadenas sin procesar, JSON y el logs con el formato Syslog. Si envías logs por lotes, utiliza caracteres de salto de línea para separar tus logs.
Una línea de logs debe terminar con un carácter de nueva línea, \n o \r\n, de lo contrario el Agent espera indefinidamente y no envía la línea de logs.

Para recopilar logs de journald, crea un archivo journald.d/conf.yaml en la raíz del directorio de configuración del Agent que incluya lo siguiente:

logs:
  - type: journald
    path: /var/log/journal/

Consulta la documentación sobre la integración con journald para obtener más información sobre la configuración de entornos contenedorizados y el filtrado de unidades.

Para enviar eventos de Windows como logs a Datadog, añade los canales a conf.d/win32_event_log.d/conf.yaml de forma manual o utiliza el administrador del Datadog.

Para consultar la lista de canales, ejecuta el siguiente comando en un PowerShell:

Get-WinEvent -ListLog *

Para consultar los canales más activos, ejecuta el siguiente comando en un PowerShell:

Get-WinEvent -ListLog * | sort RecordCount -Descending

Luego, añade los canales al archivo de configuración win32_event_log.d/conf.yaml:

logs:
  - type: windows_event
    channel_path: "<CHANNEL_1>"
    source: "<CHANNEL_1>"
    service: "<SERVICE>"
    sourcecategory: windowsevent

  - type: windows_event
    channel_path: "<CHANNEL_2>"
    source: "<CHANNEL_2>"
    service: "<SERVICE>"
    sourcecategory: windowsevent

Edita los parámetros <CHANNEL_X> con el nombre del canal de Windows desde el que quieres recopilar los eventos. Establece el mismo nombre de canal en el parámetro source correspondiente para beneficiarte de la configuración del pipeline de procesamiento automático de la integración.

Por último, reinicia el Agent.

Esta es una lista de todos los parámetros disponibles para la recopilación de logs:

Parámetro	Obligatorio	Descripción
`type`	Sí	Tipo de origen de entrada del log. Los valores válidos son: `tcp`, `udp`, `file`, `windows_event`, `docker` o `journald`.
`port`	Sí	Si `type` es tcp o udp, define el puerto en el que se realiza la escucha de los logs.
`path`	Sí	Si `type` es archivo o journald, configura la ruta de archivo para la recopilación de logs.
`channel_path`	Sí	Si `type` es windows_event, establece una lista de los canales de eventos de Windows para la recopilación de logs.
`service`	Sí	El nombre del servicio que posee el log. Si has instrumentado tu servicio con [Datadog APM 10, este debe ser el mismo nombre de servicio. Consulta las instrucciones de etiquetado unificado de servicios al configurar `service` en diferentes tipos de datos.
`source`	Sí	Atributo que define qué integración está enviando los logs. Si los logs no proceden de una integración existente, este campo puede incluir un nombre de origen personalizado. Sin embargo, se recomienda hacer coincidir este valor con el espacio de nombres de cualquier métrica personalizada relacionada que estés recopilando. Por ejemplo: `myapp` de `myapp.request.count`.
`include_units`	No	Si `type` es journald, es la lista de unidades journald específicas que se deben incluir.
`exclude_paths`	No	Si `type` es archivo, y `path` contiene un carácter comodín, es la lista con el archivo o archivos coincidentes que hay que excluir de la recopilación de logs. Disponible a partir de la versión 6.18 del Agent.
`exclude_units`	No	Si `type` es journald, es la lista de unidades journald específicas que se deben excluir.
`sourcecategory`	No	Atributo que se utiliza para definir la categoría a la que pertenece un atributo de origen. Por ejemplo: `source:postgres, sourcecategory:database` o `source: apache, sourcecategory: http_web_access`.
`start_position`	No	Consulta Posición inicial para obtener más información.
`encoding`	No	Si `type` es archivo, establece qué codificación debe utilizar el Agent para leer el archivo. Utiliza `utf-16-le` para UTF-16 little-endian, `utf-16-be` para UTF-16 big-endian o `shift-jis` para Shift JIS. Si se establece cualquier otro valor, el Agent leerá el archivo como UTF-8. Se añadieron `utf-16-le` y `utf-16be` en las versiones 6.23/7.23 del Agent, y `shift-jis` en las versiones 6.34/7.34 del Agent
`tags`	No	Una lista de etiquetas (tags) añadida a cada log recopilado (más información sobre etiquetado).

Posición inicial

El parámetro start_position es compatible con los tipos de rastreadores file y journald. El parámetro start_position es siempre beginning cuando se rastrea un contenedor.

Compatibilidad:

File: Agent v6.19/7.19 o posteriores
Journald: Agent v6.38/7.38 o posteriores

Si type es file:

Define la posición desde la que el Agent debe comenzar a leer el archivo.
Los valores válidos son beginning, end, forceBeginning y forceEnd (por defecto: end).
La posición beginning no admite rutas con comodines.

Si type es journald:

Define la posición desde la que el Agent debe comenzar a leer el registro.
Los valores válidos son beginning, end, forceBeginning y forceEnd (por defecto: end).

Prioridad

Tanto para el tipo de rastreador file como journald, si se especifica una posición end o beginning, pero se almacena un desplazamiento, este tiene prioridad. El uso de forceBeginning o forceEnd obliga al Agent a utilizar el valor especificado, aunque haya un desplazamiento almacenado.