🥇¿Está muerta la monitorización? — Larga vida al seguimiento

Desde 2008, nuestra empresa se dedica principalmente a la gestión de infraestructura y al soporte técnico las 400 horas del día para proyectos web: tenemos más de 15 clientes, lo que representa aproximadamente el 15% del comercio electrónico ruso. Por consiguiente, se soporta una arquitectura muy diversa. Si algo se cae, estamos obligados a arreglarlo en XNUMX minutos. Pero para comprender que ha ocurrido un accidente, es necesario monitorear el proyecto y responder a los incidentes. ¿Como hacer esto?

Creo que existe un problema a la hora de organizar un sistema de seguimiento adecuado. Si no hubiera habido problemas, entonces mi discurso consistiría en una tesis: "Por favor, instale Prometheus + Grafana y los complementos 1, 2, 3". Desafortunadamente, ya no funciona así. Y el principal problema es que todo el mundo sigue creyendo en algo que existía en 2008, en cuanto a componentes de software.

En cuanto a la organización del sistema de seguimiento, me atrevería a decir que... no existen proyectos con un seguimiento competente. Y la situación es tan mala que si algo cae, existe el riesgo de que pase desapercibido; al fin y al cabo, todo el mundo está seguro de que "todo está controlado".
Quizás todo esté siendo monitoreado. ¿Pero cómo?

Todos nos hemos encontrado con una historia como la siguiente: cierto desarrollador, cierto administrador está trabajando, un equipo de desarrollo se acerca a ellos y les dice: "estamos liberados, ahora monitoreemos". ¿Monitorear qué? ¿Cómo funciona?

DE ACUERDO. Monitoreamos a la antigua usanza. Y ya está cambiando, y resulta que monitoreaste el servicio A, que se convirtió en el servicio B, que interactúa con el servicio C. Pero el equipo de desarrollo te dice: “¡Instala el software, debería monitorear todo!”

Entonces, ¿qué ha cambiado? - ¡Todo ha cambiado!

2008 Todo esta bien

Hay un par de desarrolladores, un servidor, un servidor de base de datos. Todo va desde aquí. Tenemos algo de información, instalamos zabbix, Nagios, cactus. Y luego configuramos alertas claras sobre la CPU, el funcionamiento del disco y el espacio en el disco. También realizamos un par de comprobaciones manuales para garantizar que el sitio responda y que los pedidos lleguen a la base de datos. Y eso es todo: estamos más o menos protegidos.

Si comparamos la cantidad de trabajo que hizo el administrador entonces para brindar monitoreo, entonces el 98% fue automático: la persona que hace el monitoreo debe entender cómo instalar Zabbix, cómo configurarlo y configurar alertas. Y el 2% - para controles externos: que el sitio responde y realiza una solicitud a la base de datos, que han llegado nuevos pedidos.

2010 La carga esta creciendo

Estamos empezando a escalar la web, añadiendo un motor de búsqueda. Queremos asegurarnos de que el catálogo de productos contenga todos los productos. Y esa búsqueda de productos funciona. Que la base de datos esté funcionando, que se estén realizando pedidos, que el sitio responda externamente y responda desde dos servidores y que el usuario no sea expulsado del sitio mientras se reequilibra a otro servidor, etc. Hay más entidades.

Además, la entidad asociada a las infraestructuras sigue siendo la más grande en la cabeza del gestor. Todavía tengo la idea en mi cabeza de que la persona que hace el monitoreo es la persona que instalará zabbix y podrá configurarlo.

Pero al mismo tiempo, se trabaja en la realización de controles externos, en la creación de un conjunto de scripts de consulta del indexador de búsqueda, un conjunto de scripts para verificar que la búsqueda cambia durante el proceso de indexación, un conjunto de scripts que verifican que los bienes se transfieren al servicio de entrega, etc etcétera.

