Descripción del proyecto
TraducidoActualmente estamos esencialmente ciegos a lo que está sucediendo en producción. Los registros están dispersos en una docena de servidores, cada aplicación escribe en sus propios archivos en su propio formato, y cuando algo se rompe, iniciamos sesión a través de SSH y buscamos manualmente a través de gigabytes de texto. Por lo general, nos enteramos de un problema solo después de que un cliente lo informa. Queremos resolver esto adecuadamente: construir una pila de registro y observabilidad centralizada que recopile registros y métricas de cada servidor y servicio en un solo lugar con búsqueda, para que todo el equipo vea la imagen sin iniciar sesión en las máquinas mismas.
La arquitectura objetivo es un clúster ELK o OpenSearch para registros más Grafana para métricas y visualización. Se espera que el contratista implemente recolectores de registros en nuestros hosts, normalice y analice los flujos entrantes en campos estructurados, y diseñe paneles que sean claros tanto para ingenieros como para la gerencia. Además de esto, necesitamos alertas: notificar cuando la tasa de errores aumenta, cuando el retraso de respuesta cruza un umbral, cuando un servicio deja de enviar datos, o cuando se agota el espacio en disco o la memoria. Las alertas deben llegar a los canales que ya usamos, con umbrales apropiados para que no nos ahoguemos en ruido.
El almacenamiento y su costo son importantes para nosotros. Te pedimos que configures el ciclo de vida del índice y la rotación para que los datos frescos se mantengan activos y buscables, y los registros antiguos se muevan a archivo o se eliminen según lo programado. Describe la arquitectura, las reglas de análisis y el procedimiento para conectar un nuevo servicio a la tubería para que nuestro equipo pueda continuar manteniendo y expandiendo el sistema por sí mismos. Si ya has gestionado tal pila en producción, cuéntanos cómo la escalarías para nuestros volúmenes.
— Recolección de registros de servidores Linux y aplicaciones en contenedores
— Análisis estructurado, indexación y política de retención
— Paneles de Grafana para errores, retrasos y recursos
— Alertas para picos de errores, retrasos y servicios silenciosos
La arquitectura objetivo es un clúster ELK o OpenSearch para registros más Grafana para métricas y visualización. Se espera que el contratista implemente recolectores de registros en nuestros hosts, normalice y analice los flujos entrantes en campos estructurados, y diseñe paneles que sean claros tanto para ingenieros como para la gerencia. Además de esto, necesitamos alertas: notificar cuando la tasa de errores aumenta, cuando el retraso de respuesta cruza un umbral, cuando un servicio deja de enviar datos, o cuando se agota el espacio en disco o la memoria. Las alertas deben llegar a los canales que ya usamos, con umbrales apropiados para que no nos ahoguemos en ruido.
El almacenamiento y su costo son importantes para nosotros. Te pedimos que configures el ciclo de vida del índice y la rotación para que los datos frescos se mantengan activos y buscables, y los registros antiguos se muevan a archivo o se eliminen según lo programado. Describe la arquitectura, las reglas de análisis y el procedimiento para conectar un nuevo servicio a la tubería para que nuestro equipo pueda continuar manteniendo y expandiendo el sistema por sí mismos. Si ya has gestionado tal pila en producción, cuéntanos cómo la escalarías para nuestros volúmenes.
— Recolección de registros de servidores Linux y aplicaciones en contenedores
— Análisis estructurado, indexación y política de retención
— Paneles de Grafana para errores, retrasos y recursos
— Alertas para picos de errores, retrasos y servicios silenciosos
Administración Efectivo, Transferencia bancaria
