Monitoreo de petabytes de logs por día en eBay con Beats
Con 1.2 petabytes de logs por día y 5 millones de puntos de datos de métricas entrando por segundo, eBay no tiene escasez de datos que rastrear. El equipo de logging y monitoreo de la empresa de comercio electrónico se enfrenta cada día a la tarea titánica de recopilar y visualizar todos estos logs y métricas. Y al igual que la mayoría de las empresas, usa diversas aplicaciones (como Hadoop y MySQL) para impulsar distintos casos de uso en todos los equipos.
Cuando los contenedores irrumpieron en la escena para brindar una forma nueva de desplegar aplicaciones, el equipo comenzó a usar contenedores con Docker y a usar Kubernetes en la administración del ciclo de vida para el despliegue. Sin embargo, uno de los principales desafíos a los que se enfrentaron fue que las apps y el entorno evolucionan constantemente (y es difícil seguirles el ritmo). Entra en escena Beats. Fue fácil elegir Filebeat y Metricbeat para recopilar y enviar los logs y las métricas desde Docker y Kubernetes.
También querían poder descubrir las cargas de trabajo a medida que se creaban. Previo a la existencia de la funcionalidad de detección automática en Beats (nueva en la versión 6.2), crearon una propia: Collectbeat. Basado en libbeat, su Beat descubría pods nuevos en clusters de Kubernetes. Collectbeat usaba la API de Kubernetes para descubrir cargas de trabajo, recopilar y enriquecer los datos, y luego enviarlos al sistema de monitoreo interno. Este sistema, denominado Sherlock.io, se creó de forma tal que fuera flexible y se amoldara a la adopción de tecnologías nuevas.
Si bien el aspecto de la recopilación ahora estaba resuelto, aún era necesario centrar la atención en la analítica y la visualización. Recopilar todos los datos solo es útil si los usuarios de eBay pueden analizarlos con etiquetas conocidas. El siguiente paso lógico era identificar una forma de etiquetar los datos con metadatos antes de que se enviaran. Entonces, Vijay Samuel y su equipo de eBay crearon un procesador denominado “add_kubernetes_metadata” que toma los mensajes de logs y las cargas de métricas, y adjunta metadatos como nombre y espacio en pod. Este procesador ahora se encuentra disponible en GitHub; y es un excelente ejemplo de por qué los proyectos open source impulsados por la comunidad son tan poderosos.
Por supuesto, eBay sigue evolucionando. La adopción de nuevas tecnologías trae aparejada más aplicaciones, más logs y más métricas. De hecho, su crecimiento orgánico de logging es del 50 % interanualmente. ¿Cómo lidian con el número creciente de datos si los recursos son limitados? Una táctica es medir las aplicaciones a nivel del host/grupo creando límites de retención y cuotas basados en niveles. Otra es dar prioridad a tipos específicos de datos. Los eventos son la prioridad más alta, las métricas que muestran la visibilidad operativa están en segundo lugar, y los logs siguen después. Para asegurarse de que la prioridad sea la adecuada, agregaron programadores de eventos y permiten la detección automática para agregar peso a las configuraciones.
¿Estás listo para descubrir más sobre las herramientas y estrategias de su equipo? Mira la presentación de Vijay de Elastic{ON} 2018 para obtener más información sobre Sherlock.io y sobre cómo usan Beats para monitorear todos los datos en sus clusters de Kubernetes. Si deseas saber más sobre cómo puede usarse el Elastic Stack para monitorear Kubernetes y Docker, echa un vistazo a nuestro seminario web Elastic Stack: Monitoreo de aplicaciones de Kubernetes con Beats.