Nota: Escribí “un conjunto de guiones” 3 veces. Es decir, el responsable del seguimiento ya no es el que simplemente instala zabbix. Esta es una persona que comienza a codificar. Pero todavía nada ha cambiado en la mentalidad del equipo.

Pero el mundo está cambiando y volviéndose cada vez más complejo. Se añade una capa de virtualización y varios sistemas nuevos. Comienzan a interactuar entre sí. ¿Quién dijo "huele a microservicios"? Pero cada servicio sigue pareciendo un sitio web individualmente. Podemos recurrir a él y comprender que proporciona la información necesaria y funciona por sí solo. Y si eres un administrador constantemente involucrado en un proyecto que lleva 5-7-10 años desarrollándose, este conocimiento se acumula: aparece un nuevo nivel - te diste cuenta, aparece otro nivel - te diste cuenta...

Pero rara vez alguien acompaña un proyecto durante 10 años.

Currículum del monitor

Supongamos que llega a una nueva startup que inmediatamente contrató a 20 desarrolladores, escribió 15 microservicios y usted es un administrador al que le dicen: “Construya CI/CD. Por favor." Ha creado CI/CD y de repente escucha: “Es difícil para nosotros trabajar con producción en un “cubo” sin entender cómo funcionará la aplicación en él. Haznos una caja de arena en el mismo “cubo”.
Haces una caja de arena en este cubo. Inmediatamente le dicen: "Queremos una base de datos en etapa que se actualice todos los días desde producción, para que entendamos que funciona en la base de datos, pero al mismo tiempo no estropee la base de datos de producción".

Vives en todo esto. Quedan 2 semanas para el lanzamiento, te dicen: “Ahora vamos a monitorear todo esto…” Eso es. monitorear la infraestructura del cluster, monitorear la arquitectura de microservicios, monitorear el trabajo con servicios externos...

Y mis compañeros se quitan de la cabeza el esquema habitual y dicen: “¡Bueno, aquí todo está claro! Instale un programa que supervise todo esto”. Sí, sí: Prometheus + Grafana + complementos.
Y añaden: “Tienes dos semanas, asegúrate de que todo esté seguro”.

En muchos proyectos que vemos, se asigna una persona para el seguimiento. Imaginemos que queremos contratar a una persona para que haga seguimiento durante 2 semanas y le redactamos un currículum. ¿Qué habilidades debería tener esta persona, teniendo en cuenta todo lo que hemos dicho hasta ahora?

Debe comprender el seguimiento y las particularidades del funcionamiento de la infraestructura siderúrgica.
Debe comprender los detalles del monitoreo de Kubernetes (y todos quieren ir al "cubo", porque puede abstraerse de todo, esconderse, porque el administrador se ocupará del resto): él mismo, su infraestructura y comprender cómo monitorear las aplicaciones. adentro.
Debe comprender que los servicios se comunican entre sí de maneras especiales y conocer los detalles específicos de cómo interactúan entre sí. Es muy posible ver un proyecto en el que algunos servicios se comunican sincrónicamente, porque no hay otra manera. Por ejemplo, el backend va a través de REST, a través de gRPC al servicio de catálogo, recibe una lista de productos y la devuelve. No puedes esperar aquí. Y con otros servicios funciona de forma asíncrona. Transferir el pedido al servicio de entrega, enviar una carta, etc.
¿Probablemente ya has nadado por todo esto? Y el administrador, que necesita controlar esto, se confundió aún más.
Debe poder planificar y planificar correctamente, a medida que el trabajo sea cada vez mayor.
Por lo tanto, debe crear una estrategia a partir del servicio creado para entender cómo monitorearlo específicamente. Necesita comprender la arquitectura del proyecto y su desarrollo + comprender las tecnologías utilizadas en el desarrollo.

