Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.
Referencia del agente de CloudWatch Logs
importante
Esta sección es una referencia para aquellos usuarios que utilicen el agente de Registros de CloudWatch Logs obsoleto. Si utiliza la versión 2 del servicio de metadatos de instancias (IMDSv2), debe utilizar el nuevo agente unificado de CloudWatch. Sin embargo, aunque no esté utilizando IMDSv2, le recomendamos encarecidamente que utilice el nuevo agente unificado de CloudWatch en lugar del agente obsoleto de Registros de CloudWatch. Para obtener más información sobre el nuevo agente unificado de CloudWatch, consulte Recopilación de métricas y registros de instancias de Amazon EC2 y servidores en las instalaciones con el agente de CloudWatch. Para obtener información sobre la migración del agente obsoleto de Registros de CloudWatch al agente unificado, consulte Creación del archivo de configuración del agente de CloudWatch con el asistente.
El agente de CloudWatch Logs proporciona una forma automatizada de enviar datos de registro a CloudWatch Logs desde instancias de Amazon EC2. El agente incluye los componentes siguientes:
-
Un complemento a la AWS CLI que envía los datos de registro a CloudWatch Logs.
-
Un script (daemon) que inicia el proceso para enviar datos a CloudWatch Logs.
-
Un trabajo cron que garantiza que el daemon esté siempre en ejecución.
Archivo de configuración del agente
En el archivo de configuración del agente de CloudWatch Logs se describe la información que necesita dicho agente de CloudWatch Logs. La sección [general] del archivo de configuración del agente define las configuraciones comunes que se aplican a todos los flujos de registro. La sección [logstream] define la información necesaria para enviar un archivo local a un flujo de registros remoto. Puede tener más de una sección [logstream], pero cada una debe tener un nombre único en el archivo de configuración, por ejemplo, [logstream1], [logstream2], etc. El valor [logstream] junto con la primera línea de datos en el archivo de registro define la identidad del archivo de registro.
[general] state_file =
value
logging_config_file =value
use_gzip_http_content_encoding = [true | false] [logstream1] log_group_name =value
log_stream_name =value
datetime_format =value
time_zone = [LOCAL|UTC] file =value
file_fingerprint_lines =integer
|integer
-integer
multi_line_start_pattern =regex
| {datetime_format
} initial_position = [start_of_file | end_of_file] encoding = [ascii|utf_8|..] buffer_duration =integer
batch_count =integer
batch_size =integer
[logstream2] ...
- state_file
-
Especifica dónde se almacena el archivo de estado.
- logging_config_file
-
(Opcional) Especifica la ubicación del archivo de configuración de registro del agente. Si no especifica aquí un archivo de configuración de registro de agente, se utiliza el archivo de configuración. La ubicación predeterminada del archivo es
/var/awslogs/etc/awslogs.conf
si instaló el agente con un script y es/etc/awslogs/awslogs.conf
si instaló el agente con rpm. El archivo se encuentra en formato de archivo de configuración de Python (https://docs.python.org/2/library/logging.config.html#logging-config-fileformat). Las funciones de registro con los nombres siguientes se pueden personalizar.cwlogs.push cwlogs.push.reader cwlogs.push.publisher cwlogs.push.event cwlogs.push.batch cwlogs.push.stream cwlogs.push.watcher
El ejemplo siguiente cambia el nivel de lector y editor a WARNING mientras el valor por defecto es INFO.
[loggers] keys=root,cwlogs,reader,publisher [handlers] keys=consoleHandler [formatters] keys=simpleFormatter [logger_root] level=INFO handlers=consoleHandler [logger_cwlogs] level=INFO handlers=consoleHandler qualname=cwlogs.push propagate=0 [logger_reader] level=WARNING handlers=consoleHandler qualname=cwlogs.push.reader propagate=0 [logger_publisher] level=WARNING handlers=consoleHandler qualname=cwlogs.push.publisher propagate=0 [handler_consoleHandler] class=logging.StreamHandler level=INFO formatter=simpleFormatter args=(sys.stderr,) [formatter_simpleFormatter] format=%(asctime)s - %(name)s - %(levelname)s - %(process)d - %(threadName)s - %(message)s
- use_gzip_http_content_encoding
-
Cuando se establece en VERDADERO (predeterminado), permite la codificación de contenido gzip http para enviar cargas comprimidas a CloudWatch Logs. Esto reduce la utilización de la CPU, reduce NetworkOut y reduce la latencia de Put. Para desactivar esta característica, agregue use_gzip_http_content_encoding = false a la sección [general] del archivo de configuración del agente de CloudWatch Logs y, a continuación, reinicie el agente.
nota
Esta configuración solo está disponible en la versión 1.3.3 o posterior de awscli-cwlogs.
- log_group_name
-
Especifica el grupo de registro de destino. Un grupo de registro se crea automáticamente si no existe todavía. Los nombres de grupo de registros puede tener de 1 a 512 caracteres de longitud. Entre los caracteres permitidos se incluyen a-z, A-Z, 0-9, "_" (carácter de subrayado), "-" (guion), "/" (barra diagonal) y "." (punto).
- log_stream_name
-
Especifica el flujo de registro de destino. Puede usar una cadena literal, variables predefinidas ({instance_id}, {hostname} y {ip_address}), o una combinación de ellas para definir el nombre del flujo de registro. Un flujo de registro se crea automáticamente si no existe todavía.
- datetime_format
-
Especifica cómo se extrae la marca temporal de los registros. La marca temporal se utiliza para recuperar eventos de registro y generar métricas. Se utiliza la hora actual para cada evento de registro si no se proporciona datetime_format. Si el valor de datetime_format proporcionado no es válido para un mensaje de registro determinado, se utiliza la marca temporal (analizada correctamente) del último evento de registro. Si no existen eventos de registro anteriores, se utiliza la hora actual.
Los códigos datetime_format comunes se enumeran a continuación. También puede utilizar cualquier código datetime_format que admita Python, datetime.strptime (). El desfase de la zona horaria (%z) también se admite aunque no se ha admitido hasta python 3.2, [+ -] HHMM sin dos puntos (:). Para obtener más información, consulte strftime() and strptime() Behavior
. %y: año sin siglo como número decimal rellenado con ceros. 00, 01, ..., 99
%Y: año con siglo como número decimal. 1970, 1988, 2001, 2013
%b: mes como nombre abreviado de configuración regional. Ene, Feb, ..., Dic (es_ES);
%B: mes como nombre completo de configuración regional. enero, febrero,..., diciembre (es_ES);
%m: mes como número decimal rellenado con ceros. 01, 02, ..., 12
%d: día del mes como número decimal rellenado con ceros. 01, 02, ..., 31
%H: hora (formato de 24 horas) como número decimal rellenado con ceros. 00, 01, ..., 23
%I: hora (formato de 12 horas) como número decimal rellenado con ceros. 01, 02, ..., 12
%p: equivalente de la configuración regional a AM o PM.
%M: minutos como número decimal rellenado con ceros. 00, 01, ..., 59
%S: segundos como número decimal rellenado con ceros. 00, 01, ..., 59
%f: microsegundos como número decimal, rellenado con ceros a la izquierda. 000000, ..., 999999
%z: desplazamiento UTC en la forma +HHMM o -HHMM. +0000, -0400, +1030
Formatos de ejemplo:
Syslog: '%b %d %H:%M:%S', e.g. Jan 23 20:59:29
Log4j: '%d %b %Y %H:%M:%S', e.g. 24 Jan 2014 05:00:00
ISO8601: '%Y-%m-%dT%H:%M:%S%z', e.g. 2014-02-20T05:20:20+0000
- time_zone
-
Especifica la zona horaria de la marca temporal de evento de registro. Los dos valores admitidos son UTC y LOCAL. El valor predeterminado es LOCAL, que se utiliza en caso de que la zona horaria no se pueda determinar a partir de datetime_format.
- archivo
-
Especifica los archivos de registro que desea enviar a CloudWatch Logs. File puede apuntar a un archivo específico o a varios archivos (utilizando comodines como /var/log/system.log*). Solo se envía el último archivo a CloudWatch Logs en función de la hora de modificación del archivo. Le recomendamos que utilice comodines para especificar una serie de archivos del mismo tipo, como access_log.2014-06-01-01, access_log.2014-06-01-02, etc., pero no varios tipos de archivos, como por ejemplo access_log_80 y access_log_443. Para especificar varios tipos de archivos, agregue otra entrada de flujo de registro al archivo de configuración para que cada tipo de archivo de registro vaya a un flujo de registros distinto. Los archivos comprimidos no son compatibles.
- file_fingerprint_lines
-
Especifica el intervalo de líneas para identificar un archivo. Los valores admitidos son un número o dos números delimitados por guion, como, por ejemplo, "1", "2-5". El valor predeterminado es "1" de modo que se utiliza la primera línea para calcular la huella. Las líneas de huella no se envían a CloudWatch Logs, a menos que todas las líneas especificadas estén disponibles.
- multi_line_start_pattern
-
Especifica el patrón para identificar el inicio de un mensaje de registro. Un mensaje de registro consta de una línea que coincide con el patrón y de líneas siguientes que no coinciden con el patrón. Los valores válidos son expresiones regulares o {datetime_format}. Cuando se utiliza {datetime_format}, se debe especifica la opción datetime_format. El valor predeterminado es "^[^\s]" de modo que cualquier línea que comience con un carácter sin espacios en blanco cierra el mensaje de registro anterior y comienza un nuevo mensaje de registro.
- initial_position
-
Especifica dónde empezar a leer datos (start_of_file o end_of_file). El valor predeterminado es start_of_file. Se utiliza únicamente si no se almacena de forma persistente ningún estado para dicho flujo de registro.
- encoding
-
Especifica la codificación del archivo de registro, de modo que el archivo se pueda leer correctamente. El valor predeterminado es utf_8. Se pueden utilizar aquí las codificaciones compatibles con Python codecs.decode().
aviso
La especificación de una codificación incorrecta podría provocar pérdida de datos porque los caracteres que no se pueden descodificar se sustituirán por otro carácter.
A continuación se muestran las codificaciones comunes:
ascii, big5, big5hkscs, cp037, cp424, cp437, cp500, cp720, cp737, cp775, cp850, cp852, cp855, cp856, cp857, cp858, cp860, cp861, cp862, cp863, cp864, cp865, cp866, cp869, cp874, cp875, cp932, cp949, cp950, cp1006, cp1026, cp1140, cp1250, cp1251, cp1252, cp1253, cp1254, cp1255, cp1256, cp1257, cp1258, euc_jp, euc_jis_2004, euc_jisx0213, euc_kr, gb2312, gbk, gb18030, hz, iso2022_jp, iso2022_jp_1, iso2022_jp_2, iso2022_jp_2004, iso2022_jp_3, iso2022_jp_ext, iso2022_kr, latin_1, iso8859_2, iso8859_3, iso8859_4, iso8859_5, iso8859_6, iso8859_7, iso8859_8, iso8859_9, iso8859_10, iso8859_13, iso8859_14, iso8859_15, iso8859_16, johab, koi8_r, koi8_u, mac_cyrillic, mac_greek, mac_iceland, mac_latin2, mac_roman, mac_turkish, ptcp154, shift_jis, shift_jis_2004, shift_jisx0213, utf_32, utf_32_be, utf_32_le, utf_16, utf_16_be, utf_16_le, utf_7, utf_8, utf_8_sig
- buffer_duration
-
Especifica la duración para agrupar en lotes eventos de registro. El valor mínimo es 5000ms y valor predeterminado es 5000ms.
- batch_count
-
Especifica el número máximo de eventos de registro en un lote, hasta 10 000. El valor predeterminado es 10 000.
- batch_size
-
Especifica el tamaño máximo de eventos de registro en un lote, en bytes, hasta 1 048 576 bytes. El valor predeterminado es de 1 048 576 bytes. Este tamaño se calcula como la suma de todos los mensajes de eventos en UTF-8, más 26 bytes para cada evento de registro.
Uso del agente de CloudWatch Logs con servidores proxy HTTP
Puede utilizar el agente de CloudWatch Logs con servidores proxy HTTP.
nota
Los servidores proxy HTTP se admiten en awslogs-agent-setup.py versión 1.3.8 o posterior.
Para utilizar el agente de CloudWatch Logs con servidores proxy HTTP
-
Realice una de las siguientes acciones siguientes:
-
Para una nueva instalación del agente de CloudWatch Logs, ejecute los siguientes comandos:
curl https://s3.amazonaws.com/aws-cloudwatch/downloads/latest/awslogs-agent-setup.py -O
sudo python awslogs-agent-setup.py --region
us-east-1
--http-proxyhttp://your/proxy
--https-proxyhttp://your/proxy
--no-proxy 169.254.169.254Para mantener el acceso al servicio de metadatos de Amazon EC2 en instancias EC2, utilice --no-proxy 169.254.169.254 (recomendado). Para obtener más información, consulte Metadatos de instancia y datos de usuario en la Guía del usuario de Amazon EC2.
En el valor de
http-proxy
yhttps-proxy
, especifique la URL completa. -
Si se trata de una instalación existente del agente de CloudWatch Logs, edite /var/awslogs/etc/proxy.conf y agregue los servidores proxy:
HTTP_PROXY= HTTPS_PROXY= NO_PROXY=
-
-
Reinicie el agente para que los cambios surtan efecto:
sudo service awslogs restart
Si está utilizando Amazon Linux 2, utilice el comando siguiente para reiniciar el agente:
sudo service awslogsd restart
Separar en compartimentos los archivos de configuración de agente de CloudWatch Logs
Si utiliza la versión 1.3.8 o posterior de awslogs-agent-setup.py con awscli-cwlogs 1.3.3 o una versión posterior, puede importar diferentes configuraciones de flujo para diversos componentes de forma independiente entre sí mediante la creación de archivos de configuración adicionales en el directorio /var/awslogs/etc/config/. Cuando se inicia el agente de CloudWatch Logs, se incluye cualquier configuración de flujo en estos archivos de configuración adicionales. Las propiedades de configuración en la sección [general] deben definirse en el archivo de configuración principal (/var/awslogs/etc/awslogs.conf) y se omiten en los archivos de configuración adicionales que se encuentran en /var/awslogs/etc/config/.
Si no dispone de un directorio /var/awslogs/etc/config/ dado que ha instalado el agente con rpm, puede utilizar en su lugar el directorio /etc/awslogs/config/.
Reinicie el agente para que los cambios surtan efecto:
sudo service awslogs restart
Si está utilizando Amazon Linux 2, utilice el comando siguiente para reiniciar el agente:
sudo service awslogsd restart
Preguntas frecuentes sobre agentes de CloudWatch Logs
- ¿Qué tipo de rotaciones de archivo se admiten?
-
Se admiten los siguientes mecanismos de rotación de archivos:
-
Cambiar el nombre de los archivos de registro existentes por un sufijo numérico y, a continuación, volver a crear el archivo de registro vacío original. Por ejemplo, el nombre de /var/log/syslog.log se cambia a /var/log/syslog.log.1. Si ya existe /var/log/syslog.log.1 de una rotación anterior, se cambia el nombre a /var/log/syslog.log.2.
-
Truncar el archivo de registro original en vigor después de crear una copia. Por ejemplo, /var/log/syslog.log se copia a /var/log/syslog.log.1 y /var/log/syslog.log se trunca. Podría haber pérdida de datos en este caso, por tanto tenga cuidado a la hora de utilizar este mecanismo de rotación de archivo.
-
Creación de un nuevo archivo con un patrón común como el antiguo. Por ejemplo, se mantiene /var/log/syslog.log.2014-01-01 y se crea /var/log/syslog.log.2014-01-02.
La huella (ID de origen) del archivo se calcula mediante el hash de la clave del flujo de registro y la primera línea de contenido del archivo. Para omitir este comportamiento, se puede utilizar la opción file_fingerprint_lines. Cuando se produce la rotación de archivos, el nuevo archivo se supone que tiene nuevo contenido y el archivo antiguo no se supone que tenga contenido añadido; el agente envía el nuevo archivo una vez que termine la lectura del antiguo.
-
- ¿Cómo puedo determinar la versión del agente que estoy utilizando?
-
Si utilizó un script de configuración para instalar el agente de CloudWatch Logs, puede utilizar /var/awslogs/bin/awslogs-version.sh para verificar la versión del agente que utiliza. Imprime la versión del agente y sus dependencias principales. Si utilizó yum para instalar el agente de CloudWatch Logs, puede utilizar “yum info awslogs” y “yum info aws-cli-plugin-cloudwatch-logs” para verificar la versión del complemento y del agente de CloudWatch Logs.
- ¿Cómo se convierten las entradas de registro a eventos de registro?
-
Los eventos de registro contienen dos propiedades: la marca temporal de cuando se produjo el evento y el mensaje de registro sin procesar. De forma predeterminada, cualquier línea que comience con un carácter sin espacios en blanco cierra el mensaje de registro anterior si lo hay y comienza un nuevo mensaje de registro. Para anular este comportamiento, se puede usar multi_line_start_pattern y todas las líneas que coincidan con el patrón inician un nuevo mensaje de registro. El patrón podría ser cualquier regex o "{datetime_format}". Por ejemplo, si la primera línea de cada mensaje de registro contiene una marca temporal como “2014-01-02T13:13:01Z”, multi_line_start_pattern se puede establecer en “\d{4}-\d{2}-\d{2}T\d{2}:\d{2}:\d{2}Z”. Para simplificar la configuración, la variable "{datetime_format}" variable se puede utilizar si se especifica datetime_format option. Para el mismo ejemplo, si datetime_format se establece en "%Y-%m-%dT%H:%M:%S%z", entonces el patrón multi_line_start_pattern podría ser sencillamente "{datetime_format}".
Se utiliza la hora actual para cada evento de registro si no se proporciona datetime_format. Si el valor de datetime_format proporcionado no es válido para un mensaje de registro determinado, se utiliza la marca temporal (analizada correctamente) del último evento de registro. Si no existen eventos de registro anteriores, se utiliza la hora actual. Se registra un mensaje de advertencia cuando un evento de registro utiliza la hora actual o la hora del evento de registro anterior.
Las marcas temporales se utilizan para recuperar eventos de registro y generar métricas, por lo que si especifica el formato equivocado, los eventos de registro no podrían recuperarse y podrían generar métricas erróneas.
- ¿Cómo se agrupan en lotes los eventos de registro?
-
Un lote se completa y se publica cuando cumple alguna de las siguientes condiciones:
-
La cantidad de tiempo de buffer_duration que ha transcurrido desde que se agregó el primer evento de registro.
-
Se ha acumulado un valor inferior a batch_size para eventos de registro, pero al agregar el nuevo evento de registro se supera el valor de batch_size.
-
El número de eventos de registro ha alcanzado el valor batch_count.
-
Los eventos de registro del lote no abarcan más de 24 horas, pero al añadir el nuevo evento de registro se supera la restricción de 24 horas.
-
- ¿Qué provocaría la omisión o el truncamiento de las entradas de registro, los eventos de registro o los lotes?
-
Para seguir la restricción de la operación
PutLogEvents
, los siguientes problemas podrían provocar la omisión de un evento de registro o lote.nota
El agente de CloudWatch Logs escribe una advertencia en su registro cuando se omiten datos.
-
Si el tamaño de un evento de registro es superior a 256 KB, el evento de registro se omitirá por completo.
-
Si la marca temporal del evento de registro es de más de 2 horas en el futuro, se omitirá el evento de registro.
-
Si la marca temporal del evento de registro es de más de 14 días en el pasado, se omitirá el evento de registro.
-
Si cualquier evento de registro es más antiguo que el periodo de retención del grupo de registro, se omitirá todo el lote.
-
Si el lote de eventos de registro en una solicitud
PutLogEvents
única abarca más de 24 horas, la operaciónPutLogEvents
falla.
-
- ¿Provoca la parada del agente la pérdida de datos/duplicados?
-
No siempre y cuando el archivo de estado esté disponible y no se haya producido la rotación de ningún archivo desde la última ejecución. El agente de CloudWatch Logs puede iniciarse desde donde se paró y continuar enviando los datos de registro.
- ¿Puedo señalar a diferentes archivos de registro desde el mismo host o diferentes al mismo flujo de registro?
-
No se admite configurar varias fuentes de registro para enviar datos a un único flujo de registro.
- ¿Qué llamadas al API realiza el agente (o qué acciones debo agregar a mi política de IAM)?
-
El agente de CloudWatch Logs requiere las operaciones
CreateLogGroup
,CreateLogStream
,DescribeLogStreams
yPutLogEvents
. Si está utilizando el último agente, no es necesarioDescribeLogStreams
. Consulte la política de IAM de ejemplo a continuación.{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "logs:CreateLogGroup", "logs:CreateLogStream", "logs:PutLogEvents", "logs:DescribeLogStreams" ], "Resource": [ "arn:aws:logs:*:*:*" ] } ] }
- No deseo que el agente de CloudWatch Logs cree grupos de registro o flujos de registro de forma automática. ¿Cómo puedo evitar que el agente vuelva a crear grupos de registro y flujos de registro?
-
En la política de IAM, puede limitar el agente solo a las siguientes operaciones:
DescribeLogStreams
,PutLogEvents
.Antes de revocar los permisos
CreateLogStream
yCreateLogGroup
del agente, asegúrese de crear los grupos de registro y las secuencias de registro que desee que utilice el agente. El agente de registros no puede crear secuencias de registro en un grupo de registros que haya creado a menos que tenga los permisosCreateLogStream
yCreateLogGroup
. - ¿Qué registros debería examinar durante la resolución de problemas?
-
El registro del agente de instalación se encuentra en
/var/log/awslogs-agent-setup.log
y el registro del agente, en/var/log/awslogs.log
.