docker - tutorial - m4 xlarge elasticsearch
¿Es posible tener el Registro centralizado para las aplicaciones de ElasticBeanstalk Docker? (5)
Tenemos la aplicación web Docker personalizada que se ejecuta en el entorno de contenedor Elastic Beanstalk Docker. Quisiera que los registros de aplicaciones estuvieran disponibles para verlos afuera. Sin descargar a través de instancias o consola de AWS.
Hasta ahora ninguna de las soluciones ha sido aceptable. ¿Tal vez alguien logró un registro centralizado para las aplicaciones Dockerized de Elastic Benastalk?
Solución 1: descarga de registro de la consola AWS
no aceptable - requiere descargar logs, extraer cada vez. No en tiempo real.
Solución 2: S3 + Elasticsearch + Fluentd
fluentd no tiene un complemento para recuperar registros de S3. Hay un excelente complemento de S3, pero es solo para la salida de registros a S3. no para los registros de entrada de S3.
Solución 3: S3 + Elasticsearch + Logstash
contras: sólo puede extraer todos los registros de un cubo completo o nada.
El problema radica en la estructura de almacenamiento de registro de Elastic Beanstalk S3. No puede especificar el patrón de nombre de archivo. Es o todos los registros o nada. ElasticBeanstalk guarda los registros en S3 en la ruta que contiene los identificadores aleatorios de instancias y entornos:
s3.bucket/resources/environments/logs/publish/e-<random environment id>/i-<random instance id>/my.log@
El complemento Logstash s3 solo puede apuntar a recursos / ambientes / registros / publicar /. Cuando intenta apuntarlo a los entornos / logs / publish / * / my.log no funciona. lo que significa que no puede extraer un registro particular y etiquetarlo / escribirlo para poder encontrarlo en Elasticsearch. Como AWS guarda los registros de todos sus entornos e instancias en la misma estructura de carpetas, no puede elegir ni siquiera la instancia.
Solución 4: Visor de registro de la consola de AWS CloudWatch
Es posible reenviar sus registros personalizados a la consola de CloudWatch. Consíguelo, ponga los archivos de configuración en la ruta .ebextensions de su paquete de aplicaciones: http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/AWSHowTo.cloudwatchlogs.html
Hay un archivo llamado cwl-webrequest-metrics.config que le permite especificar los archivos de registro junto con las alertas, etc. ¡¿Genial? excepto que el formato del archivo de configuración no es niaml, xml ni Json, y no está documentado. Hay absolutamente cero menciones de ese archivo, su formato se encuentra en el sitio web de documentación de AWS o en cualquier lugar de la red. Y para que un archivo de registro aparezca en CloudWatch no es simplemente agregar una línea de configuración. La única forma posible de hacer que esto funcione parece ser prueba y error. ¿¡Genial!? a excepción de todos los intentos que necesite para volver a implementar su entorno.
Solo hay una referencia sobre cómo hacer que esto funcione con un registro personalizado: http://qiita.com/kozayupapa/items/2bb7a6b1f17f4e799a22 No tengo idea de cómo esa persona realizó la ingeniería inversa del formato de archivo.
contras:
- Cloudwatch no parece poder dividir los registros en columnas cuando se muestra, por lo que no puede filtrar fácilmente por prioridad, etc.
- El visor de registro de la consola de AWS no tiene actualización automática para seguir los registros.
- Pesadilla formato de archivo de configuración no documentado, no hay forma de prueba. Prueba y error requiere volver a desplegar toda la instancia.
El método más sencillo que encontré para hacer esto fue usar papertrail través de rsyslog y .ebextensions, sin embargo, es muy costoso para registrar todo.
Lo bueno es que con rsyslog puedes enviar tus registros a cualquier parte y no estás atado a papertrail.
He empezado a usar Sumologic por el momento. Hay una versión de prueba gratuita y luego un nivel gratuito (500 mb / día, 7 días de retención). Aún no estoy fuera del período de prueba y mi aplicación EB no hace literalmente nada (solo son unas pocas páginas HTML servidas por Nginx en un contenedor acoplable. Sin embargo, parece que podría ser costoso una vez que haya alcanzado una cantidad importante de registros).
Funciona bien hasta ahora. Debe crear un usuario de IAM que tenga acceso al grupo de S3 del que desea leer y luego aspira los registros a los servidores de Sumologic y realiza todo el procesamiento y la búsqueda allí. Poco complicado de configurar, pero realmente no veo cómo podría ser más simple y está razonablemente bien documentado.
Le permite proporcionar diferentes expresiones de ruta con comodines, luego asignar una "sourceCategory" a esas rutas diferentes. A continuación, utiliza esas categorías de origen para filtrar su búsqueda de registros a un tipo específico de registro.
Mi plan a largo plazo es usar algo como su solución 3, pero esto me hizo avanzar muy rápidamente para poder pasar a otras cosas.
He encontrado loggly para ser el más conveniente.
Es un servicio alojado que puede no ser lo que quieres. Sin embargo, si visita su página de configuración , puede ver varias formas en que su situación es compatible ( soluciones específicas de la ventana acoplable , así como 10 opciones específicas de Amazon). Incluso si loggly no es de su agrado, puede mirar esas soluciones y ver fácilmente cómo algunas de ellas podrían aplicarse a la mayoría de las soluciones de registro centralizado que pueda usar o escribir.
Puede usar un entorno de Multicontainer, compartiendo la carpeta de registros con otro contenedor de la ventana acoplable con la herramienta de su preferencia para centralizar los registros, en nuestro caso, conectamos un Flujo de Apache para mover los archivos a un HDFS. Espero que esto te ayude con esto.
Tal vez una función de AWS Lambda es aplicable?
Escriba algún javascript que vuelque todas las notificaciones, luego vea qué puede hacer con esas.
Después de escribir un objeto, ¿podría cambiar su nombre dentro del mismo grupo?
¿O notificar a su propio servicio de administración de registro sobre la creación de un nuevo objeto?
Muchas posibilidades allí ...