Recordemos un caso absolutamente normal: algunos servicios están en PHP, algunos servicios están en Go, algunos servicios están en JS. De alguna manera trabajan entre sí. De aquí proviene el término "microservicio": hay tantos sistemas individuales que los desarrolladores no pueden entender el proyecto en su conjunto. Una parte del equipo escribe servicios en JS que funcionan por sí solos y no saben cómo funciona el resto del sistema. La otra parte escribe servicios en Python y no interfiere con el funcionamiento de otros servicios; están aislados en su propia área. El tercero es escribir servicios en PHP o algo más.
Todas estas 20 personas están divididas en 15 servicios y solo hay un administrador que debe entender todo esto. ¡Detener! Simplemente dividimos el sistema en 15 microservicios porque 20 personas no pueden entender todo el sistema.

Pero hay que controlarlo de alguna manera...

¿Cuál es el resultado? Como resultado, hay una persona a la que se le ocurre todo lo que todo el equipo de desarrolladores no puede entender y, al mismo tiempo, también debe saber y poder hacer lo que indicamos anteriormente: infraestructura de hardware, infraestructura de Kubernetes, etc.

¿Qué puedo decir? Houston, tenemos problemas.

Monitorear un proyecto de software moderno es un proyecto de software en sí mismo

A partir de la falsa creencia de que la monitorización es un software, desarrollamos la creencia en los milagros. Pero, lamentablemente, los milagros no ocurren. No puedes instalar zabbix y esperar que todo funcione. No tiene sentido instalar Grafana y esperar que todo esté bien. La mayor parte del tiempo se dedicará a organizar comprobaciones del funcionamiento de los servicios y su interacción entre sí, comprobando cómo funcionan los sistemas externos. De hecho, el 90% del tiempo no se dedicará a escribir guiones, sino a desarrollar software. Y debe ser manejado por un equipo que comprenda el trabajo del proyecto.
Si en esta situación una persona es enviada a monitorear, entonces ocurrirá un desastre. Que es lo que pasa en todas partes.

Por ejemplo, existen varios servicios que se comunican entre sí a través de Kafka. Llegó el pedido, enviamos un mensaje sobre el pedido a Kafka. Existe un servicio que escucha información sobre el pedido y envía la mercancía. Existe un servicio que escucha la información sobre el pedido y envía una carta al usuario. Y luego aparecen muchos más servicios y empezamos a confundirnos.

Y si también le da esto al administrador y a los desarrolladores en la etapa en la que queda poco tiempo antes del lanzamiento, la persona deberá comprender todo este protocolo. Aquellos. Un proyecto de esta escala requiere una cantidad significativa de tiempo y esto debe tenerse en cuenta en el desarrollo del sistema.
Pero muy a menudo, especialmente en las startups, vemos cómo el seguimiento se pospone para más adelante. “Ahora haremos una prueba de concepto, la lanzaremos con ella, la dejaremos caer; estamos dispuestos a sacrificarnos. Y luego lo monitorearemos todo”. Cuando (o si) el proyecto comienza a generar ingresos, la empresa quiere agregar aún más funciones, porque ha comenzado a funcionar, por lo que es necesario implementarlo más. Y estás en el punto en el que primero necesitas monitorear todo lo anterior, lo cual no toma el 1% del tiempo, sino mucho más. Y, por cierto, se necesitarán desarrolladores para el seguimiento y es más fácil dejarles trabajar en nuevas funciones. Como resultado, se escriben nuevas funciones, todo se estropea y te encuentras en un punto muerto sin fin.

Entonces, ¿cómo monitorear un proyecto desde el principio y qué hacer si obtiene un proyecto que necesita ser monitoreado, pero no sabe por dónde empezar?

Primero, necesitas planificar.

Digresión lírica: muy a menudo comienzan con el monitoreo de la infraestructura. Por ejemplo, tenemos Kubernetes. Comencemos instalando Prometheus con Grafana, instalando complementos para monitorear el "cubo". No sólo los desarrolladores, sino también los administradores tienen la desafortunada práctica de: "Instalaremos este complemento, pero el complemento probablemente sepa cómo hacerlo". A la gente le gusta empezar con lo simple y directo, en lugar de con las acciones importantes. Y el monitoreo de la infraestructura es fácil.

