La integración de AWS CloudWatch con herramientas de observación de terceros puede cambiar las reglas del juego en el monitoreo de servicios sin servidor.
Esta publicación de blog explicará por qué debería integrar CloudWatch con una herramienta de observación de terceros en un entorno de servicios sin servidor.
También aprenderá a exportar registros de CloudWatch de manera efectiva utilizando tecnología sin servidor a herramientas de observación de terceros como DataDog, Grafana y otras para simplificar la administración de registros y brindar información más profunda sobre el rendimiento de sus servicios.
Tabla de contenido
Do you export your CloudWatch logs?
Yes
No
No, but I plan to export in the future
El caso sin servidor para exportar registros de CloudWatch
El monitoreo de un servicio sin servidor comienza con los registros de servicio. AWS Lambda y CloudWatch tienen una integración nativa y transparente. Las funciones Lambda envían sus registros a los grupos de registros de CloudWatch de manera predeterminada. Puede obtener más información sobre las mejores prácticas de registro en una publicación anterior aquí .
Una vez que los registros aparecen en la consola de CloudWatch, el siguiente paso para supervisar el servicio es crear un panel. Puede obtener más información sobre las prácticas recomendadas para la creación de paneles en una publicación anterior aquí .
Sin embargo, los paneles de CloudWatch tienen desventajas: no permiten una vista única de varias cuentas de AWS. Esa capacidad es fundamental cuando se trabaja en una empresa con varios servicios que abarcan varias cuentas de AWS y se necesita depurar las acciones de los usuarios en varios servicios en un solo panel. Además, algunas empresas prefieren herramientas de observación de terceros, como Grafana Cloud, DataDog y otras, debido a su facilidad de uso y otras funciones avanzadas.
Entonces, ¿por qué debería seguir usando CloudWatch? ¿Por qué no enviar los registros directamente a una herramienta de observación de terceros?
Si utiliza tecnología sin servidor, tiene más sentido seguir utilizando CloudWatch como salida de registros predeterminada. A continuación, le explicamos el motivo:
Rendimiento. Supongamos que exportamos todos los registros directamente a un tercero y no los escribimos en CloudWatch. La integración con estas herramientas de terceros puede requerir el uso de un SDK. Los SDK afectan el rendimiento de la función Lambda, ya que el proceso Lambda exporta los registros con una llamada API al tercero durante la invocación.
Menos dependencias de implementación. Otra opción para integrar con herramientas de terceros es utilizar una extensión Lambda (en forma de una capa Lambda, como DataDog ). La capa Lambda tiene sus desventajas, que analizo aquí , pero la principal desventaja es que agrega otra dependencia de tiempo de implementación.
Fácil de cambiar. Si desea cambiar de un tercero a otro (¡sí, sucede!), debe cambiar TODAS sus funciones para usar un nuevo SDK o extensión Lambda, lo que es un gran problema. Sin embargo, si escribe todos los registros en CloudWatch y los exporta desde una solución centralizada en su cuenta a un tercero, cambiar de tercero se traduce en cambiar el exportador de registros mientras que sus servicios no cambian.
Por otro lado, la única desventaja importante de usar CloudWatch y una herramienta de terceros simultáneamente es el almacenamiento de registros en ambos sistemas y el costo adicional que esto implica. Sin embargo, puede reducir los costos al reducir la retención de registros en CloudWatch o al usar las herramientas de terceros solo en cuentas de producción y no en cuentas de desarrollo.
En resumen, escribir registros de funciones Lambda en CloudWatch en lugar de exportarlos directamente a la herramienta de terceros significa un mejor rendimiento, menos dependencias de implementación y un cambio más sencillo a una herramienta de terceros diferente en el futuro, pero estas características tienen un costo adicional.
Ahora, todo lo que queda por hacer es implementar un exportador de registros centralizado que enviará los registros de CloudWatch a un tercero de su elección sin afectar ninguno de sus servicios.
Exportadores sin servidor de CloudWatch Logs
Revisaremos varios diseños para un exportador de registros centralizado. Lo implementará en sus cuentas en toda la organización y se asegurará de que los registros se exporten a la herramienta de terceros. Como se mencionó anteriormente, sus servicios sin servidor no conocen el exportador de registros ni las herramientas de terceros.
Los siguientes diseños se basan en una capacidad de suscripción de CloudWatch para suscribir grupos de registros a un destino, lo que significa que CloudWatch envía flujos de registros a un destino de su elección: Kinesis DataStream, Amazon OpenSearch, función Lambda o Kinesis Firehose.
Estas son las posibles opciones para los puntos de entrada del diseño.
Puede utilizar suscripciones para obtener acceso a una fuente en tiempo real de eventos de registro de CloudWatch Logs y enviarla a otros servicios, como una transmisión de Amazon Kinesis, una transmisión de Amazon Kinesis Data Firehose o AWS Lambda para su procesamiento, análisis o carga personalizados en otros sistemas. Cuando los eventos de registro se envían al servicio receptor, se codifican en base64 y se comprimen con el formato gzip.
Puede agregar un filtro para seleccionar qué grupos de registros no desea exportar. Para obtener más información, consulte la documentación .
Revisaremos varios diseños de exportadores de registros, discutiremos sus ventajas y desventajas y lo fácil que es cambiar entre terceros.
Todos los diseños se basan en una arquitectura sin servidor para mantener los costos de administración y mantenimiento lo más bajos posibles.
Tenga en cuenta que no cubro los costos en esta publicación. Asegúrese de calcular un diseño de su elección y adaptarlo a sus necesidades y presupuesto.
Manguera contra incendios Kinesis
En el siguiente diseño, utilizaremos Kinesis Firehose como punto de entrada que recibe un lote de registros. Cuando se envían eventos de registro al servicio receptor, se codifican en base64 y se comprimen con el formato gzip, según la documentación .
FireHose puede invocar una función Lambda de transformación por lote. La función Lambda puede procesar el lote, modificarlo y devolver el resultado procesado a Firehose. La función tiene cinco minutos por lote para procesarlo. La función Lambda de transformación proporciona varias capacidades potentes que puede implementar:
Filtra los registros del lote, controlando así qué registros exportas a un tercero.
Enriquecer registros con metadatos (etiquetas de pila, etc.)
Elimine la información personal identificable (PII) de los registros antes de enviarlos a un tercero. Usted tiene el control total.
Una vez procesado, Firehose envía el lote a un punto final HTTP de destino. Puede enviarlo a socios de observabilidad de AWS como Datadog , Dynatrace, LogicMonitor, MongoDB, New Relic, Splunk o Sumo Logic.
Ventajas:
Solución totalmente sin servidor.
Firehose maneja fallas en la invocación de funciones de transformación .
Excelente depuración. Puede configurar Firehose para enviar lotes fallidos a un depósito S3. Cada lote incluye registros que ayudan a depurar la falla del destino HTTP. Consulte la documentación aquí .
Capacidades de la función Lambda de transformación como se describió anteriormente.
Es fácil cambiar entre terceros compatibles: todo lo que necesita hacer es cambiar la URL de destino (y las claves secretas de API).
No es necesario escribir código que envíe solicitudes HTTPS y administre reintentos, ya que Firehose lo hace por usted.
Todos los recursos de diseño admiten el escalamiento automático.
Contras:
Si una respuesta no cumple con los requisitos que se indican a continuación, el servidor Kinesis Firehose la trata como si tuviera un código de estado 500 sin cuerpo. - AWS
Firehose tiene un formato de solicitud/respuesta HTTP único; no todas las herramientas de terceros lo admiten. Consulta la documentación aquí .
Kinesis DataStreams y canales EventBridge
Una de las principales desventajas del diseño anterior era que no se admiten TODAS las herramientas de observación de terceros, por ejemplo, Grafana. Los dos diseños siguientes solucionan ese problema y permiten exportar a cualquier herramienta de terceros. Repasemos el primer diseño.
Este diseño se hizo realidad a partir de una conversación con un colega de AWS serverless, Aidan Steele , quien sugirió las canalizaciones de EventBridge como una opción. ¡Gracias, Aidan!
En este ejemplo, suscribiremos nuestros registros a Kinesis DataStreams. Fijaremos la salida de DataStreams en una canalización EventBridge. No podemos usar Firehose como punto de entrada porque no admite la exportación a una canalización EventBridge.
Los pipelines están pensados para integraciones punto a punto entre orígenes y destinos compatibles, con soporte para transformaciones y enriquecimiento avanzados. Reduce la necesidad de conocimientos especializados y código de integración al desarrollar arquitecturas basadas en eventos.
Las tuberías de EventBridge obtendrán un lote de registros de Kinesis DataStreams, activarán una función Lambda de enriquecimiento y enviarán el lote a un destino de API de nuestra elección a través de HTTPS.
En este ejemplo, exportaremos los registros a Grafana.
Puede utilizar las capacidades de filtrado de EventBridge Pipe, pero como los registros están comprimidos, filtrarlos en el Lambda de enriquecimiento es más sencillo.
La función de enriquecimiento Lambda puede implementar capacidades similares a la transformación Lambda en el diseño de Firehose:
Filtrar registros del lote, controlando así qué registros se exportan a un tercero.
Enriquecer registros con metadatos (etiquetas de pila, etc.)
Elimine la información personal identificable (PII) de los registros antes de enviarlos a un tercero. Usted tiene el control total.
Devuelve una carga útil que el tercero espera recibir, es decir, la carga útil JSON que Grafana Loki espera recibir: consulte el ejemplo en los documentos y la imagen a continuación:
El enriquecimiento Lambda devuelve la carga útil que contiene los registros filtrados y enriquecidos en el formato que espera un tercero específico. Luego, la canalización EventBridge envía la carga útil al destino de la API.
EventBridge admite el envío de errores con información de depuración a un S3 similar a Firehose. Esta es una nueva capacidad que se anunció el 15 de noviembre de 2023: https://aws.amazon.com/blogs/compute/introducing-logging-support-for-amazon-eventbridge-pipes/ .
Ventajas:
Solución totalmente sin servidor.
El diseño admite TODOS los terceros a través de exportaciones de registros por lotes HTTP.
Capacidades de la función Lambda de enriquecimiento: filtro, PII, enriquecimiento.
No es necesario escribir código que envíe solicitudes HTTPS y administre reintentos, ya que EventBridge Pipes se encarga de eso por usted.
EventBridge Pipes y Lambda admiten el escalado automático.
Los lotes de registros fallidos se envían a un depósito S3 con información de depuración.
Contras:
Es más difícil cambiar entre terceros: es necesario cambiar el destino de la API de Pipe y reescribir la función de enriquecimiento para que coincida con la carga útil del otro tercero.
KinesisData Streams puede costar más que Firehose si no selecciona el mecanismo de escala correcto que se ajuste a sus ráfagas de registros ( a pedido o aprovisionado ).
Kinesis DataStreams y función Lambda
Este tercer diseño reemplaza a EventBridge Pipes y le brinda el máximo control sobre el manejo de errores y reintentos a costa de código adicional.
Reemplazaremos EventBridge Pipes con una función Lambda como se describe aquí .
Esta única función ahora es necesaria para procesar nuestros registros, filtrar, enriquecer, eliminar información de identificación personal y enviar el lote al tercero con una solicitud HTTP. Debe volver a intentarlo, manejar errores y enviar lotes o entradas de registro fallidos al depósito S3 de respaldo.
Si cree que la función hace demasiado, puede dividirla en dos con un SQS en el medio: función (filtrar, enriquecer, PII) -> SQS -> función (exportar, enviar errores a S3) , donde la segunda función maneja la exportación al tercero. Este diseño es más sólido, pero agrega latencia al proceso de exportación.
Ventajas:
Solución totalmente sin servidor.
El diseño admite TODOS los terceros a través de llamadas por lotes HTTP.
Capacidades de la función Lambda de enriquecimiento: filtro, PII, enriquecimiento.
Ofrece la mejor capacidad de depuración ya que controla la parte crítica de la cadena: la función Lambda.
Lambda admite el escalado automático.
Los registros fallidos se envían a un depósito S3 de respaldo.
Contras:
Necesitas escribir mucho código para que todo funcione.
Es más difícil cambiar entre terceros: es necesario reescribir la función de enriquecimiento para que coincida con la carga útil del otro tercero y cambiar el código que exporta a través de HTTP.
KinesisData Streams puede costar más que Firehose si no selecciona el mecanismo de escala correcto que se ajuste a sus ráfagas de registros ( a pedido o aprovisionado ).
Resumen
Hemos cubierto tres diseños sin servidor para exportar registros de CloudWatch a terceros.
Cada uno tiene sus pros y sus contras. Primero, seleccione el tercero que se ajuste a sus requisitos de observabilidad y luego elija el diseño que se adapte a su tercero.
Recuerde calcular los costos de exportación y diseñar el mecanismo de implementación para implementar el exportador de registros en toda su organización. Asegúrese de administrarlo mediante infraestructura como código (IaC) para que sea fácil de implementar, administrar y actualizar en toda la organización.
Comments