Anthony Evans de StackState escribió esta publicación de blog. Anthony es ingeniero de soluciones en StackState y tecnólogo de toda la vida. Ha pasado los últimos 15 años ayudando a las empresas a mejorar sus capacidades de entrega de software mientras mantiene la confiabilidad, trabajando extensamente para brindar soporte a los clientes en los entornos de SaaS, AI y Gestión de servicios.
Alcanzar el objetivo de ofrecer un gran rendimiento y fiabilidad frente a nuestros entornos de TI en constante cambio y cada vez más autónomos se ve fundamentalmente desafiado por un problema de datos. Claro, hay mucho (registros, métricas y rastreos de APM), pero es extremadamente difícil extraer información procesable cuando hay tantas partes que se mueven rápidamente.
Si ya está utilizando Elastic Observability, conoce la principal ventaja de reunir sus datos de monitoreo en una vista unificada. Cuando agrega StackState sobre la sólida base de datos de Elastic, la enriquece con una vista profunda y en tiempo real de la topología y sus cambios constantes. Esta es la capa contextual que es clave para identificar la causa raíz de la mayoría de los problemas de rendimiento y evitar que ocurran en el futuro. Siga leyendo para ver la magia que sucede cuando Elastic y StackState se unen.
Antes de que las relaciones entre los componentes se volvieran tan complejas, prácticamente se podía identificar un problema en la parte superior de su cabeza. Si su servicio de carrito de compras no funcionaba, podría señalar un conjunto de máquinas en particular, iniciar sesión físicamente en ellas y averiguarlo. Todo se sentó en un solo lugar, por lo que fue simple. Podría crear paneles de control a priori y proporcionarían un gran beneficio en momentos de necesidad.
Hoy en día, sus sistemas cambian continuamente. Si recibe un error o una alerta que de repente dice: "Ya no puedo poner cosas en mi cesta de la compra", puede haber mil razones. Y aunque tiene una gran cantidad de datos, es abrumador en lugar de útil porque (1) se está ahogando en datos y (2) se pierde el contexto para actuar en consecuencia. Se vuelve muy difícil, si no imposible, encontrar manualmente una causa raíz en este entorno súper complejo y en constante cambio. Es por eso que necesita la capacidad de automatizar el análisis de la causa raíz.
La importancia de una topología de viaje en el tiempo para el análisis de la causa raíz
Sin embargo, sin una topología de viaje en el tiempo , el análisis de la causa raíz es muy parecido a buscar una aguja en un pajar. Cuando ocurre un problema, lo que puede hacer es trabajar en un conjunto de hipótesis y comenzar a verificar docenas de registros diferentes de docenas de servicios diferentes. Pero eso es mucho trabajo.
En cambio, un buen lugar para comenzar es preguntando: "¿Qué cambió?". Por ejemplo, el escalador automático de su proveedor de nube puso en marcha una nueva máquina, varios pods de Kubernetes comenzaron a ejecutarse en esa máquina como parte de un conjunto de servicios, y todo eso coincidió con un cambio de configuración en una implementación de Kubernetes. Digamos que toma todos esos datos de cambio y los coloca en Elasticsearch. Elasticsearch ingiere, almacena y analiza todos estos datos a escala. Luego, Elastic Observability pone todos esos datos de monitoreo en una vista unificada. Ahora tiene una poderosa base de datos de observabilidad, pero falta una cosa: necesita saber cómo se relacionan sus datos entre sí.
Captura de pantalla de StackState que muestra cómo las dependencias subyacentes causan el impacto en el espacio de nombres de Kubernetes de la tienda de calcetines, cómo se agrupan las alertas y qué cambios son causas probables
Seguimiento de cambios y dependencias
Ahí es exactamente donde ocurre la magia entre Elastic y StackState. Los cambios registrados en la topología de viaje en el tiempo de StackState hacen que sea trivial ver la correlación entre el cambio causado por el escalador automático y el cambio en la implementación de Kubernetes, y la causalidad entre los dos. Ahora sabe que esta máquina es parte de un clúster de producción de Kubernetes que se ejecuta en una determinada región de la nube. Kubernetes comenzó a ejecutar pods que pertenecen a una sola implementación: es la red alrededor de todas esas cosas.
Suena bien, ¿no? StackState identifica la causa raíz de los problemas inducidos por cambios en entornos altamente dinámicos, y Elastic Observability le brinda todos los detalles relevantes en profundidad. Sin embargo, hay un desafío más: hacer esto generalmente requiere una gran cantidad de datos, especialmente si desea mantener estos datos durante varios años para crear suficiente contexto para que las funciones de Elastic, como el aprendizaje automático, funcionen y produzcan resultados más precisos. Esos datos tienen gravedad y hay mucha física involucrada.
No es necesario copiar los datos de Elastic Observability en StackState
Afortunadamente, hay una solución para eso: StackState puede trabajar con los datos existentes en Elastic sin necesidad de que los copie en StackState. Esto es importante porque Elastic le permite tomar decisiones basadas en conocimientos sobre el almacenamiento de datos al proporcionar el concepto de niveles de datos: un enfoque de almacenamiento híbrido en el que los datos activos se pueden mantener en discos de alto rendimiento y los datos calientes se pueden mantener a un costo más bajo. discos de rendimiento.
Más recientemente, Elastic también le permite ajustar su uso de almacenamiento y computación de datosusando el nivel congelado. Esto significa que puede desacoplar el almacenamiento de la computación y almacenar años de datos sin volverse loco en términos de costos de infraestructura. StackState solo almacenará la topología de viaje en el tiempo y aprovechará los datos de Elastic como si todos fueran parte de la misma plataforma. Las configuraciones de retención de la topología de viaje en el tiempo de StackState también están completamente desacopladas de los datos de observabilidad de Elastic.
Entonces, si un cliente dice, "Tengo algunos exabytes de datos de registro de mis aplicaciones nativas de la nube en Elastic Cloud", entonces lo que StackState dirá es, "Está bien, está bien. Quédese con todo eso ". Porque cuando está investigando un problema, puede usar la topología de viaje en el tiempo de StackState para hacerlo. Además, cuando necesite acceder a las métricas o registros relevantes para investigar más el problema, puede hacerlo a través de StackState analizando los datos que provienen directamente de Elastic.
Pero eso no es todo: StackState puede usar datos existentes en Elasticsearch para extender la topología en StackState. Todo lo que tiene que hacer es dejar que StackState lea los datos topológicos de Elasticsearch y automáticamente creará una topología de viaje en el tiempo. ¡Considere cuánto más valor puede obtener de ritmos como osquery y packetbeat en su clúster de Elasticsearch!
Trabajando uno al lado del otro, los clientes tendrían todos los beneficios y capacidades de la poderosa infraestructura de observabilidad de Elastic con la ventaja adicional de la topología de viaje en el tiempo de StackState que dice: “¡Ding! ¡Timbre! ¡Timbre! ¡Aquí es donde ocurrió tu problema! "
Captura de pantalla de StackState que muestra datos de ElasticSearch en una vista generada automáticamente para una selección de componentes topológicos
Para concluir, aquí es donde ocurre la magia entre Elastic y StackState:
Reunión de la comunidad
Bastante ordenado, ¿verdad? Si desea comprender un poco más sobre cómo StackState puede ayudarlo a identificar rápidamente la causa raíz de los problemas de infraestructura de servicio, únase a nosotros el 23 de septiembre , cuando Anthony Evans, ingeniero de soluciones de StackState, demostrará el producto en vivo y responderá sus preguntas. puede tener.
Linware ⯈
Linware Argentina ⯈