View a markdown version of this page

Ingestión de Syslog - Amazon CloudWatch Logs

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.

Ingestión de Syslog

La ingesta de syslog gestionada por Amazon CloudWatch Logs le permite enviar mensajes de syslog (RFC 5424, RFC 3164 y Cisco FTD/ASA) desde firewalls, enrutadores, conmutadores y servidores Linux directamente a Logs, sin instalar ni administrar ningún agente. CloudWatch Sus fuentes de syslog envían mensajes a través de TCP, TCP+TLS o UDP a un punto final de VPC de su cuenta. El tráfico se canaliza hacia el servicio syslog CloudWatch Logs, que analiza automáticamente los mensajes entrantes y extrae campos estructurados, como el centro, la gravedad, el nombre de host y el nombre de la aplicación, lo que elimina la necesidad de utilizar canalizaciones de análisis personalizadas. AWS PrivateLink A continuación, puede consultar estos campos mediante CloudWatch Logs Analytics para investigar los eventos de seguridad o solucionar problemas de conectividad. Esto le ayuda a centralizar la visibilidad de los registros de la infraestructura, simplificar los flujos de trabajo operativos y reducir la sobrecarga que supone la implementación y el mantenimiento de los agentes de recopilación de registros en entornos distribuidos.

Si sus fuentes de syslog ya se encuentran en su Amazon VPC, pueden enviar mensajes directamente al punto de enlace de la VPC. Si sus fuentes están fuera AWS (centros de datos locales, sucursales o instalaciones de ubicación conjunta), pueden llegar al punto final de la VPC a través de su conexión VPN o Direct Connect.

Protocolos y puertos compatibles

Protocolo Puerto Notas
TCP + TLS 6514 Encriptado en tránsito. Recomendado para cumplir con los requisitos de conformidad.
Texto sin formato de TCP 1514 Texto sin formato sobre AWS PrivateLink (aislado de la red).
UDP 514 Best-effort entrega.

El TLS del puerto 6514 finaliza en el balanceador de carga de la red mediante un certificado AWS gestionado emitido por Amazon Trust Services. Sus clientes de syslog confían en este certificado automáticamente sin ninguna configuración especial.

nota

UDP es el protocolo más eficaz. Es posible que los mensajes se pierdan debido a las condiciones de la red. Utilice TCP para una entrega fiable.

Formatos de syslog compatibles

CloudWatch Logs detecta y analiza automáticamente los siguientes formatos de syslog:

  • RFC 5424 (el formato más nuevo): incluye datos estructurados, marcas de tiempo ISO 8601 y campos explícitos de nombre de aplicación e ID de proceso.

  • RFC 3164 (syslog de BSD, el formato anterior): incluye marcas de tiempo y un campo TAG. BSD-style Todavía lo utilizan ampliamente los dispositivos de red, como firewalls, enrutadores y conmutadores.

  • Cisco FTD/ASA: formato syslog utilizado por los dispositivos Cisco Firepower Threat Defense (FTD) y Adaptive Security Appliance (ASA). Los mensajes se identifican mediante la %ASA- etiqueta %FTD- o en el cuerpo del mensaje.

Los mensajes se almacenan en el grupo de registros en su formato original sin procesar. CloudWatch Logs extrae automáticamente los campos estructurados de cada formato, que puede consultar con CloudWatch Logs Insights.

Campos extraídos mediante el RFC 5424

Campo Description (Descripción)
facilityNombre de la categoría de registro (por ejemplo,, kernauth,local0).
facilityCodeCódigo de instalación numérico (0—23).
severityNombre del nivel de gravedad (por ejemplo, emergerr,info).
severityCodeCódigo de gravedad numérico (0—7).
timestampMarca de tiempo del mensaje en formato ISO 8601.
hostnameNombre de host del dispositivo de origen.
appNameNombre de la aplicación.
procIdIdentificador del proceso.
msgIdIdentificador del mensaje.
structuredDataElementos de datos estructurados según el RFC 5424 (metadatos clave-valor).
messageCuerpo del mensaje.

Campos extraídos del RFC 3164

