Há um ano lançamos uma versão piloto de um projeto promocional para .
Inicialmente, o projeto se chamava Road-To-Barcelona, depois passou a ser Road-To-Berlin (daí R2B nas imagens) e no final passou a se chamar xRide.
A ideia principal do projeto era esta: em vez de ter um serviço centralizado de aluguer de automóveis ou scooters (estamos a falar de scooters também conhecidas como motos elétricas, não de kickscooters/scooters) queríamos fazer uma plataforma de aluguer descentralizado. Sobre as dificuldades que encontramos .
Inicialmente o projeto era voltado para automóveis, mas devido aos prazos, às comunicações extremamente longas com os fabricantes e ao grande número de restrições de segurança, as scooters elétricas foram escolhidas para o piloto.
O usuário instalou um aplicativo iOS ou Android no telefone, aproximou-se da scooter de sua preferência, após o que o telefone e a scooter estabeleceram uma conexão ponto a ponto, o ETH foi trocado e o usuário pôde iniciar o passeio ligando a scooter via o telefone. Ao final da viagem, também foi possível pagar a viagem usando Ethereum da carteira do usuário no celular.
Além dos patinetes, o usuário viu no aplicativo “carregadores inteligentes”, visitando os quais o próprio usuário poderia trocar a bateria atual caso ela estivesse fraca.
Em geral, era assim que se parecia o nosso piloto, lançado em setembro do ano passado em duas cidades alemãs: Bonn e Berlim.
E então, um dia, em Bonn, de manhã cedo, a nossa equipa de apoio (localizada no local para manter as scooters em funcionamento) foi alertada: uma das scooters tinha desaparecido sem deixar rasto.
Como encontrá-lo e devolvê-lo?
Neste artigo falarei sobre isso, mas primeiro - sobre como construímos nossa própria plataforma IoT e como a monitoramos.
O que e por que monitorar: scooters, infraestrutura, estações de recarga?
Então, o que queríamos monitorar em nosso projeto?
Em primeiro lugar, estas são as próprias scooters - as próprias scooters eléctricas são bastante caras, não se pode lançar um projecto deste tipo sem estar suficientemente preparado; se possível, pretende recolher o máximo de informação possível sobre as scooters: sobre a sua localização, nível de carga , etc.
Além disso, gostaria de monitorar o estado de nossa própria infraestrutura de TI - bancos de dados, serviços e tudo o que é necessário para funcionar. Também foi necessário monitorar o estado dos “carregadores inteligentes”, caso eles quebrassem ou ficassem sem bateria.
Patinetes
Quais eram as nossas scooters e o que queríamos saber sobre elas?
A primeira e mais importante são as coordenadas GPS, pois graças a elas podemos saber onde estão e para onde se movem.
A seguir vem a carga da bateria, graças à qual podemos determinar que o carregamento das scooters está chegando ao fim e enviar um espremedor ou pelo menos avisar o usuário.
Claro, também é necessário verificar o que está acontecendo com nossos componentes de Hardware:
- o bluetooth funciona?
- o próprio módulo GPS funciona?
- Também tivemos o problema de o GPS poder enviar coordenadas incorretas e ficar preso, e isso só poderia ser determinado por verificações adicionais na scooter,
e notifique o suporte o mais rápido possível para resolver o problema
- Também tivemos o problema de o GPS poder enviar coordenadas incorretas e ficar preso, e isso só poderia ser determinado por verificações adicionais na scooter,
E por último: verificações do software, começando pelo SO e processador, rede e carga de disco, terminando com verificações dos nossos próprios módulos que são mais específicos para nós (, ).
Hardware
Qual foi a nossa parte “de ferro”?
Levando em consideração o menor prazo possível e a necessidade de prototipagem rápida, escolhemos a opção mais fácil de implementação e seleção de componentes - Raspberry Pi.
Além do próprio Rpi, tínhamos uma placa personalizada (que nós próprios desenvolvemos e encomendamos à China para agilizar o processo de montagem da solução final) e um conjunto de componentes - um relé (para ligar/desligar a scooter), um leitor de carga de bateria, um modem, antenas. Tudo isso foi embalado de forma compacta em uma “caixa xRide” especial.
De referir ainda que toda a caixa era alimentada por um power bank adicional, que por sua vez era alimentado pela bateria principal da scooter.
Isso possibilitou utilizar o monitoramento e ligar a scooter mesmo após o término da viagem, já que a bateria principal foi desligada imediatamente após girar a chave de ignição para a posição “desligada”.
Docker? Linux simples? e implantação
Voltemos ao monitoramento, então Raspberry - o que temos?
Uma das primeiras coisas que queríamos usar para acelerar o processo de implantação, atualização e entrega de componentes para dispositivos físicos foi o Docker.
Infelizmente, rapidamente ficou claro que o Docker no RPi, embora funcione, tem muita sobrecarga, principalmente em termos de consumo de energia.
A diferença no uso do SO “nativo”, embora não tão forte, ainda foi suficiente para ficarmos atentos à possibilidade de perder carga muito rapidamente.
O segundo motivo foi uma de nossas bibliotecas parceiras em Node.js (sic!) - o único componente do sistema que não foi escrito em Go/C/C++.
Os autores da biblioteca não tiveram tempo de fornecer uma versão funcional em nenhuma das línguas “nativas”.
Não apenas o nó em si não é a solução mais elegante para dispositivos de baixo desempenho, mas a biblioteca em si consumia muitos recursos.
Percebemos que, mesmo que quiséssemos, usar o Docker seria uma sobrecarga muito grande para nós. A escolha foi feita em favor do sistema operacional nativo e do trabalho direto sob ele.
OS
Como resultado, escolhemos novamente a opção mais simples como sistema operacional e usamos o Raspbian (compilação Debian para Pi).
Escrevemos todo o nosso software em Go, por isso também escrevemos o módulo principal do agente de hardware em nosso sistema em Go.
É ele o responsável por trabalhar com GPS, Bluetooth, ler a carga, ligar a scooter, etc.
Implantar
Surgiu imediatamente a questão sobre a necessidade de implementar um mecanismo para entregar atualizações aos dispositivos (OTA) - tanto atualizações para o nosso agente/aplicativo em si, quanto atualizações para o próprio sistema operacional/firmware (já que novas versões do agente podem exigir atualizações no kernel ou componentes do sistema, bibliotecas, etc.).
Depois de uma longa análise de mercado, descobriu-se que existem muitas soluções para fornecer atualizações para o dispositivo.
Desde utilitários relativamente simples, principalmente orientados para atualização/inicialização dupla, como swupd/SWUpdate/OSTree, até plataformas completas, como Mender e Balena.
Em primeiro lugar, decidimos que estávamos interessados em soluções ponta a ponta, pelo que a escolha recaiu imediatamente sobre as plataformas.
O mesmo foi excluído devido ao fato de ele realmente usar o mesmo Docker dentro de seu balenaEngine.
Mas observo que, apesar disso, acabamos usando constantemente o produto deles para firmware flash em cartões SD - um utilitário simples e extremamente conveniente para isso.
Portanto, no final a escolha recaiu sobre . Mender é uma plataforma completa para montagem, entrega e instalação de firmware.
No geral, a plataforma parece ótima, mas levamos cerca de uma semana e meia apenas para construir a versão correta do nosso firmware usando o construtor mender.
E quanto mais mergulhávamos nas complexidades de seu uso, mais ficava claro que, para implantá-lo totalmente, precisaríamos de muito mais tempo do que o que tínhamos.
Infelizmente, nossos prazos apertados nos obrigaram a abandonar o uso do Mender e escolher um ainda mais simples.
Ansible
A solução mais simples em nossa situação foi usar Ansible. Alguns manuais foram suficientes para começar.
A essência deles era que simplesmente nos conectamos do host (servidor CI) via ssh aos nossos rasberries e distribuímos atualizações para eles.
No início tudo era simples - era preciso estar na mesma rede dos aparelhos, o vazamento era feito via wi-fi.
No escritório havia apenas uma dúzia de framboesas de teste conectadas à mesma rede, cada dispositivo tinha um endereço IP estático também especificado no Ansible Inventory.
Foi o Ansible quem entregou nosso agente de monitoramento aos dispositivos finais
X
Infelizmente, esse caso de uso do Ansible só funcionava no modo de desenvolvimento antes de termos scooters reais.
Porque as scooters, como você entende, não ficam conectadas a um roteador Wi-Fi, esperando constantemente por atualizações na rede.
Na realidade, as scooters não podem ter qualquer ligação que não seja 3G/LTE móvel (e mesmo assim não o tempo todo).
Isto impõe imediatamente muitos problemas e limitações, como baixa velocidade de conexão e comunicação instável.
Mas o mais importante é que numa rede 3G/LTE não podemos simplesmente confiar num IP estático atribuído à rede.
Isso é parcialmente resolvido por alguns fornecedores de cartões SIM; existem até cartões SIM especiais projetados para dispositivos IoT com endereços IP estáticos. Mas não tínhamos acesso a esses cartões SIM e não podíamos usar endereços IP.
É claro que surgiram ideias para fazer algum tipo de registro de endereços IP, também conhecido como descoberta de serviço em algum lugar como o Consul, mas tivemos que abandonar essas ideias, pois em nossos testes o endereço IP poderia mudar com muita frequência, o que gerava grande instabilidade.
Por esse motivo, o uso mais conveniente para entrega de métricas não seria utilizar o modelo pull, onde iríamos até os dispositivos para obter as métricas necessárias, mas sim push, entregando métricas do dispositivo diretamente para o servidor
VPN
Como solução para este problema, escolhemos VPN - especificamente .
Os clientes (scooters) no início do sistema se conectaram ao servidor VPN e conseguiram se conectar a eles. Este túnel foi usado para entregar atualizações.
Em teoria, o mesmo túnel poderia ser usado para monitoramento, mas tal conexão era mais complicada e menos confiável do que um simples push.
Recursos de nuvem
Por último, é necessário monitorar nossos serviços em nuvem e bancos de dados, já que para eles utilizamos Kubernetes, idealmente para que a implantação do monitoramento no cluster seja o mais simples possível. O ideal é usar , já que para implantação, nós o usamos na maioria dos casos. E, claro, para monitorar a nuvem você precisa usar as mesmas soluções que para as próprias scooters.
Dado
Ufa, parece que resolvemos a descrição, vamos fazer uma lista do que precisávamos no final:
- Uma solução rápida, pois o monitoramento é necessário já durante o processo de desenvolvimento
- Volume/quantidade – muitas métricas necessárias
- A coleta de registros é obrigatória
- Confiabilidade – os dados são essenciais para o sucesso do lançamento
- Você não pode usar o modelo pull - você precisa push
- Precisamos de monitoramento unificado não apenas de hardware, mas também de nuvem
A imagem final ficou mais ou menos assim
Seleção de pilha
Então, nos deparamos com a questão de escolher uma pilha de monitoramento.
Em primeiro lugar, procurávamos a solução multifuncional mais completa que cobrisse simultaneamente todas as nossas necessidades, mas ao mesmo tempo fosse suficientemente flexível para adaptar a sua utilização às nossas necessidades. Mesmo assim, tivemos muitas restrições impostas por hardware, arquitetura e prazos.
Há uma enorme variedade de soluções de monitoramento, começando com sistemas completos como , ou e finalizando com soluções prontas para gestão de frotas.
Inicialmente, esta última parecia ser uma solução ideal para nós, mas alguns não tinham monitoramento completo, outros tinham capacidades severamente limitadas das versões gratuitas e outros simplesmente não atendiam aos nossos “desejos” ou não eram flexíveis o suficiente para se adequarem aos nossos cenários. Alguns estão simplesmente desatualizados.
Depois de analisar uma série de soluções semelhantes, rapidamente chegamos à conclusão de que seria mais fácil e rápido montar nós mesmos uma pilha semelhante. Sim, será um pouco mais complicado do que implementar uma plataforma de gestão de frotas completamente pronta, mas não teremos que fazer concessões.
Quase certamente, em toda a enorme abundância de soluções, já existe uma pronta que nos serviria perfeitamente, mas no nosso caso foi muito mais rápido montar uma determinada pilha por conta própria e personalizá-la “para nós” em vez de testando produtos prontos.
Com tudo isso, não nos esforçamos para montar nós mesmos uma plataforma de monitoramento inteira, mas procurávamos as pilhas “prontas” mais funcionais, apenas com a capacidade de configurá-las com flexibilidade.
(B)ELK?
A primeira solução realmente considerada foi a conhecida pilha ELK.
Na verdade, deveria se chamar BELK, porque tudo começa com Beats -
Claro, ELK é uma das soluções mais famosas e poderosas na área de monitoramento e ainda mais na coleta e processamento de logs.
Pretendíamos que o ELK fosse usado para coletar logs e também para armazenamento de longo prazo de métricas obtidas do Prometheus.
Para visualização você pode usar Grafan.
Na verdade, a nova pilha ELK pode coletar métricas de forma independente (metricbeat), e o Kibana também pode exibi-las.
Mesmo assim, o ELK inicialmente cresceu a partir de logs e até agora a funcionalidade das métricas tem uma série de desvantagens sérias:
- Significativamente mais lento que o Prometheus
- Integra-se em muito menos lugares do que o Prometheus
- É difícil configurar alertas para eles
- Métricas ocupam muito espaço
- Configurar dashboards com métricas no Kiban é muito mais complicado do que no Grafan
Em geral, as métricas no ELK são pesadas e ainda não tão convenientes quanto em outras soluções, das quais existem agora muito mais do que apenas Prometheus: TSDB, Victoria Metrics, Cortex, etc., etc. Claro, eu realmente gostaria de ter uma solução completa e completa imediatamente, mas no caso do metricbeat houve muitos compromissos.
E a própria pilha ELK tem vários momentos difíceis:
- É pesado, às vezes até muito pesado se você coletar uma quantidade bastante grande de dados
- Você precisa “saber cozinhá-lo” - você precisa dimensioná-lo, mas isso não é trivial de fazer
- Versão gratuita simplificada - a versão gratuita não possui alerta normal e no momento da seleção não houve autenticação
Devo dizer que recentemente o último ponto melhorou e, além disso, (incluindo autenticação) o próprio modelo de preços começou a mudar.
Mas no momento em que íamos implantar esta solução, não houve nenhum alerta.
Talvez pudéssemos ter tentado construir algo usando o ElastAlert ou outras soluções comunitárias, mas ainda assim decidimos considerar outras alternativas.
Loki - Grafana - Prometeu
No momento, uma boa solução pode ser construir uma pilha de monitoramento baseada exclusivamente no Prometheus como provedor de métricas, no Loki para logs e para visualização você pode usar o mesmo Grafana.
Infelizmente, no momento do início do piloto de vendas do projeto (setembro-outubro de 19), o Loki ainda estava na versão beta 0.3-0.4, e no momento do início do desenvolvimento não poderia ser considerado uma solução de produção de forma alguma.
Ainda não tenho experiência no uso do Loki em projetos sérios, mas posso dizer que o Promtail (um agente para coleta de logs) funciona muito bem tanto para bare metal quanto para pods em kubernetes.
TICK
Talvez a alternativa completa mais valiosa (a única?) à pilha ELK agora só possa ser chamada de pilha TICK - Telegraf, InfluxDB, Chronograf, Kapacitor.
Descreverei todos os componentes abaixo com mais detalhes, mas a ideia geral é esta:
- Telegraf - agente de coleta de métricas
- InfluxDB - banco de dados de métricas
- Kapacitor - processador de métricas em tempo real para alertas
- Chronograf - painel web para visualização
Para InfluxDB, Kapacitor e Chronograf existem gráficos de leme oficiais que usamos para implantá-los.
Ressalta-se que na última versão do Influx 2.0 (beta), Kapacitor e Chronograf passaram a fazer parte do InfluxDB e não existem mais separadamente
Telégrafo
é um agente muito leve para coletar métricas em uma máquina de estado.
Ele pode monitorar uma grande quantidade de tudo, desde para
servidor .
Tem uma série de vantagens interessantes:
- Rápido e leve (escrito em Go)
- Consome uma quantidade mínima de recursos
- Enviar métricas por padrão
- Coleta todas as métricas necessárias
- Métricas do sistema sem nenhuma configuração
- Métricas de hardware, como informações de sensores
- É muito fácil adicionar suas próprias métricas
- Muitos plug-ins prontos para uso
- Coleta registros
Como as métricas push eram necessárias para nós, todas as outras vantagens foram mais do que acréscimos agradáveis.
A coleta de logs pelo próprio agente também é muito conveniente, pois não há necessidade de conectar utilitários adicionais para registrar logs.
O Influx oferece a experiência mais conveniente para trabalhar com logs se você usar .
O Telegraf geralmente é um ótimo agente para coletar métricas, mesmo se você não usar o restante da pilha ICK.
Muitas pessoas o cruzam com o ELK e vários outros bancos de dados de série temporal por conveniência, já que ele pode gravar métricas em praticamente qualquer lugar.
InfluxDB
InfluxDB é o núcleo principal da pilha TICK, ou seja, um banco de dados de série temporal para métricas.
Além das métricas, o Influx também pode armazenar logs, embora, em essência, os logs para ele sejam apenas as mesmas métricas, só que em vez dos indicadores numéricos usuais, a função principal é executada por uma linha de texto de log.
O InfluxDB também é escrito em Go e parece rodar muito mais rápido em comparação com o ELK em nosso cluster (não o mais poderoso).
Uma das vantagens interessantes do Influx também incluiria uma API muito conveniente e rica para consultas de dados, que usamos muito ativamente.
Desvantagens - $$$ ou escala?
A pilha TICK tem apenas uma desvantagem que descobrimos - ela querido. Ainda mais.
O que a versão paga tem que a versão gratuita não tem?
Pelo que pudemos entender, a única diferença entre a versão paga da pilha TICK e a gratuita são as capacidades de escalonamento.
Ou seja, você pode criar um cluster com alta disponibilidade somente em .
Se você quiser um HA completo, precisará pagar ou usar muletas. Existem algumas soluções comunitárias - por exemplo parece uma solução competente, mas está escrito que não é adequada para produção, assim como
- uma solução simples com bombeamento de dados via NATS (também terá que ser escalonada, mas isso pode ser resolvido).
É uma pena, mas ambos parecem estar abandonados - não há novos commits, presumo que o problema seja o lançamento em breve da nova versão do Influx 2.0, na qual muitas coisas serão diferentes (não há informações sobre dimensionando nele ainda).
Oficialmente existe uma versão gratuita - na verdade, este é um HA primitivo, mas apenas por meio de balanceamento,
já que todos os dados serão gravados em todas as instâncias do InfluxDB atrás do balanceador de carga.
Ele tem algum como possíveis problemas com pontos de substituição e a necessidade de criar bases para métricas com antecedência
(o que acontece automaticamente durante o trabalho normal com o InfluxDB).
Além de , isso significa sobrecarga adicional para métricas duplicadas (processamento e armazenamento) que talvez você não precise, mas não há como separá-las.
Métricas de Vitória?
Como resultado, apesar de estarmos completamente satisfeitos com a pilha TICK em tudo que não seja o escalonamento pago, decidimos ver se havia alguma solução gratuita que pudesse substituir o banco de dados InfluxDB, deixando os componentes T_CK restantes.
Existem muitos bancos de dados de séries temporais, mas o mais promissor é o Victoria Metrics, que tem uma série de vantagens:
- Rápido e fácil, pelo menos de acordo com os resultados
- Existe uma versão cluster, sobre a qual existem até boas críticas agora
- Ela pode fragmentar
- Suporta protocolo InfluxDB
Não pretendíamos construir uma pilha totalmente customizada baseada em Victoria e a principal esperança era que pudéssemos usá-la como um substituto imediato para o InfluxDB.
Infelizmente, isso não é possível, apesar de o protocolo InfluxDB ser suportado, ele só funciona para registrar métricas - apenas a API Prometheus está disponível “fora”, o que significa que não será possível configurar o Chronograf nele.
Além disso, apenas valores numéricos são suportados para métricas (usamos valores de string para métricas personalizadas - mais sobre isso na seção ).
Obviamente, pelo mesmo motivo, a VM não pode armazenar logs como o Influx faz.
Além disso, deve-se notar que no momento da busca pela solução ideal, Victoria Metrics ainda não era tão popular, a documentação era muito menor e a funcionalidade era mais fraca
(Não me lembro de uma descrição detalhada da versão do cluster e da fragmentação).
Seleção base
Como resultado, foi decidido que para o piloto ainda nos limitaríamos a um único nó InfluxDB.
Houve vários motivos principais para esta escolha:
- Gostamos muito de toda a funcionalidade da pilha TICK
- Já conseguimos implantá-lo e funcionou muito bem
- Os prazos estavam se esgotando e não sobrava muito tempo para testar outras opções.
- Não esperávamos uma carga tão pesada
Não tínhamos muitas scooters para a primeira fase do piloto e os testes durante o desenvolvimento não revelaram quaisquer problemas de desempenho.
Portanto, decidimos que para este projeto um nó Influx seria suficiente para nós sem a necessidade de escalonamento (ver conclusões no final).
Decidimos sobre a pilha e a base - agora sobre os componentes restantes da pilha TICK.
Capacitor
Kapacitor faz parte da pilha TICK, um serviço que pode monitorar métricas que entram no banco de dados em tempo real e realizar diversas ações baseadas em regras.
Em geral, ele é posicionado como uma ferramenta para rastreamento de possíveis anomalias e aprendizado de máquina (não tenho certeza se essas funções estão em demanda), mas o caso mais comum de seu uso é o alerta.
Foi assim que usamos para notificações. Configuramos alertas do Slack quando uma determinada scooter ficou off-line, e o mesmo foi feito para carregadores inteligentes e componentes importantes de infraestrutura.
Isso possibilitou responder rapidamente aos problemas, bem como receber notificações de que tudo voltou ao normal.
Um exemplo simples: uma bateria adicional para alimentar a nossa “caixa” avariou ou por algum motivo ficou sem carga; bastando instalar uma nova, após algum tempo deveremos receber uma notificação de que a funcionalidade da scooter foi restaurada.
No Influx 2.0 Kapacitor passou a fazer parte do DB
Cronógrafo
Já vi muitas soluções de UI diferentes para monitoramento, mas posso dizer que em termos de funcionalidade e UX nada se compara ao Chronograf.
Começamos a usar a pilha TICK, curiosamente, com Grafan como interface web.
Não vou descrever sua funcionalidade, todos conhecem suas amplas possibilidades de configurar qualquer coisa.
No entanto, o Grafana ainda é um instrumento completamente universal, enquanto o Chronograf foi projetado principalmente para uso com o Influx.
E, claro, graças a isso, o Chronograf pode oferecer funcionalidades muito mais inteligentes ou convenientes.
Talvez a principal conveniência de trabalhar com o Chronograf seja que você pode visualizar o interior do seu InfluxDB por meio do Explore.
Parece que o Grafana tem funcionalidade quase idêntica, mas na realidade, a configuração de um painel no Chronograf pode ser feita com alguns cliques do mouse (ao mesmo tempo olhando a visualização ali), enquanto no Grafana você ainda mais cedo ou mais tarde terá para editar a configuração JSON (é claro que o Chronograf permite fazer upload de seus dashas configurados manualmente e editá-los como JSON, se necessário - mas nunca precisei tocá-los depois de criá-los na interface do usuário).
O Kibana tem recursos muito mais ricos para criar painéis e controles para eles, mas a UX para tais operações é muito complexa.
Será necessário um bom entendimento para criar um painel conveniente. E embora a funcionalidade dos painéis do Chronograf seja menor, criá-los e personalizá-los é muito mais simples.
Os painéis em si, além do estilo visual agradável, não são diferentes dos painéis do Grafana ou Kibana:
Esta é a aparência da janela de consulta:
É importante notar, entre outras coisas, que conhecendo os tipos de campos no banco de dados InfluxDB, o próprio cronógrafo às vezes pode ajudá-lo automaticamente a escrever uma consulta ou a escolher a função de agregação correta, como a média.
E, claro, o Chronograf é o mais conveniente possível para visualizar registros. Se parece com isso:
Por padrão, os logs do Influx são adaptados para usar o syslog e, portanto, possuem um parâmetro importante: gravidade.
O gráfico no topo é especialmente útil; nele você pode ver os erros que ocorrem e a cor mostra imediatamente se a gravidade é maior.
Algumas vezes detectamos bugs importantes dessa forma, visualizando os registros da última semana e vendo um pico vermelho.
Claro que o ideal seria configurar alertas para tais erros, pois já tínhamos tudo para isso.
Até ligamos isso por um tempo, mas no processo de preparação do piloto, descobrimos que estávamos recebendo muitos erros (inclusive de sistema, como a indisponibilidade da rede LTE), que “enviaram spam” para o canal Slack demais, sem causar problemas, grande benefício.
A solução correta seria lidar com a maioria desses tipos de erros, ajustar a gravidade deles e só então ativar os alertas.
Dessa forma, apenas erros novos ou importantes seriam postados no Slack. Simplesmente não houve tempo suficiente para tal configuração, dados os prazos apertados.
Autenticação
Vale ressaltar também que o Chronograf suporta OAuth e OIDC como autenticação.
Isso é muito conveniente, pois permite conectá-lo facilmente ao seu servidor e criar um SSO completo.
No nosso caso, o servidor era — foi usado para conectar-se ao monitoramento, mas o mesmo servidor também foi usado para autenticar scooters e solicitações ao back-end.
“Administrador”
O último componente que descreverei é nosso “painel de administração” escrito por nós mesmos no Vue.
Basicamente, é apenas um serviço independente que exibe informações de scooters de nossos próprios bancos de dados, microsserviços e dados de métricas do InfluxDB simultaneamente.
Além disso, muitas funções administrativas foram transferidas para lá, como reinicialização de emergência ou abertura remota de fechadura para a equipe de suporte.
Também havia mapas. Já mencionei que começamos com o Grafana em vez do Chronograf - porque para o Grafana os mapas estão disponíveis na forma de plugins, nos quais podemos visualizar as coordenadas das scooters. Infelizmente, os recursos dos widgets de mapa para Grafana são muito limitados e, como resultado, foi muito mais fácil escrever seu próprio aplicativo web com mapas em poucos dias, para não apenas ver as coordenadas no momento, mas também exibir o percurso percorrido pela scooter, poder filtrar os dados no mapa, etc. (todas aquelas funcionalidades que não conseguimos configurar num simples dashboard).
Uma das vantagens já mencionadas do Influx é a capacidade de criar facilmente suas próprias métricas.
Isso permite que ele seja usado em uma grande variedade de cenários.
Tentamos registrar todas as informações úteis lá: carga da bateria, status do bloqueio, desempenho do sensor, bluetooth, GPS e muitas outras verificações de integridade.
Exibimos tudo isso no painel de administração.
Claro, o critério mais importante para nós foi o estado de funcionamento da scooter - na verdade, o Influx verifica isso sozinho e mostra-o com “sinais verdes” na seção Nodes.
Isto é feito pela função — usamos para entender o desempenho da nossa caixa e enviar esses mesmos alertas para o Slack.
A propósito, batizamos as scooters com nomes de personagens dos Simpsons - foi muito conveniente distingui-los uns dos outros
E no geral foi mais divertido assim. Frases como “Gente, Smithers está morto!” eram ouvidas constantemente.
Métricas de string
É importante que o InfluxDB permita armazenar não apenas valores numéricos, como é o caso do Victoria Metrics.
Parece que isso não é tão importante - afinal, além dos logs, qualquer métrica pode ser armazenada na forma de números (basta adicionar mapeamento para estados conhecidos - uma espécie de enum)?
No nosso caso, houve pelo menos um cenário em que as métricas de string foram muito úteis.
Acontece que o fornecedor dos nossos “carregadores inteligentes” era um terceiro, não tínhamos controle sobre o processo de desenvolvimento e as informações que esses carregadores poderiam fornecer.
Como resultado, a API de cobrança estava longe de ser ideal, mas o principal problema era que nem sempre conseguíamos entender seu estado.
Foi aqui que o Influx veio em socorro. Simplesmente escrevemos o status da string que chegou até nós no campo do banco de dados InfluxDB sem alterações.
Por algum tempo, apenas valores como “online” e “offline” chegavam lá, com base nas informações que eram exibidas em nosso painel de administração, e as notificações eram enviadas ao Slack. Porém, em algum momento, valores como “desconectado” também começaram a aparecer por lá.
Como descobrimos mais tarde, esse status foi enviado uma vez após a perda da conexão, caso o carregador não conseguisse estabelecer uma conexão com o servidor após um determinado número de tentativas.
Assim, se usarmos apenas um conjunto fixo de valores, poderemos não ver essas alterações no firmware no momento certo.
E, em geral, as métricas de string oferecem muito mais possibilidades de uso; você pode registrar praticamente qualquer informação nelas. Embora, é claro, você também precise usar essa ferramenta com cuidado.
Além das métricas usuais, também registramos informações de localização GPS no InfluxDB. Isso foi extremamente útil para monitorar a localização de scooters em nosso painel de administração.
Na verdade, sempre soubemos onde e qual scooter estava no momento que precisávamos.
Isto foi muito útil para nós quando procurávamos uma scooter (ver conclusões no final).
Monitoramento de infraestrutura
Além das próprias scooters, também precisávamos monitorar toda a nossa (bastante extensa) infraestrutura.
Uma arquitetura muito geral era mais ou menos assim:
Se destacarmos uma pilha de monitoramento pura, ela ficará assim:
O que gostaríamos de verificar na nuvem é:
- Bases de dados
- Manto-chave
- Microsserviços
Como todos os nossos serviços em nuvem estão localizados no Kubernetes, seria bom coletar informações sobre seu estado.
Felizmente, o Telegraf pronto para uso pode coletar um grande número de métricas sobre o estado do cluster Kubernetes, e o Chronograf oferece imediatamente belos painéis para isso.
Monitoramos principalmente o desempenho dos pods e o consumo de memória. Em caso de queda, alertas no Slack.
Existem duas maneiras de rastrear pods no Kubernetes: DaemonSet e Sidecar.
Ambos os métodos são descritos em detalhes .
Usamos o Telegraf Sidecar e, além das métricas, coletamos logs de pod.
No nosso caso, tivemos que mexer nas toras. Apesar do Telegraf poder extrair logs da API Docker, queríamos ter uma coleção uniforme de logs com nossos dispositivos finais e configuramos o syslog para contêineres para isso. Talvez essa solução não fosse bonita, mas não houve reclamações sobre seu funcionamento e os logs ficaram bem exibidos no Chronograf.
Monitorar monitoramento???
No final, surgiu a velha questão da monitorização dos sistemas de monitorização, mas felizmente, ou infelizmente, simplesmente não tivemos tempo suficiente para isso.
Embora o Telegraf possa facilmente enviar suas próprias métricas ou coletar métricas do banco de dados InfluxDB para enviar para o mesmo Influx ou para outro lugar.
Descobertas
Que conclusões tiramos dos resultados do piloto?
Como você pode fazer o monitoramento?
Em primeiro lugar, a pilha TICK atendeu plenamente às nossas expectativas e nos deu ainda mais oportunidades do que esperávamos inicialmente.
Todas as funcionalidades que precisávamos estavam presentes. Tudo o que fizemos funcionou sem problemas.
Desempenho
O principal problema com a pilha TICK na versão gratuita é a falta de recursos de escalonamento. Isto não foi um problema para nós.
Não coletamos dados/números exatos de carga, mas coletamos dados de cerca de 30 scooters por vez.
Cada um deles coletou mais de três dezenas de métricas. Ao mesmo tempo, foram coletados registros dos dispositivos. A coleta e o envio dos dados ocorreram a cada 10 segundos.
É importante notar que após uma semana e meia do piloto, quando a maior parte das “feridas de infância” foram corrigidas e os problemas mais importantes já haviam sido resolvidos, tivemos que reduzir a frequência de envio de dados ao servidor para 30 segundos. Isto tornou-se necessário porque o tráfego nos nossos cartões SIM LTE começou a desaparecer rapidamente.
A maior parte do tráfego foi consumida por logs, as próprias métricas, mesmo com intervalo de 10 segundos, praticamente não o desperdiçaram.
Como resultado, depois de algum tempo desabilitamos completamente a coleta de logs nos dispositivos, pois problemas específicos já eram evidentes mesmo sem a coleta constante.
Em alguns casos, se a visualização dos logs ainda fosse necessária, simplesmente nos conectamos via WireGuard via VPN.
Acrescentarei também que cada ambiente separado foi separado um do outro e a carga descrita acima era relevante apenas para o ambiente de produção.
No ambiente de desenvolvimento, criamos uma instância separada do InfluxDB que continuou a coletar dados a cada 10 segundos e não tivemos problemas de desempenho.
TICK - ideal para projetos de pequeno e médio porte
Com base nessas informações, eu concluiria que a pilha TICK é ideal para projetos relativamente pequenos ou projetos que definitivamente não esperam nenhum HighLoad.
Se você não tiver milhares de pods ou centenas de máquinas, até mesmo uma instância do InfluxDB lidará perfeitamente com a carga.
Em alguns casos, você pode ficar satisfeito com o Influx Relay como uma solução primitiva de alta disponibilidade.
E, claro, ninguém está impedindo você de configurar o dimensionamento “vertical” e simplesmente alocar servidores diferentes para diferentes tipos de métricas.
Se você não tem certeza sobre a carga esperada nos serviços de monitoramento, ou se tem/terá uma arquitetura muito “pesada”, eu não recomendaria usar a versão gratuita da pilha TICK.
Claro, uma solução simples seria comprar - mas aqui não posso comentar de alguma forma, pois eu mesmo não conheço as sutilezas. Além de ser muito caro e definitivamente não adequado para pequenas empresas.
Nesse caso, hoje, eu recomendaria buscar a coleta de métricas por meio do Victoria Metrics e logs usando o Loki.
É verdade que voltarei a fazer uma reserva de que Loki/Grafana são muito menos convenientes (devido à sua maior versatilidade) que os TICK prontos, mas são gratuitos.
É importante: todas as informações aqui descritas são relevantes para a versão Influx 1.8, no momento o Influx 2.0 está prestes a ser lançado.
Embora não tenha tido a oportunidade de experimentá-lo em condições de combate e seja difícil tirar conclusões sobre melhorias, a interface definitivamente ficou ainda melhor, a arquitetura foi simplificada (sem capacitor e cronógrafo),
modelos apareceram (“recurso matador” - ). Mas, infelizmente, no momento, a versão 2 não possui a chave para a qual escolhemos a primeira versão - não há coleta de logs.
Esta funcionalidade também aparecerá no Influx 2.0, mas não encontramos prazos, mesmo aproximados.
Como não fazer plataformas IoT (agora)
No final, tendo lançado o piloto, nós próprios montamos a nossa própria pilha IoT completa, na ausência de uma alternativa adequada aos nossos padrões.
Porém, recentemente está disponível em versão Beta — é uma pena que ela não estivesse lá quando começamos a fazer o projeto.
Estamos completamente satisfeitos com o resultado final e com a plataforma baseada em Ansible + TICK + WireGuard que nós mesmos montamos. Mas hoje, eu recomendaria dar uma olhada em Balena antes de tentar construir sua própria plataforma IoT.
Porque, em última análise, ele pode fazer a maior parte do que fizemos, e o OpenBalena é gratuito e de código aberto.
Ele já sabe não apenas enviar atualizações, mas também uma VPN já integrada e adaptada para uso em um ambiente IoT.
E recentemente eles até lançaram seu , que se conecta facilmente ao seu ecossistema.
Ei, e a scooter desaparecida?
Então a scooter, "Ralph", desapareceu sem deixar vestígios.
Corremos imediatamente para ver o mapa em nosso “painel de administração”, com dados de métricas GPS do InfluxDB.
Graças aos dados de monitoramento, determinamos facilmente que a scooter saiu do estacionamento por volta das 21h do dia passado, dirigiu cerca de meia hora até alguma área e ficou estacionada até as 00h ao lado de alguma casa alemã.
Depois das 5h, nenhum dado de monitoramento foi recebido – isso significava que a bateria adicional estava completamente descarregada ou que o invasor finalmente descobriu como remover o hardware inteligente da scooter.
Apesar disso, a polícia ainda foi chamada ao endereço onde estava a scooter. A scooter não estava lá.
No entanto, o dono da casa também ficou surpreso com isso, já que ele realmente dirigiu esta scooter do escritório para casa ontem à noite.
Acontece que um dos funcionários de apoio chegou de manhã cedo e pegou a scooter, vendo que a bateria adicional estava completamente descarregada e levou-a (a pé) para o estacionamento. E a bateria adicional falhou devido à umidade.
Roubamos a scooter de nós mesmos. Aliás, não sei como e quem resolveu então a questão do caso policial, mas o monitoramento funcionou perfeitamente...
Fonte: habr.com