¿Cuál es una buena práctica de registro para tareas distribuidas?

Tengo la siguiente configuración:

Cree varios trabajadores, haga un cálculo y termínelos después de que se haya realizado el cálculo.

Por lo tanto, cada vez será una instancia diferente que ejecute la tarea, por lo que cada host tendrá su propio archivo de registro, lo que dará como resultado una gran lista de archivos.

¿Es una buena práctica? Si no, ¿cuál sería una mejor manera de registrar el procesamiento de la tarea en este caso de uso en particular?

PD: mi infraestructura no tiene servidor. Entonces, por ahora, estoy iniciando sesión en (AWS) CloudWatch. Pero, responda la pregunta independientemente de AWS y adapte una configuración sin servidor tanto como sea posible.

"Sin servidor" en su mayoría solo significa que tiene microservicios relativamente simples, generalmente solo una pequeña aplicación web o una sola función que se conecta automáticamente a una interfaz REST. Se aplican los mismos conceptos que usaría para servicios web más tradicionales: generalmente una combinación de syslog remoto y escritores ElasticSearch.

El syslog en red o remoto ha existido durante mucho tiempo y tiene un conjunto bastante robusto de herramientas a su alrededor. Tendría que ejecutar los servidores centrales de syslog, pero el protocolo es muy simple y hay bibliotecas de cliente puro en todos los idiomas que puede usar para enviar registros. Un problema común con syslog remoto es que tradicionalmente se ha basado en UDP. Esto significa que bajo una gran carga, algunos mensajes de registro pueden perderse. Esto podría ser algo bueno, ya que ayuda a evitar una sobrecarga en cascada, pero es algo a tener en cuenta. Algunos demonios syslog más nuevos también admiten un protocolo basado en TCP, pero el soporte al cliente está menos unificado, así que solo investigue.

Más reciente pero muy popular es iniciar sesión en ElasticSearch. Esto es principalmente útil debido al tablero de Kibana y Logstash takelit (a menudo llamado ELK, ElasticSearch + Logstash + Kibana). Amazon incluso ofrece una opción alojada de ElasticSearch, lo que hace que sea un poco más fácil comenzar. ES utiliza una API REST relativamente simple, por lo que cualquier lenguaje con un cliente HTTP (léase: todos) debería estar bien al iniciar sesión en ES, pero asegúrese de tener cuidado al bloquear las operaciones de red en casos de interrupciones parciales del sistema (es decir, asegúrese de que su la aplicación no se atascará en una llamada de registro que nunca tendrá éxito y dejará de atender las solicitudes de los usuarios).

Las topologías de registro más complejas están limitadas solo por su imaginación, aunque en estos días verá mucho uso de la base de datos / cola / Kafka como lo desee llamarlo como un punto de conexión en sistemas de distribución de registros muy complejos. .

En el lado "sin servidor", generalmente querrá integrarse con estos sistemas directamente en el nivel de red, por lo que enviar datos de registro directamente a syslog o ES desde su servicio / función, en lugar de escribir en archivos locales (aunque tal vez haga eco en esos también para depuración local y desarrollo).

Esta respuesta es más acerca de las consideraciones de escalabilidad: si el número de trabajadores puede ser alto y / o varios de ellos pueden producir registros a alta velocidad al mismo tiempo.

Sí, usar múltiples archivos de registro simultáneamente es una buena práctica.

Intentar combinar en un solo archivo de registro los registros de varios trabajadores en tiempo real generará problemas:

• El uso de mecanismos de bloqueo para evitar la pérdida de mensajes ralentizará a los trabajadores
• los mensajes de registro pueden aparecer fuera de servicio en el archivo de registro combinado
• una instalación de registro centralizada que combina los registros se puede sobrecargar debido a la velocidad de escritura limitada, los mensajes se perderían

Fragmentar archivos de registro (utilizando múltiples archivos de registro activos al mismo tiempo) es en sí una técnica utilizada por algunos proveedores de alojamiento que ofrecen servicios de registro centralizados escalables y de alto rendimiento. Por ejemplo, al exportar registros a archivos, el Registro StackDriver de Google produce múltiples archivos de registro fragmentados. Desde las entradas de registro en Google Cloud Storage :

Cuando exporta registros a un depósito de Cloud Storage, Stackdriver Logging escribe un conjunto de archivos en el depósito. Los archivos están organizados en jerarquías de directorios por tipo de registro y fecha. El tipo de registro puede ser un nombre simple como syslogo un nombre compuesto como appengine.googleapis.com/request_log. Si estos registros se almacenaron en un depósito denominado my-gcs-bucket, los directorios se nombrarían como en el siguiente ejemplo:

my-gcs-bucket/syslog/YYYY/MM/DD/
my-gcs-bucket/appengine.googleapis.com/request_log/YYYY/MM/DD/

Un único depósito puede contener registros de varios tipos de registro.

Los directorios de hoja ( DD/) contienen varios archivos, cada uno de los cuales contiene las entradas de registro exportadas durante un período de tiempo especificado en el nombre del archivo. Los archivos están fragmentados y sus nombres terminan en un número de fragmento, Sno An(n = 0, 1, 2, ...). Por ejemplo, aquí hay dos archivos que pueden almacenarse dentro de directory my-gcs-bucket/syslog/2015/01/13/:

08:00:00_08:59:59_S0.json
08:00:00_08:59:59_S1.json

Estos dos archivos juntos contienen las syslogentradas de registro para todas las instancias durante la hora que comienza a las 0800 UTC. Para obtener todas las entradas de registro, debe leer todos los fragmentos de cada período de tiempo; en este caso, fragmentos de archivo 0 y 1. El número de fragmentos de archivo escritos puede cambiar para cada período de tiempo dependiendo del volumen de las entradas de registro.

Dichos servicios de registro de alto rendimiento también pueden ofrecer alternativas al registro en archivos, por lo tanto, la administración de archivos de registro se puede evitar por completo si eso es de interés:

• insertando registros directamente en una base de datos. Por ejemplo, Stackdriver Logging puede insertar registros directamente en Google BigQuery
• empujando registros directamente en un motor de procesamiento. Por ejemplo, Stackdriver Logging puede insertar registros en temas de Pub / Sub de Google

Finalmente, si la fusión de archivos de registro en tiempo real no es un requisito, tener varios archivos de registro puede ayudar con la administración de registros sin conexión:

• fácil de diseñar esquemas de copia de seguridad progresiva, compresión, archivo y eliminación final
• Es posible el procesamiento paralelo de múltiples conjuntos de registros (archivos de registro), lo que reduce / evita los efectos de cuello de botella
• no es necesario dividir ni reescribir archivos