16 módems, 4 operadores móbiles = Velocidade de saída 933.45 Mbit/s
Introdución
Ola! Este artigo trata sobre como escribimos un novo sistema de seguimento para nós mesmos. Diferénciase dos existentes pola súa capacidade para obter métricas síncronas de alta frecuencia e un consumo de recursos moi baixo. A taxa de sondeo pode alcanzar 0.1 milisegundos cunha precisión de sincronización entre métricas de 10 nanosegundos. Todos os ficheiros binarios ocupan 6 megabytes.
Sobre o proxecto
Temos un produto bastante específico. Producimos unha solución completa para resumir o rendemento e a tolerancia a fallos das canles de transmisión de datos. Isto é cando hai varias canles, digamos Operador1 (40 Mbit/s) + Operador2 (30 Mbit/s) + Outra cousa (5 Mbit/s), o resultado é unha canle estable e rápida, cuxa velocidade será algo así como isto: (40+ 30+5)x0.92=75×0.92=69 Mbit/s.
Tales solucións son demandadas cando a capacidade dunha canle é insuficiente. Por exemplo, transporte, sistemas de videovixilancia e transmisión de vídeo en tempo real, emisión de emisións de televisión e radio en directo, calquera instalación suburbana onde entre os operadores de telecomunicacións só haxa representantes dos Big Four e a velocidade nun módem/canle non sexa suficiente. .
Para cada unha destas áreas, producimos unha liña separada de dispositivos, pero a súa parte de software é case a mesma e un sistema de monitorización de alta calidade é un dos seus módulos principais, sen a correcta implementación do cal o produto non sería posible.
Ao longo de varios anos, conseguimos crear un sistema de vixilancia multinivel, rápido, multiplataforma e lixeiro. Isto é o que queremos compartir coa nosa respectada comunidade.
Declaración de problemas
O sistema de monitorización proporciona métricas de dúas clases fundamentalmente diferentes: métricas en tempo real e todas as demais. O sistema de vixilancia só tiña os seguintes requisitos:
- Adquisición síncrona de alta frecuencia de métricas en tempo real e a súa transferencia desde o sistema de xestión da comunicación sen demoras.
A alta frecuencia e a sincronización de diferentes métricas non só é importante, é vital para analizar a entropía das canles de transmisión de datos. Se nunha canle de transmisión de datos o atraso medio é de 30 milisegundos, entón un erro de sincronización entre as métricas restantes de só un milisegundo levará a unha degradación da velocidade da canle resultante nun 5%. Se erramos o tempo en 1 milisegundo en 4 canles, a degradación da velocidade pode caer facilmente ata o 30%. Ademais, a entropía nas canles cambia moi rapidamente, polo que se a medimos menos dunha vez cada 0.5 milisegundos, nas canles rápidas cun pequeno atraso conseguiremos unha degradación a alta velocidade. Por suposto, tal precisión non é necesaria para todas as métricas e non en todas as condicións. Cando o atraso na canle é de 500 milisegundos e traballamos con tal, entón case non se notará un erro de 1 milisegundo. Ademais, para as métricas do sistema de soporte vital, temos suficientes taxas de votación e sincronización de 2 segundos, pero o propio sistema de seguimento debe poder funcionar con taxas de votación ultra altas e sincronización ultra precisa das métricas. - Consumo mínimo de recursos e unha única pila.
O dispositivo final pode ser un poderoso complexo a bordo que pode analizar a situación na estrada ou realizar gravacións biométricas de persoas, ou un ordenador de placa única do tamaño dunha palma de man que un soldado das forzas especiais leva debaixo da súa armadura corporal para transmitir vídeo. tempo real en malas condicións de comunicación. A pesar de tanta variedade de arquitecturas e potencia de cómputo, gustaríanos ter a mesma pila de software. - Arquitectura paraugas
As métricas deben recollerse e agregarse no dispositivo final, almacenarse localmente e visualizarse en tempo real e de forma retrospectiva. Se hai unha conexión, transfira os datos ao sistema de vixilancia central. Cando non hai conexión, a cola de envío debería acumularse e non consumir memoria RAM. - API para a integración no sistema de monitorización do cliente, porque ninguén precisa de moitos sistemas de monitorización. O cliente debe recoller datos de calquera dispositivo e redes nun único monitor.
Que pasou
Para non sobrecargar a xa impresionante lectura longa, non vou dar exemplos e medidas de todos os sistemas de vixilancia. Isto levará a outro artigo. Só direi que non puidemos atopar un sistema de monitorización que sexa capaz de tomar dúas métricas simultáneamente cun erro de menos de 1 milisegundo e que funcione con igual eficacia tanto na arquitectura ARM con 64 MB de RAM como na arquitectura x86_64 con 32. GB de RAM. Por iso, decidimos escribir o noso, que pode facer todo isto. Aquí tes o que temos:
Resumindo o rendemento de tres canles para diferentes topoloxías de rede
Visualización dalgunhas métricas clave
Arquitectura
Usamos Golang como linguaxe de programación principal, tanto no dispositivo como no centro de datos. Simplificou moito a vida coa súa implementación de multitarefa e a capacidade de obter un ficheiro binario executable ligado estáticamente para cada servizo. Como resultado, aforramos significativamente en recursos, métodos e tráfico para a implantación do servizo nos dispositivos finais, tempo de desenvolvemento e depuración de código.
O sistema está implementado segundo o principio modular clásico e contén varios subsistemas:
- Rexistro de métricas.
Cada métrica é atendida polo seu propio fío e está sincronizada entre as canles. Puidemos acadar unha precisión de sincronización de ata 10 nanosegundos. - Almacenamento de métricas
Eliximos entre escribir o noso propio almacenamento para series cronolóxicas ou usar algo que xa estaba dispoñible. A base de datos é necesaria para os datos retrospectivos que están suxeitos a visualización posterior, é dicir, non contén datos sobre atrasos na canle cada 0.5 milisegundos nin lecturas de erros na rede de transporte, senón que hai velocidade en cada interface cada 500 milisegundos. Ademais dos altos requisitos de multiplataforma e de baixo consumo de recursos, é moi importante para nós poder procesar. os datos é onde se almacenan. Isto aforra enormes recursos informáticos. Levamos empregando o DBMS Tarantool neste proxecto desde 2016 e ata agora non vemos un substituto para el no horizonte. Flexible, cun consumo óptimo de recursos, soporte técnico máis que adecuado. Tarantool tamén implementa un módulo GIS. Por suposto, non é tan poderoso como PostGIS, pero é suficiente para as nosas tarefas de almacenar algunhas métricas relacionadas coa localización (relevantes para o transporte). - Visualización de métricas
Todo é relativamente sinxelo aquí. Tomamos datos do almacén e mostrámolos en tempo real ou retrospectivamente. - Sincronización de datos co sistema central de vixilancia.
O sistema de vixilancia central recibe datos de todos os dispositivos, gárdaos cun historial especificado e envíao ao sistema de seguimento do Cliente a través da API. A diferenza dos sistemas de vixilancia clásicos, nos que a “cabeza” anda e recolle datos, temos o esquema contrario. Os propios dispositivos envían datos cando hai unha conexión. Este é un punto moi importante, xa que permite recibir datos do dispositivo durante aqueles períodos de tempo nos que non estivo dispoñible e non cargar canles e recursos mentres o dispositivo non estea dispoñible. Usamos o servidor de monitorización Influx como sistema de monitorización central. A diferenza dos seus análogos, pode importar datos retrospectivos (é dicir, cunha marca de tempo diferente ao momento en que se recibiu as métricas) As métricas recollidas son visualizadas por Grafana, modificadas cun ficheiro. Tamén se escolleu esta pila estándar porque ten integracións de API preparadas con case calquera sistema de seguimento de clientes. - Sincronización de datos cun sistema central de xestión de dispositivos.
O sistema de xestión de dispositivos implementa Zero Touch Provisioning (actualización de firmware, configuración, etc.) e, a diferenza do sistema de monitorización, só recibe problemas por dispositivo. Estes son disparadores para o funcionamento dos servizos de control de hardware integrados e todas as métricas dos sistemas de soporte vital: temperatura da CPU e SSD, carga da CPU, espazo libre e saúde SMART nos discos. O almacenamento do subsistema tamén está construído en Tarantool. Isto dános unha velocidade significativa á hora de agregar series temporais en miles de dispositivos e tamén resolve por completo o problema de sincronizar datos con estes dispositivos. Tarantool ten un excelente sistema de colas e entrega garantida. Conseguimos esta función tan importante fóra da caixa, xenial!
Sistema de xestión de redes
Que hai a continuación
Ata agora, o noso elo máis débil é o sistema central de vixilancia. Implícase nun 99.9 % nunha pila estándar e ten unha serie de desvantaxes:
- InfluxDB perde datos cando se perde a enerxía. Como regra xeral, o Cliente recolle de inmediato todo o que provén dos dispositivos e a propia base de datos non contén datos de máis de 5 minutos, pero no futuro isto pode converterse nunha dor.
- Grafana ten unha serie de problemas coa agregación de datos e a sincronización da súa visualización. O problema máis común é cando a base de datos contén unha serie temporal cun intervalo de 2 segundos a partir de, por exemplo, 00:00:00, e Grafana comeza a mostrar datos en conxunto a partir de +1 segundo. Como resultado, o usuario ve un gráfico de baile.
- Cantidade excesiva de código para a integración da API con sistemas de monitorización de terceiros. Pódese facer moito máis compacto e, por suposto, reescrito en Go)
Creo que todos vistedes perfectamente o que parece Grafana e coñecedes os seus problemas sen min, así que non vou sobrecargar a publicación con imaxes.
Conclusión
Non describín deliberadamente os detalles técnicos, senón que describín só o deseño básico deste sistema. En primeiro lugar, para describir tecnicamente completamente o sistema, será necesario outro artigo. En segundo lugar, non todos estarán interesados nisto. Escribe nos comentarios que detalles técnicos che gustaría saber.
Se alguén ten dúbidas fóra do alcance deste artigo, pode escribirme a a.rodin @ qedr.com
Fonte: www.habr.com