Pensamos en crear un sistema de seguimiento en la etapa de formación de equipos de producto. Quedó claro que nuestro negocio, la explotación, no entra en estos equipos. ¿Porqué es eso?
El hecho es que todos nuestros equipos se basan en sistemas de información, microservicios y frentes individuales, por lo que los equipos no ven el estado general de todo el sistema en su conjunto. Por ejemplo, es posible que no sepan cómo una pequeña parte del backend profundo afecta al front-end. Su alcance de interés se limita a los sistemas con los que está integrado su sistema. Si un equipo y su servicio A casi no tienen conexión con el servicio B, entonces dicho servicio es casi invisible para el equipo.
Nuestro equipo, a su vez, trabaja con sistemas que están muy integrados entre sí: hay muchas conexiones entre ellos, esta es una infraestructura muy grande. Y el funcionamiento de la tienda online depende de todos estos sistemas (de los cuales tenemos, por cierto, una enorme cantidad).
Entonces resulta que nuestro departamento no pertenece a ningún equipo, sino que está ubicado un poco a un lado. En toda esta historia, nuestra tarea es comprender de manera integral cómo funcionan los sistemas de información, su funcionalidad, integraciones, software, redes, hardware y cómo todo esto está conectado entre sí.
La plataforma en la que operan nuestras tiendas online tiene el siguiente aspecto:
- frontal o trasero
- oficina central
- back office
Por mucho que nos gustaría, no sucede que todos los sistemas funcionen sin problemas y sin problemas. El punto, nuevamente, es la cantidad de sistemas e integraciones: con algo como el nuestro, algunos incidentes son inevitables, a pesar de la calidad de las pruebas. Además, tanto dentro de un sistema separado como en términos de su integración. Y es necesario controlar de forma exhaustiva el estado de toda la plataforma, y no sólo de una parte individual de ella.
Lo ideal sería automatizar el seguimiento del estado de toda la plataforma. Y llegamos al monitoreo como una parte inevitable de este proceso. Inicialmente, se construyó solo para la parte de primera línea, mientras que los especialistas en redes y los administradores de software y hardware tenían y todavía tienen sus propios sistemas de monitoreo capa por capa. Todas estas personas siguieron el seguimiento sólo a su propio nivel, nadie tenía tampoco una comprensión completa.
Por ejemplo, si una máquina virtual falla, en la mayoría de los casos solo el administrador responsable del hardware y de la máquina virtual lo sabe. En tales casos, el equipo de primera línea vio el hecho mismo de la falla de la aplicación, pero no tenía datos sobre la falla de la máquina virtual. Y el administrador puede saber quién es el cliente y tener una idea aproximada de lo que se está ejecutando actualmente en esta máquina virtual, siempre que se trate de algún tipo de proyecto grande. Lo más probable es que no sepa nada de los más pequeños. En cualquier caso, el administrador debe acudir al propietario y preguntarle qué había en esta máquina, qué se debe restaurar y qué se debe cambiar. Y si algo realmente grave se estropeaba, empezaban a dar vueltas en círculos, porque nadie veía el sistema en su conjunto.
En última instancia, historias tan dispares afectan a todo el frontend, a los usuarios y a nuestra función empresarial principal: las ventas online. Dado que no formamos parte de un equipo, sino que participamos en el funcionamiento de todas las aplicaciones de comercio electrónico como parte de una tienda en línea, asumimos la tarea de crear un sistema de seguimiento integral para la plataforma de comercio electrónico.
Estructura y pila del sistema.
Comenzamos identificando varias capas de monitoreo para nuestros sistemas, dentro de las cuales necesitaríamos recopilar métricas. Y era necesario combinar todo esto, que es lo que hicimos en la primera etapa. Ahora, en esta etapa, estamos finalizando la recopilación de métricas de la más alta calidad en todas nuestras capas para construir una correlación y comprender cómo los sistemas se influyen entre sí.
La falta de un monitoreo integral en las etapas iniciales del lanzamiento de la aplicación (desde que comenzamos a construirla cuando la mayoría de los sistemas estaban en producción) llevó al hecho de que teníamos una deuda técnica significativa para configurar el monitoreo de toda la plataforma. No podíamos permitirnos el lujo de concentrarnos en establecer el monitoreo de un SI y elaborarlo en detalle, ya que el resto de los sistemas permanecerían sin monitoreo por algún tiempo. Para solucionar este problema, identificamos una lista de las métricas más necesarias para evaluar el estado del sistema de información por capa y comenzamos a implementarla.
Por eso, decidieron comerse el elefante en partes.
Nuestro sistema consta de:
- hardware;
- sistema operativo;
- software;
- Partes de la interfaz de usuario en la aplicación de monitoreo;
- métricas comerciales;
- aplicaciones de integración;
- seguridad de información;
- redes;
- equilibrador de tráfico.
En el centro de este sistema está el autocontrol. Para comprender en general el estado de todo el sistema, es necesario saber qué sucede con las aplicaciones en todas estas capas y en todo el conjunto de aplicaciones.
Entonces, sobre la pila.
Utilizamos software de código abierto. En el centro tenemos Zabbix, que utilizamos principalmente como sistema de alerta. Todo el mundo sabe que es ideal para el seguimiento de infraestructuras. ¿Qué quiere decir esto? Exactamente esas métricas de bajo nivel que tiene cada empresa que mantiene su propio centro de datos (y Sportmaster tiene sus propios centros de datos): temperatura del servidor, estado de la memoria, raid, métricas del dispositivo de red.
Hemos integrado Zabbix con Telegram Messenger y Microsoft Teams, que se utilizan activamente en equipos. Zabbix cubre la capa de red real, hardware y algo de software, pero no es una panacea. Enriquecemos estos datos con algunos otros servicios. Por ejemplo, a nivel de hardware, nos conectamos directamente vía API a nuestro sistema de virtualización y recopilamos datos.
Qué otra cosa. Además de Zabbix, utilizamos Prometheus, que nos permite monitorear métricas en una aplicación de entorno dinámico. Es decir, podemos recibir métricas de la aplicación a través de un punto final HTTP y no preocuparnos por qué métricas cargar en él y cuáles no. A partir de estos datos se pueden desarrollar consultas analíticas.
Las fuentes de datos para otras capas, por ejemplo, las métricas comerciales, se dividen en tres componentes.
En primer lugar, se trata de sistemas comerciales externos, Google Analytics, recopilamos métricas de los registros. De ellos obtenemos datos sobre usuarios activos, conversiones y todo lo relacionado con el negocio. En segundo lugar, este es un sistema de monitoreo de UI. Debería describirse con más detalle.
Érase una vez comenzamos con pruebas manuales y crecimos hasta convertirse en pruebas automáticas de funcionalidad e integraciones. A partir de esto hicimos el seguimiento, dejando solo la funcionalidad principal y nos basamos en marcadores que sean lo más estables posible y no cambien con frecuencia con el tiempo.
La nueva estructura de equipo significa que todas las actividades de la aplicación se limitan a los equipos de producto, por lo que dejamos de realizar pruebas puras. En su lugar, hicimos un seguimiento de la interfaz de usuario a partir de las pruebas, escritas en Java, Selenium y Jenkins (utilizado como sistema para iniciar y generar informes).
Tuvimos muchas pruebas, pero al final decidimos ir al camino principal, la métrica de nivel superior. Y si tenemos muchas pruebas específicas, será difícil mantener los datos actualizados. Cada versión posterior dañará significativamente todo el sistema y todo lo que haremos será arreglarlo. Por lo tanto, nos centramos en cosas muy fundamentales que rara vez cambian y solo las monitoreamos.
Finalmente, en tercer lugar, la fuente de datos es un sistema de registro centralizado. Usamos Elastic Stack para los registros y luego podemos incorporar estos datos a nuestro sistema de monitoreo para métricas comerciales. Además de todo esto, tenemos nuestro propio servicio API de monitoreo, escrito en Python, que consulta cualquier servicio a través de API y recopila datos de ellos en Zabbix.
Otro atributo indispensable del seguimiento es la visualización. El nuestro está basado en Grafana. Se destaca entre otros sistemas de visualización porque le permite visualizar métricas de diferentes fuentes de datos en el panel. Podemos recopilar métricas de nivel superior para una tienda en línea, por ejemplo, la cantidad de pedidos realizados en la última hora desde el DBMS, métricas de rendimiento para el sistema operativo en el que se ejecuta esta tienda en línea desde Zabbix y métricas para instancias de esta aplicación. de Prometeo. Y todo esto estará en un solo tablero. Claro y accesible.
Permítanme señalar algo sobre la seguridad: actualmente estamos ultimando el sistema, que luego integraremos con el sistema de monitoreo global. En mi opinión, los principales problemas que enfrenta el comercio electrónico en el campo de la seguridad de la información están relacionados con los bots, los analizadores y la fuerza bruta. Debemos estar atentos a esto, porque todo esto puede afectar críticamente tanto al funcionamiento de nuestras aplicaciones como a nuestra reputación desde el punto de vista empresarial. Y con el stack elegido cubrimos con éxito estas tareas.
Otro punto importante es que Prometheus ensambla la capa de aplicación. Él mismo también está integrado con Zabbix. Y también tenemos sitespeed, un servicio que nos permite ver parámetros como la velocidad de carga de nuestra página, cuellos de botella, renderizado de páginas, carga de scripts, etc., también está integrado por API. Entonces, nuestras métricas se recopilan en Zabbix y, en consecuencia, también alertamos desde allí. Actualmente, todas las alertas se envían a los principales métodos de envío (por ahora es correo electrónico y Telegram, MS Teams también se ha conectado recientemente). Hay planes para actualizar las alertas a un estado tal que los robots inteligentes funcionen como un servicio y proporcionen información de seguimiento a todos los equipos de productos interesados.
Para nosotros, las métricas son importantes no solo para los sistemas de información individuales, sino también las métricas generales para toda la infraestructura que utilizan las aplicaciones: grupos de servidores físicos en los que se ejecutan máquinas virtuales, balanceadores de tráfico, balanceadores de carga de red, la red misma, utilización de canales de comunicación. . Además de métricas para nuestros propios centros de datos (tenemos varios y la infraestructura es bastante grande).
Las ventajas de nuestro sistema de monitoreo son que con su ayuda vemos el estado de salud de todos los sistemas y podemos evaluar su impacto entre sí y en los recursos compartidos. Y, en última instancia, nos permite participar en la planificación de recursos, que también es nuestra responsabilidad. Gestionamos los recursos del servidor: un grupo dentro del comercio electrónico, ponemos en servicio y desmantelamos nuevos equipos, compramos equipos nuevos adicionales, realizamos una auditoría de la utilización de recursos, etc. Cada año, los equipos planifican nuevos proyectos, desarrollan sus sistemas y es importante para nosotros brindarles recursos.
Y con la ayuda de métricas, vemos la tendencia en el consumo de recursos por parte de nuestros sistemas de información. Y en base a ellos podemos planificar algo. A nivel de virtualización, recopilamos datos y vemos información sobre la cantidad de recursos disponibles por centro de datos. Y ya dentro del centro de datos se puede ver el reciclaje, la distribución real y el consumo de recursos. Además, tanto con servidores independientes como con máquinas virtuales y grupos de servidores físicos en los que todas estas máquinas virtuales giran vigorosamente.
Perspectivas
Ahora tenemos listo el núcleo del sistema en su conjunto, pero aún quedan muchas cosas en las que es necesario trabajar. Como mínimo, se trata de una capa de seguridad de la información, pero también es importante para llegar a la red, desarrollar alertas y resolver el problema de correlación. Tenemos muchas capas y sistemas, y en cada capa hay muchas más métricas. Resulta ser una matrioska al grado de una matrioska.
Nuestra tarea es, en última instancia, emitir las alertas correctas. Por ejemplo, si hubo un problema con el hardware, nuevamente, con una máquina virtual, y había una aplicación importante y no se realizó una copia de seguridad del servicio de ninguna manera. Descubrimos que la máquina virtual ha muerto. Luego, las métricas comerciales le alertarán: los usuarios han desaparecido en alguna parte, no hay conversión, la interfaz de usuario en la interfaz no está disponible, el software y los servicios también han muerto.
En esta situación recibiremos spam de alertas, y esto ya no encaja en el formato de un sistema de seguimiento adecuado. Surge la cuestión de la correlación. Por lo tanto, idealmente, nuestro sistema de monitoreo debería decir: "Chicos, su máquina física ha muerto, y con ella esta aplicación y estas métricas", con la ayuda de una alerta, en lugar de bombardearnos furiosamente con cien alertas. Debe informar lo principal: la causa, lo que ayuda a eliminar rápidamente el problema debido a su localización.
Nuestro sistema de notificación y procesamiento de alertas se basa en un servicio de línea directa las XNUMX horas. Allí se envían todas las alertas que se consideran imprescindibles y están incluidas en la lista de verificación. Cada alerta debe tener una descripción: qué pasó, qué significa realmente, qué afecta. Y también un enlace al panel e instrucciones sobre qué hacer en este caso.
Se trata de los requisitos para crear una alerta. Entonces la situación puede desarrollarse en dos direcciones: o hay un problema que debe resolverse, o ha habido una falla en el sistema de monitoreo. Pero en cualquier caso, debes ir y resolverlo.
Actualmente recibimos una media de cien alertas al día, teniendo en cuenta que la correlación de alertas aún no se ha configurado correctamente. Y si necesitamos realizar trabajos técnicos y apagamos algo a la fuerza, su número aumenta significativamente.
Además de monitorear los sistemas que operamos y recopilar métricas que se consideran importantes por nuestra parte, el sistema de monitoreo nos permite recopilar datos para los equipos de productos. Pueden influir en la composición de las métricas dentro de los sistemas de información que monitoreamos.
Nuestro colega puede venir y pedir agregar alguna métrica que será útil tanto para nosotros como para el equipo. O, por ejemplo, es posible que el equipo no tenga suficientes métricas básicas que nosotros tenemos; necesitan realizar un seguimiento de algunas específicas. En Grafana, creamos un espacio para cada equipo y otorgamos derechos de administrador. Además, si un equipo necesita paneles de control, pero ellos mismos no pueden o no saben cómo hacerlo, les ayudamos.
Dado que estamos fuera del flujo de creación de valor del equipo, sus lanzamientos y planificación, gradualmente llegamos a la conclusión de que los lanzamientos de todos los sistemas son fluidos y se pueden implementar diariamente sin coordinación con nosotros. Y es importante para nosotros monitorear estas versiones, porque potencialmente podrían afectar el funcionamiento de la aplicación y romper algo, y esto es crítico. Para gestionar los lanzamientos utilizamos Bamboo, desde donde recibimos datos vía API y podemos ver qué lanzamientos se han lanzado en qué sistemas de información y su estado. Y lo más importante es a qué hora. Superponemos marcadores de lanzamiento sobre las principales métricas críticas, lo que es visualmente muy indicativo en caso de problemas.
De esta manera podemos ver la correlación entre los nuevos lanzamientos y los problemas emergentes. La idea principal es comprender cómo funciona el sistema en todas las capas, localizar rápidamente el problema y solucionarlo con la misma rapidez. Al fin y al cabo, muchas veces sucede que lo que lleva más tiempo no es solucionar el problema, sino buscar la causa.
Y en este ámbito queremos centrarnos en el futuro en la proactividad. Idealmente, me gustaría saber acerca de un problema inminente con anticipación, y no después, para poder prevenirlo en lugar de resolverlo. En ocasiones se producen falsas alarmas del sistema de monitorización, tanto por error humano como por cambios en la aplicación, y trabajamos en ello, lo depuramos e intentamos avisar de ello a los usuarios que lo utilizan con nosotros antes de cualquier manipulación del sistema de monitorización. , o realizar estas actividades en la ventana técnica.
Entonces, el sistema ha sido lanzado y ha estado funcionando con éxito desde principios de primavera... y está mostrando beneficios muy reales. Por supuesto, esta no es su versión final; introduciremos muchas más funciones útiles. Pero ahora mismo, con tantas integraciones y aplicaciones, la automatización del monitoreo es realmente inevitable.
Si también monitoreas proyectos grandes con una cantidad significativa de integraciones, escribe en los comentarios qué solución milagrosa encontraste para esto.
Fuente: habr.com