Primero, decida qué y cómo desea monitorear, y luego seleccione una herramienta, porque otras personas no pueden pensar por usted. ¿Y deberían hacerlo? Otras personas pensaron para sí mismas en un sistema universal, o no pensaron en absoluto cuando se escribió este complemento. Y sólo porque este complemento tenga 5 mil usuarios no significa que sea de alguna utilidad. Quizás te conviertas en el número 5001 simplemente porque antes ya había 5000 personas allí.

Si comienza a monitorear la infraestructura y el backend de su aplicación deja de responder, todos los usuarios perderán la conexión con la aplicación móvil. Aparecerá un error. Se acercarán a ti y te dirán: "La aplicación no funciona, ¿qué estás haciendo aquí?" - “Estamos monitoreando”. — “¡¿Cómo monitoreas si no ves que la aplicación no funciona?!”

Creo que debes comenzar a monitorear exactamente desde el punto de entrada del usuario. Si el usuario no ve que la aplicación funciona, ya está, es un fallo. Y el sistema de seguimiento debería advertir sobre esto primero.
Y sólo entonces podremos controlar la infraestructura. O hacerlo en paralelo. Es más fácil con la infraestructura: aquí finalmente podemos instalar zabbix.
Y ahora necesitas ir a la raíz de la aplicación para comprender dónde no funcionan las cosas.

Mi idea principal es que el seguimiento debe ir en paralelo con el proceso de desarrollo. Si distrae al equipo de monitoreo con otras tareas (creación de CI/CD, sandboxing, reorganización de la infraestructura), el monitoreo comenzará a retrasarse y es posible que nunca se ponga al día con el desarrollo (o tarde o temprano tendrá que detenerlo).

Todo por niveles

Así es como veo la organización de un sistema de seguimiento.

1) Nivel de aplicación:

monitorear la lógica empresarial de la aplicación;
monitorear las métricas de salud de los servicios;
seguimiento de la integración.

2) Nivel de infraestructura:

monitoreo del nivel de orquestación;
monitoreo del software del sistema;
Monitoreo del nivel de hierro.

3) De nuevo el nivel de aplicación, pero como producto de ingeniería:

recopilar y monitorear registros de aplicaciones;
APM;
rastreo.

4) Alerta:

organización de un sistema de alerta;
organización de un sistema de deberes;
organización de una “base de conocimientos” y flujo de trabajo para el procesamiento de incidentes.

Es importante: ¡llegamos a la alerta no después, sino de inmediato! No es necesario iniciar el seguimiento y "de alguna manera más tarde" averiguar quién recibirá las alertas. Al fin y al cabo, cuál es la tarea del seguimiento: comprender en qué parte del sistema algo funciona mal y comunicarlo a las personas adecuadas. Si deja esto para el final, las personas adecuadas sabrán que algo va mal con sólo decir “nada funciona para nosotros”.

Capa de aplicación: supervisión de la lógica empresarial

Aquí estamos hablando de comprobar el hecho mismo de que la aplicación funciona para el usuario.

Este nivel debe realizarse durante la fase de desarrollo. Por ejemplo, tenemos un Prometheus condicional: va al servidor que realiza las comprobaciones, extrae el punto final y el punto final va y comprueba la API.

Cuando a menudo se les pide que supervisen la página de inicio para asegurarse de que el sitio esté funcionando, los programadores brindan un identificador que se puede utilizar cada vez que necesiten asegurarse de que la API esté funcionando. Y los programadores en este momento todavía toman y escriben /api/test/helloworld
¿La única forma de asegurarse de que todo funcione? - ¡No!

