16 módems, 4 operadores celulares = Velocidad de salida 933.45 Mbit/s
introducción
¡Hola! Este artículo trata sobre cómo escribimos un nuevo sistema de monitoreo para nosotros mismos. Se diferencia de los existentes por su capacidad para obtener métricas síncronas de alta frecuencia y un consumo de recursos muy bajo. La tasa de sondeo puede alcanzar los 0.1 milisegundos con una precisión de sincronización entre métricas de 10 nanosegundos. Todos los archivos binarios ocupan 6 megabytes.
Sobre el proyecto
Tenemos un producto bastante específico. Producimos una solución integral para resumir el rendimiento y la tolerancia a fallas de los canales de transmisión de datos. Esto es cuando hay varios canales, digamos Operador1 (40Mbit/s) + Operador2 (30Mbit/s)+ Algo más (5 Mbit/s), el resultado es un canal estable y rápido, cuya velocidad será algo así como esto: (40+ 30+5)x0.92=75×0.92=69 Mbit/s.
Este tipo de soluciones tienen demanda cuando la capacidad de cualquier canal es insuficiente. Por ejemplo, transporte, sistemas de videovigilancia y transmisión de vídeo en tiempo real, retransmisiones en directo de televisión y radio, cualquier instalación suburbana donde entre los operadores de telecomunicaciones solo haya representantes de los Cuatro Grandes y la velocidad en un módem/canal no sea suficiente. .
Para cada una de estas áreas, producimos una línea separada de dispositivos, pero su parte de software es casi la misma y un sistema de monitoreo de alta calidad es uno de sus módulos principales, sin cuya correcta implementación el producto no sería posible.
A lo largo de varios años, logramos crear un sistema de monitoreo multinivel, rápido, multiplataforma y liviano. Esto es lo que queremos compartir con nuestra respetada comunidad.
Formulación del problema
El sistema de seguimiento proporciona métricas de dos clases fundamentalmente diferentes: métricas en tiempo real y todas las demás. El sistema de seguimiento tenía únicamente los siguientes requisitos:
- Adquisición síncrona de alta frecuencia de métricas en tiempo real y su transferencia al sistema de gestión de comunicaciones sin demora.
La alta frecuencia y la sincronización de diferentes métricas no sólo son importantes, sino que también son vitales para analizar la entropía de los canales de transmisión de datos. Si en un canal de transmisión de datos el retraso promedio es de 30 milisegundos, entonces un error en la sincronización entre las métricas restantes de solo un milisegundo conducirá a una degradación de la velocidad del canal resultante en aproximadamente un 5%. Si calculamos mal el tiempo en 1 milisegundo en 4 canales, la degradación de la velocidad puede caer fácilmente al 30%. Además, la entropía en los canales cambia muy rápidamente, por lo que si la medimos menos de una vez cada 0.5 milisegundos, en canales rápidos con un pequeño retraso obtendremos una degradación de alta velocidad. Por supuesto, tal precisión no es necesaria para todas las métricas ni en todas las condiciones. Cuando el retraso en el canal es de 500 milisegundos y trabajamos con eso, entonces un error de 1 milisegundo casi no se notará. Además, para las métricas del sistema de soporte vital, tenemos suficientes tasas de sondeo y sincronización de 2 segundos, pero el sistema de monitoreo en sí debe poder funcionar con tasas de sondeo ultra altas y una sincronización de métricas ultraprecisa. - Consumo mínimo de recursos y una sola pila.
El dispositivo final puede ser un potente complejo de a bordo que puede analizar la situación en la carretera o realizar registros biométricos de personas, o una computadora de placa única del tamaño de la palma de la mano que un soldado de las fuerzas especiales lleva debajo de su chaleco antibalas para transmitir vídeo en tiempo real en malas condiciones de comunicación. A pesar de tanta variedad de arquitecturas y potencia informática, nos gustaría tener la misma pila de software. - Arquitectura paraguas
Las métricas deben recopilarse y agregarse en el dispositivo final, almacenarse localmente y visualizarse en tiempo real y de forma retrospectiva. Si hay una conexión, transfiera datos al sistema de monitoreo central. Cuando no hay conexión, la cola de envío debe acumularse y no consumir RAM. - API para integración en el sistema de seguimiento del cliente, porque nadie necesita muchos sistemas de seguimiento. El cliente debe recopilar datos de cualquier dispositivo y red en un solo monitoreo.
Qué pasó
Para no sobrecargar la ya impresionante lectura larga, no daré ejemplos ni mediciones de todos los sistemas de seguimiento. Esto conducirá a otro artículo. Solo diré que no pudimos encontrar un sistema de monitoreo que sea capaz de tomar dos métricas simultáneamente con un error de menos de 1 milisegundo y que funcione con la misma eficacia tanto en arquitectura ARM con 64 MB de RAM como en arquitectura x86_64 con 32 GB de RAM. Por lo tanto, decidimos escribir el nuestro, que puede hacer todo esto. Esto es lo que tenemos:
Resumiendo el rendimiento de tres canales para diferentes topologías de red
Visualización de algunas métricas clave.
Arquitectura
Utilizamos Golang como lenguaje de programación principal, tanto en el dispositivo como en el centro de datos. Simplificó enormemente la vida con su implementación de multitarea y la capacidad de obtener un archivo binario ejecutable vinculado estáticamente para cada servicio. Como resultado, ahorramos significativamente en recursos, métodos y tráfico para implementar el servicio en dispositivos finales, tiempo de desarrollo y depuración de código.
El sistema se implementa según el principio modular clásico y contiene varios subsistemas:
- Registro de métricas.
Cada métrica es atendida por su propio hilo y sincronizada entre canales. Pudimos lograr una precisión de sincronización de hasta 10 nanosegundos. - Almacenamiento de métricas
Estábamos eligiendo entre escribir nuestro propio almacenamiento para series temporales o usar algo que ya estaba disponible. La base de datos es necesaria para datos retrospectivos que están sujetos a visualización posterior, es decir, no contiene datos sobre retrasos en el canal cada 0.5 milisegundos ni lecturas de errores en la red de transporte, pero hay velocidad en cada interfaz cada 500 milisegundos. Además de los altos requisitos de multiplataforma y el bajo consumo de recursos, para nosotros es muy importante poder procesar. los datos es donde se almacenan. Esto ahorra enormes recursos informáticos. Hemos estado utilizando Tarantool DBMS en este proyecto desde 2016 y hasta ahora no vemos un reemplazo en el horizonte. Flexible, con óptimo consumo de recursos, soporte técnico más que adecuado. Tarantool también implementa un módulo GIS. Por supuesto, no es tan poderoso como PostGIS, pero es suficiente para nuestras tareas de almacenar algunas métricas relacionadas con la ubicación (relevantes para el transporte). - Visualización de métricas
Aquí todo es relativamente sencillo. Tomamos datos del almacén y los mostramos en tiempo real o retrospectivamente. - Sincronización de datos con el sistema central de seguimiento.
El sistema de monitoreo central recibe datos de todos los dispositivos, los almacena con un historial específico y los envía al sistema de monitoreo del Cliente a través de API. A diferencia de los sistemas de seguimiento clásicos, en los que la “cabeza” se pasea y recoge datos, tenemos el esquema opuesto. Los propios dispositivos envían datos cuando hay una conexión. Este es un punto muy importante, ya que permite recibir datos del dispositivo durante aquellos periodos de tiempo durante los cuales no estuvo disponible y no cargar canales y recursos mientras el dispositivo no esté disponible. Utilizamos el servidor de monitoreo Influx como sistema de monitoreo central. A diferencia de sus análogos, puede importar datos retrospectivos (es decir, con una marca de tiempo diferente al momento en que se recibieron las métricas), y las métricas recopiladas son visualizadas por Grafana y modificadas con un archivo. También se eligió esta pila estándar porque tiene integraciones API listas para usar con casi cualquier sistema de monitoreo de clientes. - Sincronización de datos con un sistema central de gestión de dispositivos.
El sistema de gestión de dispositivos implementa Zero Touch Provisioning (actualización de firmware, configuración, etc.) y, a diferencia del sistema de monitoreo, recibe solo problemas por dispositivo. Estos son desencadenantes del funcionamiento de los servicios de vigilancia de hardware integrados y de todas las métricas de los sistemas de soporte vital: temperatura de CPU y SSD, carga de CPU, espacio libre y estado SMART en los discos. El subsistema de almacenamiento también se basa en Tarantool. Esto nos brinda una velocidad significativa para agregar series temporales en miles de dispositivos y también resuelve por completo el problema de sincronizar datos con estos dispositivos. Tarantool tiene un excelente sistema de colas y entrega garantizada. Tenemos esta característica importante lista para usar, ¡genial!
Sistema de gestión de red.
¿Qué sigue
Hasta ahora, nuestro eslabón más débil es el sistema central de seguimiento. Se implementa al 99.9% en una pila estándar y tiene una serie de desventajas:
- InfluxDB pierde datos cuando se corta la energía. Como regla general, el Cliente recopila rápidamente todo lo que proviene de los dispositivos y la base de datos en sí no contiene datos de más de 5 minutos, pero en el futuro esto puede convertirse en una molestia.
- Grafana tiene varios problemas con la agregación de datos y la sincronización de su visualización. El problema más común es cuando la base de datos contiene una serie de tiempo con un intervalo de 2 segundos a partir de, digamos, 00:00:00, y Grafana comienza a mostrar datos agregados desde +1 segundo. Como resultado, el usuario ve un gráfico danzante.
- Cantidad excesiva de código para la integración de API con sistemas de monitoreo de terceros. Se puede hacer mucho más compacto y, por supuesto, reescribirlo en Go)
Creo que todos habéis visto perfectamente cómo luce Grafana y conocéis sus problemas sin mí, así que no sobrecargaré el post con fotografías.
Conclusión
Deliberadamente no describí los detalles técnicos, sino que solo describí el diseño básico de este sistema. En primer lugar, para describir técnicamente completamente el sistema, será necesario otro artículo. En segundo lugar, no a todo el mundo le interesará. Escribe en los comentarios qué detalles técnicos te gustaría saber.
Si alguien tiene preguntas más allá del alcance de este artículo, puede escribirme a [email protected]
Fuente: habr.com