Campo Description (Descripción)
facilityNombre de la categoría de registro.
facilityCodeCódigo numérico de instalación (0—23).
severityNombre del nivel de gravedad.
severityCodeCódigo de gravedad numérico (0—7).
timestampMarca de tiempo del mensaje (convertida del formato BSD a la ISO 8601).
hostnameNombre de host del dispositivo de origen.
appNameNombre de la aplicación (extraído del campo TAG).
procIdID del proceso (extraído del campo TAG, si está presente).
messageCuerpo del mensaje.

Campos FTD/ASA extraídos por Cisco

Campo Description (Descripción)
deviceTipo de dispositivo (FTD,ASA, oFMC-AUDIT-LOG).
timestampMarca de tiempo del mensaje (formato RFC 3164 o RFC 5424, según la configuración del dispositivo).
deviceIdNombre de host del dispositivo (presente cuando se configura el device-id registro en el dispositivo).
severityNombre del nivel de gravedad (por ejemplo,informational,warning,critical).
severityLevelNivel de gravedad numérico (0—7).
messageIdIdentificador numérico de mensajes de Cisco (por ejemplo,106023,302013).
subsystemNombre del subsistema (presente para ciertos tipos de mensajes).
messageCuerpo del mensaje (texto sin formato) o campos clave-valor individuales cuando el cuerpo utiliza el formato estructurado de Cisco.

Entrega de mensajes

A diferencia HTTP-based de la ingesta, en la que el servidor devuelve un código de estado para cada solicitud, syslog no proporciona al remitente una confirmación de éxito por mensaje. Una vez que el servicio recibe los mensajes, se almacenan en el búfer y se envían al grupo de registros, con reintentos en caso de errores transitorios. Las garantías de entrega dependen del protocolo de transporte que elija:

  • TCP (puertos 6514 y 1514): proporciona una entrega fiable en condiciones de funcionamiento normales.

    Cuando no es posible realizar la entrega, el servicio restablece la conexión TCP para avisar al cliente del fallo. Es posible que los mensajes en movimiento en esa conexión se pierdan, pero el restablecimiento de la conexión proporciona una contrapresión inmediata para que el cliente pueda detectar el problema y almacenar los mensajes en búfer local hasta que se resuelva la situación. Debido a la presión de capacidad, el servicio rechaza anticipadamente las nuevas conexiones TCP y proporciona la misma señal de contrapresión.

    Entre las condiciones que provocan el restablecimiento de una conexión se incluyen las siguientes:

    • La política de puntos finales de la VPC deniega el acceso

    • Se ha superado la PutLogEvents cuota de su cuenta

    • El grupo de registros de destino no existe

    • La política de recursos del grupo de registros deniega el acceso

  • UDP (puerto 514): Best-effort entrega. Los mensajes que no se pueden entregar se descartan sin ninguna respuesta para el remitente. Los mensajes también se pueden perder debido a la congestión de la red o a limitaciones de capacidad. Use TCP si la entrega confiable es importante para su caso de uso.

Para detectar problemas de entrega y responder a ellos, monitorea la SyslogMessagesDropped métrica CloudWatch. La Reason dimensión indica por qué se descartaron los mensajes para que puedas tomar medidas correctivas. Para obtener más información, consulte Supervisión de la ingesta de syslog.

Cuotas y límites

Límite Valor Notas
Tamaño máximo de mensaje (TCP) 64 KB Los mensajes syslog estándar suelen estar muy por debajo de este límite. Si tiene un caso de uso que requiere mensajes más grandes, póngase en contacto con AWS Support.
Tamaño máximo de los mensajes (UDP) 8 KB Los mensajes syslog estándar suelen estar muy por debajo de este límite. Si tiene un caso de uso que requiere mensajes más grandes, póngase en contacto con AWS Support.
Rendimiento de ingestión Compartido con PutLogEvents La ingesta de Syslog se tiene en cuenta en la PutLogEvents cuota de su cuenta (de forma predeterminada, 5000 solicitudes por segundo por cuenta y región).

La cuota de PutLogEvents se puede ajustar. Si su tráfico de syslog requiere un mayor rendimiento, solicite un aumento de cuota a través de Service Quotas.