Crear tales controles es esencialmente tarea de los desarrolladores. Las pruebas unitarias deben ser escritas por los programadores que escriben el código. Porque si se lo filtra al administrador, "Amigo, aquí hay una lista de protocolos API para las 25 funciones, ¡supervise todo!". - nada saldrá bien.
Si imprime "hola mundo", nadie sabrá nunca que la API debería funcionar y funciona. Cada cambio de API debe dar lugar a un cambio en los controles.
Si ya tiene un problema de este tipo, detenga las funciones y asigne desarrolladores que escriban estos controles, o acepte las pérdidas, acepte que no se verifica nada y fallará.

Consejos técnicos:

Asegúrese de organizar un servidor externo para organizar las comprobaciones; debe asegurarse de que su proyecto sea accesible al mundo exterior.
Organice comprobaciones en todo el protocolo API, no solo en puntos finales individuales.
Cree un punto final de Prometheus con los resultados de la prueba.

Capa de aplicación: monitoreo de métricas de salud

Ahora estamos hablando de métricas de salud externas de los servicios.

Decidimos monitorear todos los "identificadores" de la aplicación mediante controles externos, que llamamos desde un sistema de monitoreo externo. Pero estos son los "identificadores" que el usuario "ve". Queremos estar seguros de que nuestros servicios funcionan. Aquí hay una historia mejor: K8s tiene controles de estado, de modo que al menos el "cubo" puede estar convencido de que el servicio está funcionando. Pero la mitad de los cheques que he visto tienen la misma impresión "hola mundo". Aquellos. Entonces, una vez que lo retira después del despliegue, respondió que todo está bien, eso es todo. Y el servicio, si proporciona su propia API, tiene una gran cantidad de puntos de entrada para esa misma API, que también necesita ser monitoreada, porque queremos saber si funciona. Y ya lo estamos monitoreando por dentro.

Cómo implementar esto correctamente técnicamente: cada servicio expone un punto final sobre su rendimiento actual, y en los gráficos de Grafana (o cualquier otra aplicación) vemos el estado de todos los servicios.

Cada cambio de API debe dar lugar a un cambio en los controles.
Cree un nuevo servicio de inmediato con métricas de salud.
Un administrador puede acudir a los desarrolladores y pedirles "agreguenme un par de funciones para que entienda todo y agregue información sobre esto a mi sistema de monitoreo". Pero los desarrolladores suelen responder: "No agregaremos nada dos semanas antes del lanzamiento".
Hágales saber a los gerentes de desarrollo que habrá tales pérdidas, infórmeselo también a la gerencia de los gerentes de desarrollo. Porque cuando todo caiga, alguien seguirá llamando y exigiendo monitorear el “servicio en constante caída” (c)
Por cierto, asigne desarrolladores para que escriban complementos para Grafana; esto será de gran ayuda para los administradores.

Capa de aplicación: supervisión de la integración

El monitoreo de integración se enfoca en monitorear las comunicaciones entre sistemas críticos para el negocio.

Por ejemplo, hay 15 servicios que se comunican entre sí. Estos ya no son sitios separados. Aquellos. No podemos ejecutar el servicio por sí solo, obtener /helloworld y entender que el servicio se está ejecutando. Debido a que el servicio web de pedidos debe enviar información sobre el pedido al autobús, desde el autobús, el servicio de almacén debe recibir este mensaje y seguir trabajando con él. Y el servicio de distribución de correo electrónico debe procesar esto de alguna manera más, etc.

Por lo tanto, examinando cada servicio individualmente, no podemos entender que todo funcione. Porque tenemos un determinado bus a través del cual todo se comunica e interactúa.
Por lo tanto, esta etapa debería marcar la etapa de prueba de la interacción de los servicios con otros servicios. Es imposible organizar el seguimiento de la comunicación mediante el seguimiento del intermediario de mensajes. Si hay un servicio que emite datos y un servicio que los recibe, al monitorear al broker solo veremos datos que vuelan de un lado a otro. Incluso si de alguna manera logramos monitorear la interacción de estos datos internamente (que un determinado productor publica los datos, alguien los lee, este flujo continúa yendo a Kafka), esto aún no nos dará información si un servicio envió el mensaje en una versión. , pero el otro servicio no esperaba esta versión y la omitió. No lo sabremos, ya que los servicios nos dirán que todo está funcionando.

