16 modems, 4 operadoras de celular = Velocidade de saída 933.45 Mbit/s
Introdução
Olá! Este artigo é sobre como escrevemos um novo sistema de monitoramento para nós mesmos. Difere dos existentes pela capacidade de obter métricas síncronas de alta frequência e baixíssimo consumo de recursos. A taxa de pesquisa pode chegar a 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 o rendimento e a tolerância a falhas dos canais de transmissão de dados. Isto é quando existem vários canais, digamos Operador1 (40Mbit/s) + Operador2 (30Mbit/s)+ Outra coisa (5 Mbit/s), o resultado é um canal estável e rápido, cuja velocidade será algo como isto: (40+ 30+5)x0.92=75×0.92=69 Mbit/s.
Tais soluções são procuradas onde a capacidade de qualquer canal é insuficiente. Por exemplo, transportes, sistemas de videovigilância e streaming de vídeo em tempo real, transmissão de transmissões de televisão e rádio ao vivo, quaisquer instalações suburbanas onde entre os operadores de telecomunicações existam apenas representantes das Quatro Grandes e a velocidade de um modem/canal não seja suficiente .
Para cada uma dessas áreas produzimos uma linha separada de dispositivos, mas sua parte de software é quase a mesma e um sistema de monitoramento de alta qualidade é um de seus principais módulos, sem a correta implementação do qual o produto não seria possível.
Ao longo de vários anos, conseguimos criar um sistema de monitoramento multinível, rápido, multiplataforma e leve. Isso é o que queremos compartilhar com nossa respeitada comunidade.
Formulação do problema
O sistema de monitoramento fornece métricas de duas classes fundamentalmente diferentes: métricas em tempo real e todas as outras. O sistema de monitoramento tinha apenas 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 gerenciamento de comunicação sem demora.
A alta frequência e a sincronização de diferentes métricas não são apenas importantes, são vitais para analisar a entropia dos canais de transmissão de dados. Se em um canal de transmissão de dados o atraso médio for de 30 milissegundos, então um erro de sincronização entre as métricas restantes de apenas um milissegundo levará à degradação da velocidade do canal resultante em aproximadamente 5%. Se calcularmos mal o tempo em 1 milissegundo em 4 canais, a degradação da velocidade pode facilmente cair 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, em canais rápidos com um pequeno atraso obteremos degradação de alta velocidade. É claro que tal 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, um erro de 1 milissegundo quase não será perceptível. Além disso, para métricas do sistema de suporte à vida, temos taxas de sondagem e sincronização suficientes de 2 segundos, mas o próprio sistema de monitoramento deve ser capaz de trabalhar com taxas de sondagem ultra-altas e sincronização ultraprecisa de métricas. - Consumo mínimo de recursos e uma única pilha.
O dispositivo final pode ser um poderoso complexo de bordo que pode analisar a situação na estrada ou realizar registros biométricos de pessoas, ou um computador de placa única do tamanho da palma da mão que um soldado das forças especiais usa sob sua armadura para transmitir vídeo em tempo real em más condições de comunicação. Apesar de tanta variedade de arquiteturas e poder computacional, gostaríamos de ter a mesma pilha de software. - Arquitetura guarda-chuva
As métricas devem ser coletadas e agregadas no dispositivo final, armazenadas localmente e visualizadas em tempo real e retrospectivamente. Se houver uma conexão, 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. - API para integração no sistema de monitoramento do cliente, pois ninguém precisa de muitos sistemas de monitoramento. O cliente deve coletar dados de quaisquer dispositivos e redes em um único monitoramento.
O que aconteceu
Para não sobrecarregar o já impressionante longread, não darei exemplos e medições de todos os sistemas de monitoramento. Isso levará a outro artigo. Direi apenas que não conseguimos encontrar um sistema de monitoramento que seja capaz de obter duas métricas simultaneamente com um erro inferior a 1 milissegundo e que funcione de forma igualmente eficaz tanto na arquitetura ARM com 64 MB de RAM quanto na arquitetura x86_64 com 32 MB. GB de RAM. Portanto, decidimos escrever o nosso próprio, que pode fazer tudo isso. Aqui está o que temos:
Resumindo o rendimento de três canais para diferentes topologias de rede
Visualização de algumas métricas importantes
Arquitetura
Usamos Golang como principal linguagem de programação, tanto no dispositivo quanto no data center. Ele simplificou bastante a vida com a implementação de multitarefa e a capacidade de obter um arquivo binário executável vinculado estaticamente para cada serviço. Como resultado, economizamos significativamente recursos, métodos e tráfego para implantar o serviço em 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:
- Cadastro de métricas.
Cada métrica é atendida por seu próprio thread e sincronizada entre canais. Conseguimos atingir uma precisão de sincronização de até 10 nanossegundos. - Armazenamento de métricas
Estávamos escolhendo entre escrever nosso próprio armazenamento para séries temporais ou usar algo que já estava disponível. O banco de dados é necessário para dados retrospectivos que estão sujeitos a visualização posterior, ou seja, não contém dados de atrasos no canal a cada 0.5 milissegundos ou leituras de erros na rede de transporte, mas há velocidade em cada interface a cada 500 milissegundos. Além dos altos requisitos de plataforma cruzada e baixo consumo de recursos, é extremamente importante para nós podermos processar. os dados são onde estão armazenados. Isso economiza enormes recursos de computação. Usamos o SGBD Tarantool neste projeto desde 2016 e até agora não vemos um substituto para ele no horizonte. Flexível, com ótimo consumo de recursos, suporte técnico mais que adequado. Tarantool também implementa um módulo GIS. Claro, não é tão poderoso quanto o PostGIS, mas é suficiente para nossas tarefas de armazenamento de algumas métricas relacionadas à localização (relevantes para transporte). - Visualização de métricas
Tudo é relativamente simples aqui. Pegamos dados do armazém e os exibimos em tempo real ou retrospectivamente. - Sincronização de dados com o sistema central de monitoramento.
O sistema de monitoramento central recebe dados de todos os dispositivos, armazena-os com um histórico específico e envia-os para o sistema de monitoramento do Cliente via API. Ao contrário dos sistemas clássicos de monitoramento, em que a “cabeça” anda e coleta dados, temos o esquema oposto. Os próprios dispositivos enviam dados quando há conexão. Este é um ponto muito importante, pois permite receber dados do dispositivo durante os períodos em que ele não esteve disponível e não carregar canais e recursos enquanto o dispositivo estiver indisponível. Usamos o servidor de monitoramento Influx como sistema de monitoramento central. Ao contrário de seus análogos, ele pode importar dados retrospectivos (ou seja, com carimbo de data/hora diferente do momento em que as métricas foram recebidas).As métricas coletadas são visualizadas pelo Grafana, modificadas com um arquivo. Essa pilha padrão também foi escolhida porque possui integrações de API prontas com quase todos os sistemas de monitoramento de clientes. - Sincronização de dados com um sistema central de gerenciamento de dispositivos.
O sistema de gerenciamento de dispositivos implementa Zero Touch Provisioning (atualização de firmware, configuração, etc.) e, diferentemente do sistema de monitoramento, recebe apenas problemas por dispositivo. Esses são gatilhos para a operação de serviços de vigilância de hardware integrados e todas as métricas dos sistemas de suporte à vida: temperatura da CPU e SSD, carga da CPU, espaço livre e integridade 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 de sincronização de dados com esses dispositivos. A Tarantool possui um excelente sistema de filas e entrega garantida. Tiramos esse recurso importante da caixa, ótimo!
Sistema de gerenciamento de rede
Qual é o próximo
Até agora, o nosso elo mais fraco é o sistema central de monitorização. Ele é implementado 99.9% em uma pilha padrão e tem várias desvantagens:
- O InfluxDB perde dados quando há falta de energia. Via de regra, o Cliente coleta prontamente tudo o que vem dos dispositivos e o próprio banco de dados não contém dados com mais de 5 minutos, mas no futuro isso pode se tornar um incômodo.
- O Grafana tem vários problemas com agregação de dados e 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 começando, digamos, 00:00:00, e o Grafana começa a mostrar dados agregados a partir de +1 segundo. Como resultado, o usuário vê um gráfico dançante.
- Quantidade excessiva de código para integração de API com sistemas de monitoramento de terceiros. Pode ser muito mais compacto e, claro, reescrito em Go)
Acho que todos vocês viram perfeitamente como é o Grafana e conhecem seus problemas sem mim, então não vou sobrecarregar o post com fotos.
Conclusão
Deliberadamente não descrevi os detalhes técnicos, mas descrevi apenas o design básico deste sistema. Em primeiro lugar, para descrever tecnicamente o sistema de forma completa, será necessário outro artigo. Em segundo lugar, nem todos estarão interessados nisso. Escreva nos comentários quais detalhes técnicos você gostaria de saber.
Se alguém tiver dúvidas além do escopo deste artigo, pode escrever para mim em a.rodin @ qedr.com
Fonte: habr.com