Los registros de la aplicación revelan información sobre eventos externos e internos que la aplicación ve durante la ejecución. Cuando ocurre un error, hackeo o anomalía durante una implementación, los registros son la evidencia más útil y confiable para analizar las causas del incidente.
Veamos cómo escribir mensajes útiles en el diario que a todos les encantarán.
1. Qué registrar
Mensajes entrantes y salientes
Si los componentes interactúan entre sí mediante mensajes, debe registrar los mensajes entrantes y salientes que indiquen las URL de los puntos finales de la API, parámetros de solicitud, solicitudes de IP iniciales e intermedias, encabezados de solicitud, información sobre el autor, cuerpos de solicitud y respuesta, contexto comercial , marcas de tiempo y pasos de procesamiento interno.
Es muy importante que a cada mensaje se le asigne un identificador único (generalmente generado en el administrador de API o en el nivel de servicio). Esto es necesario para rastrear el intercambio de mensajes entre servicios en el sistema.
Servicios y funciones de llamada
Al llamar a un servicio o función, es conveniente registrar su contexto con más detalle, principalmente para depurar (use TRACE o DEBUG). Estos registros le ayudarán a solucionar problemas de lógica empresarial, especialmente si no tiene el privilegio de adjuntar un depurador a una aplicación (por ejemplo, cuando se implementa en un entorno de prueba, preparación o preproducción).
Acciones de los usuarios y estadísticas comerciales
Cada aplicación tiene escenarios comerciales y trayectos de usuario únicos que brindan mucha información a los profesionales especializados. Por ejemplo, si una determinada transacción tardó demasiado en completarse o si los usuarios están atascados en alguna funcionalidad, todos estos son datos muy importantes desde el punto de vista de la experiencia del usuario. Otra información relacionada con el negocio (el número de transacciones y usuarios activos, así como sus etapas) es importante para encontrar relaciones causales e incluso se puede utilizar en el análisis empresarial.
Operaciones de datos (pista de auditoría)
Por motivos de seguridad y cumplimiento, la mayoría de las aplicaciones empresariales requieren registros de transacciones separados con toda la información importante, como ID de acceso (usuarios y sistemas), instancias de servicio exactas y privilegios de rol utilizados, marcas de tiempo, solicitudes de datos, instantáneas. y el nuevo estado de los datos modificados (diff). La pista de auditoría debe registrar todas las operaciones de datos (acceso, importación, exportación, etc.), así como las operaciones CRUD (crear, leer, actualizar, eliminar) realizadas por los usuarios, otros sistemas y servicios.
Eventos del sistema
Estos incluyen información sobre el comportamiento (arranques, paradas, reinicios y eventos relacionados con la seguridad), modos transitorios (frío, calentamiento, caliente), comunicación entre servicios (reconocimiento, estados de establecimiento de conexión: conectado, desconectado, reconectado, reintentos), identificadores instancias de servicio, API de servicio activo, escucha activa en IP y rangos de puertos, configuraciones cargadas (bootstrap y actualizaciones dinámicas), estado general del servicio y cualquier otra cosa que pueda ayudarlo a comprender el comportamiento del sistema.
Estadísticas de desempeño
La diligencia es una gran característica de los dispositivos informáticos, pero es posible que no funcionen perfectamente. En cualquier momento, puede haber problemas de rendimiento o degradaciones inesperadas repentinas en el servicio (principalmente debido a errores no controlados y datos corruptos). Para determinarlos, siempre se recomienda publicar estadísticas sobre el estado general y el rendimiento del sistema. Puede contener información como contadores de llamadas API (exitosas y fallidas), latencia de la red, duración promedio del viaje de ida y vuelta, consumo de memoria y otra información específica de la aplicación (generalmente determinada por el contexto comercial).
Amenazas y vulnerabilidades
Revelar amenazas y vulnerabilidades mediante aplicaciones y registros en tiempo de ejecución es un arte que cualquier desarrollador de software empresarial debe dominar. Los hacks y los fallos no suelen ocurrir de repente. Muy a menudo, hay señales que nadie nota al principio. Por lo tanto, siempre debe registrar la actividad humana sospechosa (por ejemplo, intentos erróneos de autenticación y verificación con la aplicación de toda la información de bajo nivel, como redes usadas, fuentes de solicitudes, roles de usuario y privilegios), así como el comportamiento del sistema (por ejemplo, un aumento en los picos en los patrones de consumo de recursos, alta carga en servidores web, fallas ocasionales del servicio). Cuando note un evento sospechoso, asegúrese de que los registros contengan toda la información relacionada con él. Perfectamente,para que sea un seguimiento de pila completa con valores de parámetros e información adicional obtenida del contexto de la aplicación.
2. Qué no necesitas registrar
Informacion personal
Casi todas las leyes de privacidad (por ejemplo, GDPR, CCPA) recomiendan explícitamente que los desarrolladores no registren información de identificación personal. Esto incluye nombre, apodos, sexo, fecha de nacimiento, dirección postal, correo electrónico, números de teléfono, número de seguro social y números de tarjetas de crédito.
Nombres de empresas e información de contacto
Asegúrese de no escribir nombres de empresas, información de empleados, clientes, proveedores o información de contacto individual y de la empresa. La revista nunca debe revelar relaciones comerciales y transacciones con terceros. Para rastrear transacciones específicas, use ID de eventos generados por el sistema en lugar de nombres reales y páselos a otros servicios.
Datos financieros (cuentas bancarias, datos de tarjetas bancarias, importes enviados, etc.)
Por ley, todos los datos financieros deben eliminarse o enmascararse por completo. La divulgación de dicha información en revistas puede fácilmente dar lugar a acciones legales graves (hasta e incluida la responsabilidad penal). Evite esto por todos los medios.
Contraseñas, claves y secretos de seguridad, tokens de autenticación
Las credenciales y los tokens de autenticación se consideran información confidencial, por lo que su presencia en los registros ayudará a los atacantes a encontrar fácilmente agujeros en el sistema. Por lo tanto, no permita que estos datos entren en los registros.
Nota: Puede determinar fácilmente qué información ocultar de los registros si agrega un atributo a cada campo que determina el nivel de visibilidad (por ejemplo, mostrar, enmascarar, ocultar, cifrar). Si tiene un mecanismo de este tipo, puede cambiar la visibilidad de los campos simplemente actualizando las propiedades en la configuración. Esta es una buena solución en los casos en los que necesita registrar cierta información del usuario en entornos que no son de combate, especialmente para probar y depurar. O puede escribir analizadores que filtren registros y procesen campos confidenciales de acuerdo con las instrucciones escritas previamente para el entorno.
3. Mejores prácticas
Sepa cuándo usar un nivel particular de registro
El nivel de registro se utiliza para indicar la gravedad de cada elemento del sistema. La mayoría de los marcos de registro tienen estos niveles:
- FATAL : errores muy graves que probablemente provocarán la finalización de la aplicación. Esto generalmente termina con fallas graves.
- ERROR : errores con los que la aplicación aún puede seguir funcionando, pero con el deterioro de determinadas capacidades.
- ADVERTENCIA : eventos menos peligrosos en comparación con los errores. Por lo general, no degradan ni bloquean la aplicación. Pero estos siguen siendo eventos importantes que deben investigarse.
- INFO : pancartas de eventos importantes y mensajes informativos en el comportamiento de la aplicación.
- DEBUG: , . .
- TRACE: , , . .
Linux Syslog también tiene niveles más serios como Emergencia, Alerta, Crítico, Error, Advertencia, Aviso, Informativo y Depuración.
Independientemente de la complejidad y profundidad de cada nivel de registro, debemos configurarlos correctamente en nuestro código para brindar la cantidad óptima de información en cada escenario. Por ejemplo, todos los datos utilizados por los desarrolladores para la depuración y el análisis técnico deben ir a los niveles DEBUG o TRACE, y los banners con datos del sistema deben ir por debajo de INFO.
Usa el inglés
Algunas herramientas y consolas no admiten la salida y el almacenamiento de registros con ciertos caracteres Unicode. Por lo tanto, la localización y otras mejoras pueden resultar difíciles. Cíñete al inglés y utiliza siempre un juego de caracteres ampliamente compatible para escribir mensajes.
2020-11-11 13:52:18 DEBUG App:36 - Loading adapters.. 2020-11-11 13:52:21 DEBUG Adapters:10 - Loading adapter docs/v1 2020-11-11 13:52:22 DEBUG Adapters:16 - Loading adapter mongo/v1 2020-11-11 13:52:26 DEBUG Docs:38 - docs adapter initialized 2020-11-11 13:52:27 DEBUG Mongo:38 - mongo adapter initialized 2020-11-11 13:52:22 DEBUG Adapters:20 - Successfully loaded all
Agregue mensajes amigables para desarrolladores (concisos y significativos)
Si hay muy poco registro, no podremos obtener la información que necesitamos para recrear el contexto de cada evento importante. Y si registra demasiado, degradará el rendimiento: escribir un archivo de registro enorme aumentará la E / S y el consumo de recursos de almacenamiento en disco. Si el sistema de archivos no lo admite, reducirá el rendimiento general del sistema.
Para optimizar los mensajes, necesita una comprensión clara de las expectativas funcionales y no funcionales del sistema y planificar la calidad y cantidad de mensajes deseadas. Cada diario debe ser significativo y apropiado al contexto: siempre escriba brevemente y al grano.
2020-11-11 13:52:27 DEBUG Users:18 - Successfully created new user (RecordID: 5f5a0d594d17e22b848ee570)2020-11-11 13:52:27 ERROR Users:34 - Failed to update DB (E: inactive user, RecordID: 5f5a0d594d17e22b848ee570)
Cree identificadores de referencia, alias y plantillas simplificadas para mensajes largos y de uso frecuente
En lugar de escribir una descripción completa cada vez, intente crear identificadores de referencia o plantillas simplificadas para representar descripciones largas y repetitivas en el registro. Esto reduce el número total y la longitud de los mensajes y también aumenta la flexibilidad para ocultar cierta información. Por ejemplo, en lugar de describir una vulnerabilidad en un registro de texto, es mejor usar un alias o un identificador para que solo los expertos especializados puedan comprender el escenario actual.
2020-11-11 13:52:27 ERROR DB:22 - Failed to write (E:ORA-01017)// ORA-01017 denotes "invalid username/password; logon denied" error message
Use marcas de tiempo correctas
Las marcas de tiempo proporcionan información sobre la secuencia de eventos y son esenciales para la depuración y el análisis. Al fijar el tiempo, se recomienda utilizar los valores más detallados (por ejemplo, a nivel de milisegundos o microsegundos) para facilitar la identificación de eventos adyacentes. Además, asegúrese de que las marcas de tiempo estén al principio del mensaje en el formato aaaa-mm-dd HH: mm: ss. Siempre especifique su zona horaria a menos que esté usando la hora predeterminada del servidor (UTC).
// with default server time (UTC)2020-11-11 13:52:12 INFO XYZ Integration API Manager v2.0.0// with timezone (e.g. PST - Pacific Standard Time)2020-11-11 13:52:12PST INFO XYZ Integration API Manager v2.0.0
Proporcione la fuente o el origen de los datos de registro (para DEBUG, TRACE, ERROR)
Esto es muy útil para identificar claramente la ubicación que condujo al mensaje correspondiente. Algunos marcos de registro le permiten especificar fuentes en el nivel más detallado (hasta el nombre de los archivos con números de línea), pero la mayoría de las veces, es suficiente mencionar solo la clase, función o nombre de archivo.
2020-11-11 13:52:12 INFO app - XYZ Integration API Manager v2.0.0 2020-11-11 13:52:15 INFO app - Loading configurations.. 2020-11-11 13:52:18 INFO app - *** InstanceID APIM_V2_I02 2020-11-11 13:52:18 INFO app — *** BaseURL http://10.244.2.168:3000 2020-11-11 13:52:19 INFO app - *** LogLevel 05 (DEBUG) 2020-11-11 13:52:12 DEBUG App:22 - Initializing Swagger UI.. 2020-11-11 13:52:14 DEBUG App:28 - Generating schemata.. 2020-11-11 13:52:14 DEBUG App:30 - Initializing REST services.. 2020-11-11 13:52:15 DEBUG App:32 - Generating documentation.. 2020-11-11 13:52:18 DEBUG App:36 - Loading adapters.. 2020-11-11 13:52:21 DEBUG Adapters:10 - Loading adapter docs/v1 2020-11-11 13:52:22 DEBUG Adapters:16 - Loading adapter mongo/v1 2020-11-11 13:52:26 DEBUG Docs:38 - docs adapter initialized 2020-11-11 13:52:27 DEBUG Mongo:38 - mongo adapter initialized 2020-11-11 13:52:22 DEBUG Adapters:20 - Successfully loaded all 2020-11-11 13:52:31 INFO app - Started listening...
Cada revista debe ser única dentro del sistema
La mayoría de los novatos cometen el mismo error: copian y pegan un mensaje de muestra en diferentes archivos, recopilando el registro final de las mismas líneas que provienen de diferentes partes del sistema. En este caso, es difícil rastrear la ubicación específica que desencadenó el evento. Si el conjunto de palabras no se puede cambiar, al menos mencione la fuente en el mensaje para que las líneas en el archivo final difieran entre sí. Además, si el registro lo maneja la clase principal, envíe un identificador durante la inicialización y utilícelo para registrar mensajes sobre el comportamiento de las clases secundarias.
2020-11-11 13:52:18 DEBUG App:36 - Loading adapters.. 2020-11-11 13:52:21 DEBUG Adapters:10 - Loading adapter docs/v1 2020-11-11 13:52:22 DEBUG Adapters:16 - Loading adapter mongo/v1 2020-11-11 13:52:26 DEBUG Docs:38 - docs adapter initialized 2020-11-11 13:52:27 DEBUG Mongo:38 - mongo adapter initialized 2020-11-11 13:52:22 DEBUG Adapters:20 - Successfully loaded all
Agregar una identificación rastreada o un token de mensaje al mensaje
Cuando un evento o mensaje llega al sistema, generalmente se le asigna un identificador único. Se puede pasar a otras etapas de procesamiento para rastrear el movimiento de un evento a través del sistema, lo cual es útil para depurar, procesar simultáneamente y operaciones basadas en datos. Idealmente, el sistema debería tener un identificador de evento único dentro de todos los módulos y servicios.
[87d4s-a98d7-9a8742jsd] Request Body: { "request_id": "87d4s-a98d7-9a8742jsd", "app_id": "TX001", "option_val": "IBM", "req_type_id": "0013", "data": {...........} [87d4s-a98d7-9a8742jsd] Sending request to RefData: href="http://10.244.2.168:8280/v1
Hacer coincidir identificadores en los puntos de transición
En ciertos casos, especialmente cuando se transmite un evento de un sistema a otro, los identificadores cambian de acuerdo con la convención adoptada en el otro sistema. En tales puntos de transición, es necesario indicar explícitamente la correspondencia entre el identificador antiguo y el nuevo en un mensaje separado, con la adición del contexto necesario.
[1000508] ***** Incoming request from 10.244.2.168:3000 ***** [1000508] Origin Id: 87d4s-a98d7-9a8742jsd -> System ID: 1000508 [1000508] Transaction successfully added to Rabbit Queue
Especificar identificadores para todas las instancias de servicio
La mayoría de los sistemas empresariales son plataformas informáticas distribuidas en las que hay muchas instancias de los mismos servicios con varias configuraciones de aplicaciones, recursos, versiones y propiedades de red. Se recomienda que asigne identificadores a las instancias y los utilice para la comunicación entre servicios.
2020-11-11 13:52:12 INFO app - XYZ Integration API Manager v2.0.0 2020-11-11 13:52:15 INFO app - Loading configurations.. 2020-11-11 13:52:18 INFO app - *** InstanceID APIM_V2_I02 2020-11-11 13:52:18 INFO app — *** BaseURL http://10.244.2.168:3000 2020-11-11 13:52:19 INFO app - *** LogLevel 05 (DEBUG)
Configurar un nivel de registro activo
El nivel de registro activo debe cambiarse según el entorno de implementación. Para la producción, se recomienda generar registros hasta el nivel INFO. En otros entornos, los registros se generan hasta el nivel DEBUG o TRACE, según el nivel de detalle requerido por los equipos de desarrollo y operaciones.
// Active Log Level = DEBUG2020-11-11 13:52:12 INFO app - XYZ Integration API Manager v2.0.0 2020-11-11 13:52:15 INFO app - Loading configurations.. 2020-11-11 13:52:18 INFO app - *** InstanceID APIM_V2_I02 2020-11-11 13:52:18 INFO app — *** BaseURL http://10.244.2.168:3000 2020-11-11 13:52:19 INFO app - *** LogLevel 05 (DEBUG) 2020-11-11 13:52:12 DEBUG App:22 - Initializing Swagger UI.. 2020-11-11 13:52:14 DEBUG App:28 - Generating schemata.. 2020-11-11 13:52:14 DEBUG App:30 - Initializing REST services.. 2020-11-11 13:52:15 DEBUG App:32 - Generating documentation.. 2020-11-11 13:52:18 DEBUG App:36 - Loading adapters.. 2020-11-11 13:52:21 DEBUG Adapters:10 - Loading adapter docs/v1 2020-11-11 13:52:22 DEBUG Adapters:16 - Loading adapter mongo/v1 2020-11-11 13:52:26 DEBUG Docs:38 - docs adapter initialized 2020-11-11 13:52:27 DEBUG Mongo:38 - mongo adapter initialized 2020-11-11 13:52:22 DEBUG Adapters:20 - Successfully loaded all 2020-11-11 13:52:31 INFO app - Started listening...// Active Log Level = INFO2020-11-11 13:52:12 INFO app - XYZ Integration API Manager v2.0.0 2020-11-11 13:52:15 INFO app - Loading configurations.. 2020-11-11 13:52:18 INFO app - *** InstanceID API_V2_I02 2020-11-11 13:52:18 INFO app — *** BaseURL http://10.244.2.168:3000 2020-11-11 13:52:19 INFO app - *** LogLevel 04 (INFO) 2020-11-11 13:52:31 INFO app - Started listening...
Proporcione un contexto suficiente para errores y bloqueos
Los errores y fallas requieren la investigación más exhaustiva. Para ello, la aplicación debe proporcionar a los expertos en la materia la información que necesitan, así como el contexto tecnológico y empresarial. Por ejemplo, si no se pudo procesar una solicitud o un mensaje, es muy útil registrar el cuerpo de la solicitud fallida además del error.
[1000508] ***** Incoming request from 10.244.2.168:3000 *****[1000508] Origin Id: 87d4s-a98d7-9a8742jsd -> System ID: 1000508[1000508] Failed to validate msg body (E: Uncaught ReferenceError: missing params - option_val)[1000508] Failed Message: { "request_id": "87d4s-a98d7-9a8742jsd", "app_id": "TX001", "req_type_id": "0013", "data": {...........} }
Haga una copia de seguridad de las transacciones de datos con evidencia (¡no asuma!)
Para cada operación de datos, no dé por sentado que se realizó correctamente. Siempre verifique la condición final con evidencia. Por ejemplo, cuando crea, actualiza o elimina un registro en la base de datos, devuelve un contador de los registros modificados y el registro actualizado en sí. Compruebe siempre el resultado o el contador esperado. Otro ejemplo: cuando inserta un registro en una estructura de datos (por ejemplo, en una cola), compruebe si su tamaño ha aumentado. Suponga que su sistema usa operaciones concurrentes, pero la cola no las admite. Entonces puede perder algunos registros, y la única forma de detectar tales errores ocultos en el código es verificar la longitud.
DEBUG BatchWriter:28 - Successfully connected to DB. Trying to insert 24 accounts...DEBUG BatchWriter:35 - Successfully inserted 24 accounts. Total DB rows affected: 24
Encriptar o enmascarar datos confidenciales
Por lo general, la ley requiere que la información confidencial de los usuarios y los sistemas internos esté enmascarada y / o encriptada. Los requisitos reglamentarios pueden variar según la industria y el lugar de trabajo. Descubra todos los matices e implemente los procedimientos correctos en la aplicación. En algunos casos, es posible que deba enviar la estrategia de registro al servicio de seguridad y obtener su aprobación o certificación antes de la puesta en funcionamiento.
[1000508] ***** Incoming request from 10.244.2.168:3000 *****[1000508] Origin Id: 87d4s-a98d7-9a8742jsd -> System ID: 1000508[1000508] Request Body: { ”user_id”:”XXXXXXXXXX”, ”personal_details”:{ ”firstName”:”XXXXXXXXXX”, ”lastName”:”XXXXXXXXXX”, ”DOB”:”XXXXXXXXXX”, ”gender”:”Male”, ”proffessional”:”Software Architect”, ”industry”:”IT”, ”SSN”:”XXXXXXXXXX” }, ”address_history”:[ {”streetAdress”:”Street No 1″,”zipcode”:”XXXXX”,”state”:”CA”}, {”streetAdress”:”Street No 2″,”zipcode”:”XXXXX”,”state”:”NY”}, {”streetAdress”:”Street No 2″,”zipcode”:”XXXXX”,”state”:”AL”} ], ”card_info”:[ {”type”:”amex″,”card_number”:”XXXXXXXXX”,”credit_limit”:”XXXXX”}, {”type”:”visa″,”card_number”:”XXXXXXXXX”,”credit_limit”:”XXXXX”} ] }
Configure el nombre de los archivos de registro, las políticas de rotación, los tamaños de almacenamiento y los procedimientos de respaldo
Si escribe registros en archivos, asegúrese de que estén almacenados en un disco separado que no afecte de ningún modo a la aplicación en ejecución (por ejemplo, puede asignar un volumen en un servidor remoto y adjuntarlo al servidor de aplicaciones). También averigüe la frecuencia del diario y cómo crecen los archivos. Asegúrese de tener una política de rotación de registros con las convenciones de nomenclatura correctas (por ejemplo, agregar una marca de tiempo al nombre al crear) para mantener el tamaño y la cantidad ideales de archivos. También debe tener un mecanismo para hacer copias de seguridad de los registros antiguos en un lugar seguro y un mecanismo para limpiar el almacenamiento con regularidad. Dependiendo de su industria, puede configurar una copia de seguridad programada (generalmente cada pocos meses o años), eliminando todos los archivos anteriores al final del período.
[ec2-user@ip-XXX-XX-X-XXX logs]$ ls .. APIM_V2_I02-2020-11-20_04:38:43.log APIM_V2_I02-2020-11-23_02:05:35.log APIM_V2_I02-2020-11-24_04:38:17.log APIM_V2_I02-2020-11-27_03:28:37.log APIM_V2_I02-2020-11-27_12:06:45.log ...
4.
Una práctica muy común entre los desarrolladores de aplicaciones empresariales es crear un servidor o una ubicación de acceso centralizado para recopilar registros. Por lo general, estos agregadores rastrean los registros no solo de aplicaciones, sino también de dispositivos y sistemas operativos (por ejemplo, Linux Syslog), redes, firewalls, bases de datos, etc. Además, separan los archivos de registro de los servidores de aplicaciones y le permiten almacenar registros en más formatos protegidos, ordenados y eficientes durante más tiempo. En algunas industrias (como banca y finanzas), es necesario almacenar registros en almacenamiento local y central para que los atacantes no puedan tener acceso a ambos lugares y eliminar evidencia de sus actividades al mismo tiempo. Por lo tanto, la redundancia de datos y la discrepancia de datos entre las dos tiendas pueden ayudar a detectar intrusiones.
Escriba analizadores y realice un seguimiento de los registros con prudencia
La capacidad de escribir analizadores y filtros está integrada en la mayoría de las herramientas de supervisión de registros, la denominada integración de gestión de eventos e información de seguridad (SIEM) . Los analizadores ayudan a mantener los registros en formatos más ordenados y la consulta de datos se vuelve mucho más fácil y rápida. Además, los datos debidamente organizados se pueden transferir a sistemas de seguimiento y búsqueda de anomalías para el seguimiento proactivo y la predicción de eventos futuros. Estas herramientas son muy poderosas para graficar datos basados en series de tiempo y en tiempo real.
Configure alertas y notificaciones automáticas para incidentes críticos
Casi todas las herramientas de monitoreo de registros le permiten establecer umbrales específicos para ciertos niveles. Cuando el sistema alcanza estos valores, la herramienta los detecta de antemano, ayuda a registrar datos y notifica a los administradores de sistemas a través de alertas, API de notificaciones push (como la API de registros de auditoría de Slack ), correos electrónicos, etc. También pueden preconfigurarse para iniciar procesos automatizados. como escalado dinámico, copias de seguridad del sistema, distribución de carga, etc. Pero si invierte en software comercial de monitoreo de registros, échele un buen vistazo porque estas herramientas pueden ser excesivas para sistemas de software de tamaño pequeño a mediano.
5. Herramientas recomendadas
Marcos de registro
JavaScript / TypeScript: Log4js / pino
Java: Log4j
Golang: Logrus
Serverless-functions: aws-lambda-powertools-python / Auto-escrito
Explorar, agregar y monitorear registros
Herramientas CLI: menos, vim
Herramientas en la nube: Fluentd, AWS CloudWatch
SIEM herramientas: SolarWinds, Splunk, McAfee ESM, DataDog, IBM QRadar
Otros: ELK Stack (ElasticSearch, Logstash, Kibana, Beats), Loggly