Lo que recomiendo hacer:

Para comunicación síncrona: el punto final realiza solicitudes a servicios relacionados. Aquellos. Tomamos este punto final, extraemos un script dentro del servicio, que va a todos los puntos y dice "Puedo tirar allí, y tirar allí, puedo tirar allí..."
Para comunicación asincrónica: mensajes entrantes: el punto final verifica el bus en busca de mensajes de prueba y muestra el estado de procesamiento.
Para comunicación asincrónica: mensajes salientes: el punto final envía mensajes de prueba al bus.

Como suele pasar: tenemos un servicio que arroja datos al bus. Llegamos a este servicio y le pedimos que nos informe sobre su salud de integración. Y si el servicio necesita generar un mensaje en algún lugar más lejano (aplicación web), generará este mensaje de prueba. Y si ejecutamos un servicio en el lado de OrderProcessing, primero publica lo que puede publicar de forma independiente, y si hay algunas cosas dependientes, luego lee un conjunto de mensajes de prueba del bus, comprende que puede procesarlos, lo informa y , si es necesario, publíquelos más, y sobre esto dice: todo está bien, estoy vivo.

Muy a menudo escuchamos la pregunta "¿cómo podemos probar esto con datos de combate?" Por ejemplo, estamos hablando del mismo servicio de pedidos. El pedido envía mensajes al almacén donde se dan de baja las mercancías: no podemos probar esto con datos de combate, porque "¡mis mercancías serán dadas de baja!". Solución: planifique toda esta prueba desde el principio. También tienes pruebas unitarias que hacen simulacros. Entonces, hazlo a un nivel más profundo donde tengas un canal de comunicación que no perjudique el funcionamiento del negocio.

Capa de infraestructura

El monitoreo de infraestructura es algo que durante mucho tiempo se ha considerado como monitoreo en sí mismo.

El monitoreo de la infraestructura puede y debe iniciarse como un proceso separado.
No deberías comenzar con el monitoreo de la infraestructura de un proyecto en ejecución, incluso si realmente lo deseas. Esto es una molestia para todos los devops. "Primero monitorearé el clúster, monitorearé la infraestructura", es decir. En primer lugar, controlará lo que hay debajo, pero no entrará en la aplicación. Porque la aplicación es algo incomprensible para los devops. Se le filtró y no entiende cómo funciona. Pero él entiende la infraestructura y comienza con ella. Pero no, siempre es necesario supervisar primero la aplicación.
No te excedas con la cantidad de alertas. Teniendo en cuenta la complejidad de los sistemas modernos, las alertas circulan constantemente y de alguna manera hay que vivir con este montón de alertas. Y la persona de guardia, después de haber visto cien de las siguientes alertas, decidirá: "No quiero pensar en eso". Las alertas sólo deben notificar sobre cosas críticas.

Nivel de aplicación como unidad de negocio

Puntos clave:

ALCE. Este es el estándar de la industria. Si por alguna razón no agrega registros, comience a hacerlo de inmediato.
AM. APM externos como forma de cerrar rápidamente la monitorización de aplicaciones (NewRelic, BlackFire, Datadog). Puedes instalar esto temporalmente para al menos entender de alguna manera lo que te está pasando.
Rastreo. En docenas de microservicios, hay que rastrear todo, porque la solicitud ya no vive por sí sola. Es muy difícil agregarlo más adelante, por lo que es mejor programar inmediatamente el seguimiento en el desarrollo; este es el trabajo y la utilidad de los desarrolladores. Si aún no lo has implementado, ¡impleméntalo! Ver Jaeger/Zipkin

alertando

