Soma de velocidade em 16 modems de 4 operadoras de celular. Velocidade de saída em um fluxo - 933,45 Mbps
1. Introdução
Oi Este artigo é sobre como escrevemos um novo sistema de monitoramento para nós mesmos. Difere das existentes pela possibilidade de aquisição síncrona de alta frequência de métricas e consumo de recursos muito baixo. A frequência de pesquisa pode atingir 0,1 milissegundos com uma precisão de sincronização entre métricas de 10 nanossegundos. Todos os arquivos binários ocupam 6 megabytes.
Sobre o projeto
Temos um produto bastante específico. Produzimos uma solução abrangente para resumir a taxa de transferência e a tolerância a falhas dos canais de dados. É quando existem vários canais, por exemplo, Operador1 (40Mbit / s) + Operador2 (30Mbit / s) + Outra coisa (5Mbit / s), o resultado é um canal estável e rápido, cuja velocidade será mais ou menos assim: (40+ 30 + 5) x0,92 = 75x0,92 = 69 Mbps.
Essas soluções são procuradas onde a capacidade de qualquer canal é insuficiente. Por exemplo, transporte, vigilância por vídeo em tempo real e sistemas de transmissão de vídeo, transmissões de televisão e rádio ao vivo, quaisquer objetos fora da cidade em que as operadoras de telecomunicações tenham apenas representantes dos Big Four, e a velocidade em um modem / canal não é suficiente.
Para cada uma dessas áreas, produzimos uma linha separada de dispositivos, no entanto, sua parte de software é quase a mesma e um sistema de monitoramento de alta qualidade é um de seus principais módulos, sem a implementação correta da qual o produto seria impossível.
Por vários anos, conseguimos criar um sistema de monitoramento rápido, multiplataforma e leve em vários níveis. O que queremos compartilhar com uma comunidade respeitável.
Declaração do problema
O sistema de monitoramento fornece métricas para duas classes fundamentalmente diferentes: métricas em tempo real e todo o resto. O sistema de monitoramento tinha os seguintes requisitos:
- Aquisição síncrona de alta frequência de métricas em tempo real e sua transferência para o sistema de controle de comunicação sem demora.
A alta frequência e sincronização de diferentes métricas não é apenas importante, é vital para a análise da entropia dos canais de transmissão de dados. Se houver um atraso médio de 30 milissegundos em um canal de dados, um erro na sincronização entre as métricas restantes em apenas um milissegundo levará à degradação da velocidade do canal resultante em cerca de 5%. Se cometermos um erro na sincronização por 1 milissegundo em 4 canais, a degradação da velocidade poderá cair facilmente para 30%. Além disso, a entropia nos canais muda muito rapidamente; portanto, se a medirmos menos de uma vez a cada 0,5 milissegundos, obteremos uma degradação de alta velocidade nos canais rápidos com um pequeno atraso. Obviamente, essa precisão não é necessária para todas as métricas e nem em todas as condições. Quando o atraso no canal é de 500 milissegundos, e trabalhamos com isso, o erro de 1 milissegundo dificilmente será perceptível. Além disso, para as métricas dos sistemas de suporte à vida, as frequências de pesquisa e sincronização de 2 segundos são suficientes para nós, no entanto, o próprio sistema de monitoramento deve poder trabalhar com frequências de pesquisa ultra altas e sincronização métrica ultra precisa. - Consumo mínimo de recursos e uma única pilha.
O dispositivo final pode ser um poderoso complexo a bordo que pode analisar a situação na estrada ou registrar dados biométricos de pessoas, ou um computador de tamanho de palma de uma placa que é usado por um soldado das forças especiais sob uma armadura para transmitir vídeo em tempo real em más condições de comunicação. Apesar de uma variedade de arquiteturas e poder de computação, gostaríamos de ter a mesma pilha de software. - Arquitetura de guarda-chuva
As métricas devem ser coletadas e agregadas no dispositivo final, ter um sistema de armazenamento local e visualização em tempo real e retrospectivamente. Se houver comunicação disponível, transfira os dados para o sistema de monitoramento central. Quando não há conexão, a fila de envio deve acumular e não consumir RAM. - Uma API para integração ao sistema de monitoramento de um cliente, porque ninguém precisa de muitos sistemas de monitoramento. O cliente deve coletar dados de qualquer dispositivo e rede em um único monitoramento.
O que aconteceu
Para carregar a já impressionante longrid, não darei exemplos e medidas de todos os sistemas de monitoramento. Isso puxará outro artigo. Vou apenas dizer que não conseguimos encontrar um sistema de monitoramento capaz de realizar duas métricas ao mesmo tempo com um erro de menos de 1 milissegundo e que funciona de maneira igualmente eficiente nas arquiteturas ARM com 64 MB de RAM e x86_64 com 32 GB de RAM. Portanto, decidimos escrever nossos próprios, o que pode fazer exatamente isso. Aqui está o que temos:
Somando a taxa de transferência de três canais para diferentes topologias de rede
Visualização de algumas métricas principais
Arquitetura
Como principal linguagem de programação, tanto no dispositivo quanto no data center, usamos Golang. Ele simplificou bastante sua vida implementando multitarefa e a capacidade de obter um binário executável vinculado estaticamente para cada serviço. Como resultado, economizamos significativamente recursos, métodos e tráfego de implantação de serviço nos dispositivos finais, tempo de desenvolvimento e depuração de código.
O sistema é implementado de acordo com o princípio modular clássico e contém vários subsistemas:
- Registro de métricas.
Cada métrica é veiculada por seu próprio fluxo e sincronizada pelos canais. Conseguimos obter uma precisão de sincronização de até 10 nanossegundos. - Armazenamento métrico
Escolhemos entre escrever nosso repositório para séries temporais ou usar um dos disponíveis. O banco de dados é necessário para dados retrospectivos, que estão sujeitos a visualização subseqüente, ou seja, não possui dados sobre atrasos no canal a cada 0,5 milissegundos ou indicações de erro na rede de transporte, mas há uma velocidade em cada interface a cada 500 milissegundos. Além dos altos requisitos de plataforma cruzada e baixo consumo de recursos, é extremamente importante que possamos processar. dados no mesmo local em que estão armazenados. Isso economiza tremendamente recursos de computação. Desde 2016, usamos o Tarantool DBMS neste projeto e, até o momento, não estamos vendo um substituto para ele no horizonte. Flexível, com ótimo consumo de recursos, mais do que suporte técnico adequado. Tarantool também possui um módulo GIS. Certamente não é tão poderoso quanto o PostGIS, mas é suficiente para nossas tarefas de armazenar algumas métricas vinculadas a um local (relevante para o transporte). - Visualização de Métricas
Tudo é relativamente simples aqui. Pegamos os dados do armazenamento e mostramos em tempo real ou retrospectivamente. - Sincronização de dados com um sistema de monitoramento central.
O sistema de monitoramento central recebe dados de todos os dispositivos, armazena-os com uma dada retrospectiva e os envia por meio da API ao sistema de monitoramento do Cliente. Ao contrário dos sistemas de monitoramento clássicos, nos quais a "cabeça" caminha e coleta dados - temos o esquema oposto. Os próprios dispositivos enviam dados quando há uma conexão. Esse é um ponto muito importante, pois permite que você receba dados do dispositivo pelos períodos em que ele não estava disponível e não carregue canais e recursos enquanto o dispositivo não estiver disponível. Como sistema central de monitoramento, usamos o servidor de monitoramento Influx. Diferentemente dos análogos, ele pode importar dados retrospectivos (ou seja, com um carimbo de hora diferente do momento em que a métrica foi recebida). As métricas coletadas são visualizadas por um arquivo Grafana modificado. Essa pilha padrão também foi escolhida porque possui APIs de integração prontas para praticamente qualquer sistema de monitoramento de clientes. - Sincronização de dados com um sistema central de gerenciamento de dispositivos.
O sistema de gerenciamento de dispositivos implementa o Zero Touch Provisioning (atualização de firmware, configuração etc.) e, ao contrário do sistema de monitoramento, recebe apenas problemas do dispositivo. Esses são os gatilhos dos serviços de vigilância de hardware a bordo e todas as métricas dos sistemas de suporte à vida: temperatura da CPU e SSD, carga da CPU, espaço livre e integridade do SMART nos discos. O armazenamento do subsistema também é construído no Tarantool. Isso nos dá uma velocidade significativa na agregação de séries temporais em milhares de dispositivos e também resolve completamente o problema da sincronização de dados com esses dispositivos. O Tarantool possui um excelente sistema de filas e entrega garantida. Tiramos esse importante recurso da caixa, ótimo!
Sistema de gerenciamento de rede
O que vem a seguir
Até agora, o elo mais fraco do nosso país é o sistema central de monitoramento. É implementado em 99,9% na pilha padrão e possui várias desvantagens:
- O InfluxDB perde dados quando a energia é desligada. Como regra, o Cliente pega prontamente tudo o que vem dos dispositivos e não há dados com mais de 5 minutos no próprio banco de dados, mas no futuro isso pode ser complicado.
- A Grafana tem vários problemas com a agregação de dados e a sincronização de sua exibição. O problema mais comum é quando o banco de dados contém uma série temporal com um intervalo de 2 segundos a partir de, por exemplo, 00:00:00, e o Grafana começa a mostrar dados em agregação a partir de +1 segundo. Como resultado, o usuário vê um gráfico de dança.
- Código em excesso para integração da API com sistemas de monitoramento de terceiros. Pode ser muito mais compacto e, é claro, reescrever para Go)
Suponho que todos vocês viram perfeitamente como é Grafana e sem mim você conhece os problemas dela, portanto não sobrecarregarei o post com fotos.
Conclusão
Eu deliberadamente não descrevi detalhes técnicos, mas descrevi apenas o design de suporte deste sistema. Primeiramente, para descrever tecnicamente o sistema, é necessário mais um artigo. Em segundo lugar, nem todos estarão interessados. Escreva nos comentários quais detalhes técnicos você gostaria de saber.
Se alguém tiver perguntas fora deste artigo, posso escrever para a.rodin @ qedr.com