Organización de un sistema de notificaciones: en condiciones de monitorear muchas cosas, debería haber un sistema unificado para enviar notificaciones. Puedes hacerlo en Grafana. En Occidente, todo el mundo utiliza PagerDuty. Las alertas deben ser claras (por ejemplo, de dónde proceden...). Y es recomendable controlar que se reciban notificaciones en todo momento.
Organización de un sistema de turnos: las alertas no deben enviarse a todo el mundo (o todos reaccionarán entre la multitud o nadie reaccionará). Los desarrolladores también deben estar de guardia: asegúrese de definir áreas de responsabilidad, dar instrucciones claras y escribir en ellas a quién llamar exactamente los lunes y miércoles, y a quién llamar los martes y viernes (de lo contrario, no llamarán a nadie ni siquiera en el En caso de un gran problema, tendrán miedo de despertarte o molestarte: a la gente generalmente no le gusta llamar y despertar a otras personas, especialmente de noche). Y explique que pedir ayuda no es un indicador de incompetencia (“Pido ayuda, eso significa que soy un mal trabajador”), fomente las solicitudes de ayuda.
Organización de una “base de conocimientos” y flujo de trabajo para el procesamiento de incidentes: para cada incidente grave se debe planificar una autopsia y, como medida temporal, se deben registrar las acciones que resolverán el incidente. Y que sea una práctica que las alertas repetidas sean pecado; deben arreglarse en código o trabajo de infraestructura.

Pila de tecnología

Imaginemos que nuestra pila es la siguiente:

recopilación de datos - Prometeo + Grafana;
análisis de registros - ELK;
para APM o Tracing - Jaeger (Zipkin).

La elección de opciones no es crítica. Porque si al principio entendiste cómo monitorear el sistema y escribiste un plan, entonces comienzas a elegir herramientas que se adapten a tus necesidades. La pregunta es qué eligió monitorear en primer lugar. Porque quizás la herramienta que elegiste al principio no se adapta en absoluto a tus necesidades.

Algunos puntos técnicos que veo en todas partes últimamente:

Prometheus está siendo empujado dentro de Kubernetes: ¿a quién se le ocurrió esto? Si su clúster falla, ¿qué hará? Si tiene un clúster complejo en su interior, entonces debería haber algún tipo de sistema de monitoreo dentro del clúster y otro en el exterior, que recopilará datos desde el interior del clúster.

Dentro del clúster recopilamos registros y todo lo demás. Pero el sistema de seguimiento debe estar fuera. Muy a menudo, en un clúster donde Promtheus está instalado internamente, también hay sistemas que realizan comprobaciones externas del funcionamiento del sitio. ¿Qué pasa si tus conexiones con el mundo exterior se han caído y la aplicación no funciona? Resulta que por dentro todo está bien, pero no facilita las cosas a los usuarios.

Hallazgos

Monitorear el desarrollo no es la instalación de utilidades, sino el desarrollo de un producto de software. El 98% del seguimiento actual consiste en codificación. Codificar servicios, codificar verificaciones externas, verificar servicios externos y eso es todo.
No hagas perder el tiempo a tus desarrolladores monitoreando: puede llevar hasta el 30% de su trabajo, pero vale la pena.
Devops, no se preocupen por no poder monitorear algo, porque algunas cosas son una forma de pensar completamente diferente. No eras programador y monitorear el trabajo es exactamente su trabajo.
Si el proyecto ya está en ejecución y no está monitoreado (y usted es administrador), asigne recursos para el monitoreo.
Si el producto ya está en producción y usted es un desarrollador a quien le dijeron que "configurara el monitoreo", intente explicarle a la gerencia sobre qué escribí todo esto.

Esta es una versión ampliada del informe de la conferencia Saint Highload++.

Si está interesado en mis ideas y pensamientos al respecto y temas relacionados, aquí puede leer el canal 🙂

Fuente: habr.com

¿Está muerta la monitorización? — Monitoreo de larga vida