Hai un ano lanzamos unha versión piloto dun proxecto promocional para .
Inicialmente, o proxecto chamábase Road-To-Barcelona, máis tarde pasou a ser Road-To-Berlin (de aí R2B nas capturas de pantalla), e ao final chamouse xRide.
A idea principal do proxecto era esta: en lugar de ter un servizo de aluguer de coches ou scooters centralizado (falamos de scooters, tamén coñecidos como motocicletas eléctricas, non de kickscooters/scooters) queriamos facer unha plataforma para o aluguer descentralizado. Sobre as dificultades que atopamos .
Inicialmente, o proxecto centrouse nos automóbiles, pero debido aos prazos, ás comunicacións extremadamente longas cos fabricantes e a unha gran cantidade de restricións de seguridade, escolléronse scooters eléctricos para o piloto.
O usuario instalou unha aplicación iOS ou Android no teléfono, achegouse ao scooter que lle gustaba, despois de que o teléfono e o scooter estableceron unha conexión peer-to-peer, intercambiouse ETH e o usuario podía comezar o paseo acendo o scooter a través de o teléfono. Ao final da viaxe, tamén foi posible pagar a viaxe usando Ethereum desde a carteira do usuario no teléfono.
Ademais dos scooters, o usuario viu na aplicación "cargadores intelixentes", visitando os cales o usuario podía cambiar por si mesmo a batería actual se estaba baixa.
En xeral, así era o noso piloto, lanzado en setembro do ano pasado en dúas cidades alemás: Bonn e Berlín.
E entón, un día, en Bonn, á primeira hora da mañá, o noso equipo de apoio (situado no lugar para manter os scooters en funcionamento) foi avisado: un dos patinetes desaparecera sen deixar rastro.
Como atopalo e devolvelo?
Neste artigo falarei sobre isto, pero primeiro sobre como construímos a nosa propia plataforma IoT e como a monitorizamos.
Que e por que supervisar: scooters, infraestruturas, estacións de carga?
Entón, que queriamos supervisar no noso proxecto?
En primeiro lugar, estes son os propios scooters: os propios scooters eléctricos son bastante caros, non pode lanzar un proxecto deste tipo sen estar suficientemente preparado; se é posible, quere recoller toda a información posible sobre os scooters: sobre a súa localización, nivel de carga. , etc.
Ademais, gustaríame supervisar o estado da nosa propia infraestrutura informática: bases de datos, servizos e todo o que precisan para funcionar. Tamén foi necesario controlar o estado dos "cargadores intelixentes", por se avariaban ou quedaban sen baterías cheas.
Scooters
Cales eran os nosos patinetes e que queriamos saber sobre eles?
O primeiro e máis importante son as coordenadas GPS, xa que grazas a elas podemos entender onde están e onde se moven.
A continuación está a carga da batería, grazas á cal podemos determinar que a carga dos scooters está chegando ao seu fin e enviar un espremedor ou polo menos avisar ao usuario.
Por suposto, tamén é necesario comprobar o que está a suceder cos nosos compoñentes de Hardware:
- funciona o bluetooth?
- funciona o propio módulo GPS?
- Tamén tivemos un problema co feito de que o GPS podía enviar coordenadas incorrectas e quedar atascado, e isto só se puido determinar mediante comprobacións adicionais no scooter.
e notifique ao soporte o antes posible para resolver o problema
- Tamén tivemos un problema co feito de que o GPS podía enviar coordenadas incorrectas e quedar atascado, e isto só se puido determinar mediante comprobacións adicionais no scooter.
E por último: comprobacións do software, comezando polo SO e procesador, carga da rede e do disco, rematando coas comprobacións dos nosos propios módulos que son máis específicos para nós (, ).
ferraxes
Cal foi a nosa parte de "ferro"?
Tendo en conta o prazo máis breve posible e a necesidade de prototipado rápido, escollemos a opción máis sinxela para a implementación e selección de compoñentes: Raspberry Pi.
Ademais do propio Rpi, tiñamos unha placa personalizada (que nós mesmos desenvolvemos e encargamos a China para acelerar o proceso de montaxe da solución final) e un conxunto de compoñentes: un relé (para acender/apagar o scooter), un lector de carga de batería, un módem, antenas. Todo isto foi embalado de forma compacta nunha "caixa xRide" especial.
Tamén hai que ter en conta que toda a caixa estaba alimentada por un banco de enerxía adicional, que á súa vez era alimentado pola batería principal do scooter.
Isto permitiu usar a monitorización e encender o scooter mesmo despois do final da viaxe, xa que a batería principal desconectase inmediatamente despois de virar a chave de contacto á posición "apagado".
Docker? Linux simple? e despregamento
Volvamos á vixilancia, entón Raspberry - que temos?
Unha das primeiras cousas que queriamos utilizar para acelerar o proceso de implantación, actualización e entrega de compoñentes aos dispositivos físicos foi Docker.
Desafortunadamente, axiña quedou claro que Docker en RPi, aínda que funciona, ten moita sobrecarga, especialmente en termos de consumo de enerxía.
A diferenza usando o sistema operativo "nativo", aínda que non era tan forte, aínda era suficiente para que desconfiásemos da posibilidade de perder carga demasiado rápido.
O segundo motivo foi unha das nosas bibliotecas asociadas en Node.js (sic!), o único compoñente do sistema que non estaba escrito en Go/C/C++.
Os autores da biblioteca non tiveron tempo de ofrecer unha versión de traballo en ningunha das linguas “nativas”.
Non só o nodo en si non é a solución máis elegante para dispositivos de baixo rendemento, senón que a propia biblioteca tiña moita fame de recursos.
Démonos conta de que, aínda que quixeramos, usar Docker sería unha sobrecarga excesiva para nós. A elección foi feita a favor do sistema operativo nativo e traballar directamente baixo el.
OS
Como resultado, escollemos de novo a opción máis sinxela como o SO e usamos Raspbian (construción de Debian para Pi).
Escribimos todo o noso software en Go, polo que tamén escribimos o módulo principal de axente de hardware do noso sistema en Go.
É el quen se encarga de traballar con GPS, Bluetooth, ler a carga, encender o scooter, etc.
Implantar
Inmediatamente xurdiu a pregunta sobre a necesidade de implementar un mecanismo para entregar actualizacións aos dispositivos (OTA), tanto as actualizacións do noso axente/aplicación como as do propio SO/firmware (xa que as novas versións do axente poderían requirir actualizacións do núcleo). ou compoñentes do sistema, bibliotecas, etc.).
Despois dunha longa análise do mercado, descubriuse que hai moitas solucións para ofrecer actualizacións ao dispositivo.
Desde utilidades relativamente sinxelas, na súa maioría orientadas a actualización/arranque dual como swupd/SWUpdate/OSTree ata plataformas completas como Mender e Balena.
En primeiro lugar, decidimos que nos interesaban solucións de extremo a extremo, polo que a elección recaeu inmediatamente nas plataformas.
O moi foi excluído debido ao feito de que realmente usa o mesmo Docker dentro do seu balenaEngine.
Pero observo que a pesar diso, acabamos usando constantemente o seu produto para o firmware flash en tarxetas SD: unha utilidade sinxela e moi cómoda para iso.
Polo tanto, ao final a elección caeu . Mender é unha plataforma completa para montar, entregar e instalar firmware.
En xeral, a plataforma ten un aspecto estupendo, pero levounos aproximadamente unha semana e media só crear a versión correcta do noso firmware usando o creador de reparadores.
E canto máis nos mergullábamos nas complejidades do seu uso, máis claro quedou que para implantalo por completo necesitaríamos moito máis tempo do que tiñamos.
Por desgraza, os nosos prazos axustados fixeron que nos víramos obrigados a abandonar o uso de Mender e escoller un aínda máis sinxelo.
Ansible
A solución máis sinxela na nosa situación era usar Ansible. Un par de libros de xogo foron suficientes para comezar.
A súa esencia era que simplemente nos conectamos desde o servidor (servidor CI) a través de ssh ás nosas framboesas e distribuímoslles actualizacións.
Ao principio, todo era sinxelo: tiñas que estar na mesma rede cos dispositivos, o vertido facíase a través de Wi-Fi.
Na oficina había simplemente unha ducia de framboesas de proba conectadas á mesma rede, cada dispositivo tiña un enderezo IP estático tamén especificado en Ansible Inventory.
Foi Ansible quen entregou o noso axente de vixilancia aos dispositivos finais
3G / LTE
Desafortunadamente, este caso de uso para Ansible só podía funcionar no modo de desenvolvemento antes de que tiveramos scooters reais.
Porque os scooters, como entendes, non están conectados a un enrutador Wi-Fi, esperando constantemente actualizacións pola rede.
En realidade, os scooters non poden ter ningunha conexión que non sexa 3G/LTE móbil (e aínda así non todo o tempo).
Isto impón inmediatamente moitos problemas e limitacións, como a baixa velocidade de conexión e a comunicación inestable.
Pero o máis importante é que nunha rede 3G/LTE non podemos confiar simplemente nunha IP estática asignada á rede.
Isto é solucionado parcialmente por algúns provedores de tarxetas SIM; incluso hai tarxetas SIM especiais deseñadas para dispositivos IoT con enderezos IP estáticos. Pero non tiñamos acceso a tales tarxetas SIM e non podíamos usar enderezos IP.
Por suposto, había ideas para facer algún tipo de rexistro de enderezos IP tamén coñecido como descubrimento de servizos nalgún lugar como Consul, pero tivemos que abandonar tales ideas, xa que nas nosas probas o enderezo IP podía cambiar con demasiada frecuencia, o que provocou unha gran inestabilidade.
Por este motivo, o uso máis conveniente para entregar métricas non sería usar o modelo de extracción, onde iríamos aos dispositivos para as métricas necesarias, senón push, entregando métricas desde o dispositivo directamente ao servidor.
VPN
Como solución a este problema, escollemos VPN, concretamente .
Os clientes (scooters) no inicio do sistema conectaron ao servidor VPN e puideron conectarse a eles. Este túnel utilizouse para entregar actualizacións.
En teoría, o mesmo túnel podería usarse para a monitorización, pero esa conexión era máis complicada e menos fiable que un simple empuxe.
Recursos na nube
Por último, é necesario supervisar os nosos servizos e bases de datos na nube, xa que utilizamos Kubernetes para eles, idealmente para que a implantación do seguimento no clúster sexa o máis sinxelo posible. O ideal é usar , xa que para o despregamento, usámolo na maioría dos casos. E, por suposto, para supervisar a nube cómpre empregar as mesmas solucións que para os propios scooters.
Dado
Uf, parece que temos resolto a descrición, imos facer unha lista do que necesitamos ao final:
- Unha solución rápida, xa que o seguimento é necesario xa durante o proceso de desenvolvemento
- Volume/cantidade: necesítanse moitas métricas
- É necesaria a recollida de rexistros
- Fiabilidade: os datos son fundamentais para o éxito do lanzamento
- Non podes usar o modelo de tracción, necesitas empuxe
- Necesitamos un seguimento unificado non só do hardware, senón tamén da nube
A imaxe final parecía algo así
Selección de pila
Entón, enfrontámonos á cuestión de escoller unha pila de seguimento.
En primeiro lugar, buscabamos a solución todo-en-un máis completa que cubrira simultáneamente todos os nosos requisitos, pero que, ao mesmo tempo, fose o suficientemente flexible como para adaptar o seu uso ás nosas necesidades. Aínda así, tivemos moitas restricións impostas por hardware, arquitectura e prazos.
Hai unha gran variedade de solucións de monitorización, comezando por sistemas completos como , ou e rematando con solucións preparadas para a xestión da flota.
Inicialmente, esta última parecíanos unha solución ideal, pero algúns non tiñan un seguimento completo, outros tiñan capacidades moi limitadas das versións gratuítas e outros simplemente non cubrían os nosos "desexos" ou non eran o suficientemente flexibles como para adaptarse aos nosos escenarios. Algunhas simplemente están desfasadas.
Despois de analizar unha serie de solucións similares, chegamos rapidamente á conclusión de que sería máis fácil e rápido montar nós mesmos unha pila similar. Si, será un pouco máis complicado que implantar unha plataforma de xestión de flotas completamente preparada, pero non teremos que facer compromisos.
Case con certeza, en toda a enorme abundancia de solucións, xa hai unha preparada que nos conveña completamente, pero no noso caso foi moito máis rápido montar unha determinada pila pola nosa conta e personalizala "por nós mesmos" en lugar de probando produtos preparados.
Con todo isto, non nos esforzamos por montar nós mesmos unha plataforma de monitorización completa, senón que buscabamos as pilas "preparadas" máis funcionais, só coa posibilidade de configuralas de forma flexible.
(B) ELK?
A primeira solución que se considerou realmente foi a coñecida pila ELK.
De feito, debería chamarse BELK, porque todo comeza con Beats -
Por suposto, ELK é unha das solucións máis famosas e poderosas no campo da vixilancia, e máis aínda na recollida e procesamento de rexistros.
Pretendemos que ELK se utilizase para recoller rexistros e almacenar a longo prazo as métricas obtidas de Prometheus.
Para a visualización pode usar Grafan.
De feito, a nova pila ELK pode recoller métricas de forma independente (metricbeat) e Kibana tamén pode mostralas.
Pero aínda así, ELK xurdiu inicialmente a partir de rexistros e ata agora a funcionalidade das métricas ten unha serie de graves inconvenientes:
- Significativamente máis lento que Prometheus
- Intégrase en moitos menos lugares que Prometheus
- É difícil configurar alertas para eles
- As métricas ocupan moito espazo
- Configurar paneis con métricas en Kiban é moito máis complicado que en Grafan
En xeral, as métricas en ELK son pesadas e aínda non tan cómodas como noutras solucións, das que agora hai moito máis que Prometheus: TSDB, Victoria Metrics, Cortex, etc., etc. Por suposto, realmente gustaríame ter unha solución completa de inmediato, pero no caso de metricbeat había demasiados compromisos.
E a propia pila ELK ten unha serie de momentos difíciles:
- É pesado, ás veces incluso moi pesado se recolle unha cantidade bastante grande de datos
- Necesitas "saber cociñalo" - necesitas escalalo, pero isto non é trivial.
- Versión gratuíta reducida: a versión gratuíta non ten alerta normal e no momento da selección non había autenticación
Debo dicir que recentemente o último punto foi mellor e ademais (incluída a autenticación) o propio modelo de prezos comezou a cambiar.
Pero no momento no que íamos implantar esta solución, non había ningunha alerta.
Quizais puidésemos tentar construír algo usando ElastAlert ou outras solucións comunitarias, pero aínda así decidimos considerar outras alternativas.
Loki - Grafana - Prometeo
Polo momento, unha boa solución pode ser construír unha pila de seguimento baseada exclusivamente en Prometheus como provedor de métricas, Loki para rexistros e para a visualización podes usar o mesmo Grafana.
Desafortunadamente, no momento do inicio do piloto de vendas do proxecto (setembro-outubro de 19), Loki aínda estaba na versión beta 0.3-0.4, e no momento do inicio do desenvolvemento non podía considerarse como unha solución de produción. en absoluto.
Aínda non teño experiencia en usar Loki en proxectos serios, pero podo dicir que Promtail (un axente para recoller rexistros) funciona moi ben tanto para bare-metal como para pods en kubernetes.
MARCA
Quizais a alternativa máis valiosa (a única?) con todas as funcións á pila ELK agora só se pode chamar pila TICK: Telegraf, InfluxDB, Chronograf, Kapacitor.
Vou describir todos os compoñentes a continuación con máis detalle, pero a idea xeral é a seguinte:
- Telegraf - axente para a recollida de métricas
- InfluxDB - base de datos de métricas
- Kapacitor: procesador de métricas en tempo real para alertar
- Chronograf - panel web para visualización
Para InfluxDB, Kapacitor e Chronograf hai gráficos oficiais de timón que utilizamos para implementalos.
Cabe sinalar que na última versión de Influx 2.0 (beta), Kapacitor e Chronograf pasaron a formar parte de InfluxDB e xa non existen por separado.
Telegrafa
é un axente moi lixeiro para recoller métricas nunha máquina de estado.
Pode supervisar unha gran cantidade de todo, desde para
servidor .
Ten unha serie de vantaxes interesantes:
- Rápido e lixeiro (escrito en Go)
- Come unha cantidade mínima de recursos
- Push métricas por defecto
- Recopila todas as métricas necesarias
- Métricas do sistema sen ningunha configuración
- Métricas de hardware como información dos sensores
- É moi sinxelo engadir as túas propias métricas
- Moitos complementos fóra da caixa
- Recolle rexistros
Dado que as métricas push eran necesarias para nós, todas as outras vantaxes eran máis que agradables adicións.
A recollida de rexistros polo propio axente tamén é moi conveniente, xa que non é necesario conectar utilidades adicionais para rexistrar rexistros.
Influx ofrece a experiencia máis conveniente para traballar con rexistros se usas .
Telegraf é xeralmente un excelente axente para recoller métricas, aínda que non uses o resto da pila ICK.
Moitas persoas cruzan con ELK e outras bases de datos de series temporais por comodidade, xa que pode escribir métricas en case calquera lugar.
InfluxDB
InfluxDB é o núcleo principal da pila TICK, é dicir, unha base de datos de series temporais para métricas.
Ademais das métricas, Influx tamén pode almacenar rexistros, aínda que, en esencia, os rexistros son só as mesmas métricas, só que en lugar dos indicadores numéricos habituais, a función principal realízase mediante unha liña de texto de rexistro.
InfluxDB tamén está escrito en Go e parece funcionar moito máis rápido en comparación con ELK no noso clúster (non o máis potente).
Unha das vantaxes interesantes de Influx tamén incluiría unha API moi cómoda e rica para consultas de datos, que utilizamos de forma moi activa.
Desvantaxes - $$$ ou escalado?
A pila TICK só ten un inconveniente que descubrimos: el querida. Aínda máis.
Que ten a versión de pago que non ten a versión gratuíta?
Polo que puidemos entender, a única diferenza entre a versión de pago da pila TICK e a gratuíta son as capacidades de escalado.
É dicir, pode crear un clúster con alta dispoñibilidade só en .
Se queres HA completo, debes pagar ou usar unhas muletas. Hai un par de solucións comunitarias, por exemplo parece unha solución competente, pero está escrito que non é adecuado para a produción, así como
- unha solución sinxela con bombeo de datos a través de NATS (tamén haberá que escalar, pero pódese solucionar).
É unha mágoa, pero ambos parecen estar abandonados: non hai novos commits, supoño que o problema é o pronto lanzamento esperado da nova versión de Influx 2.0, na que moitas cousas serán diferentes (non hai información sobre escalando nel aínda).
Oficialmente hai unha versión gratuíta - de feito, este é un HA primitivo, pero só a través do equilibrio,
xa que todos os datos escribiranse en todas as instancias de InfluxDB detrás do equilibrador de carga.
Ten algúns como problemas potenciais con puntos de sobrescritura e a necesidade de crear bases para métricas con antelación
(o que ocorre automaticamente durante o traballo normal con InfluxDB).
Ademais , isto significa sobrecarga adicional para as métricas duplicadas (tanto de procesamento como de almacenamento) que quizais non necesites, pero non hai forma de separalas.
Métricas de Victoria?
Como resultado, a pesar de que estabamos completamente satisfeitos coa pila TICK en todo o que non fose o escalado de pago, decidimos ver se había algunha solución gratuíta que puidese substituír a base de datos InfluxDB, deixando os compoñentes T_CK restantes.
Hai moitas bases de datos de series temporais, pero a máis prometedora é Victoria Metrics, que ten unha serie de vantaxes:
- Rápido e sinxelo, polo menos segundo os resultados
- Hai unha versión clúster, sobre a que aínda hai boas críticas agora
- Ela pode esnaquizar
- Admite o protocolo InfluxDB
Non tiñamos a intención de construír unha pila completamente personalizada baseada en Victoria e a principal esperanza era que puidésemos usala como substituto para InfluxDB.
Desafortunadamente, isto non é posible, a pesar de que o protocolo InfluxDB é compatible, só funciona para gravar métricas; só a API de Prometheus está dispoñible "fóra", o que significa que non será posible configurar Chronograf nel.
Ademais, só se admiten valores numéricos para as métricas (utilizamos valores de cadea para as métricas personalizadas; máis sobre isto na sección ).
Obviamente, polo mesmo motivo, a máquina virtual non pode almacenar rexistros como fai Influx.
Ademais, hai que ter en conta que no momento de buscar a solución óptima, Victoria Metrics aínda non era tan popular, a documentación era moito menor e a funcionalidade era máis débil.
(Non recordo unha descrición detallada da versión do clúster e da fragmentación).
Selección base
Como resultado, decidiuse que para o piloto aínda nos limitaríamos a un único nodo InfluxDB.
Houbo varias razóns principais para esta elección:
- Gustounos moito toda a funcionalidade da pila TICK
- Xa conseguimos implantalo e funcionou moi ben
- Os prazos estaban esgotando e non quedaba moito tempo para probar outras opcións.
- Non esperábamos unha carga tan pesada
Non tivemos moitos scooters para a primeira fase do piloto, e as probas durante o desenvolvemento non revelaron ningún problema de rendemento.
Polo tanto, decidimos que para este proxecto un nodo de Influx sería suficiente para nós sen necesidade de escalar (ver conclusións ao final).
Decidimos a pila e a base, agora sobre os compoñentes restantes da pila TICK.
Kapacitor
Kapacitor forma parte da pila TICK, un servizo que pode supervisar as métricas que entran na base de datos en tempo real e realizar diversas accións baseadas en regras.
En xeral, sitúase como unha ferramenta para o seguimento de posibles anomalías e a aprendizaxe automática (non estou seguro de que estas funcións sexan demandadas), pero o caso máis popular do seu uso é o máis común: alertar.
Así o usamos para as notificacións. Configuramos alertas de Slack cando un scooter en particular se desconectaba, e o mesmo se fixo con cargadores intelixentes e compoñentes de infraestrutura importantes.
Isto permitiu responder rapidamente aos problemas, así como recibir notificacións de que todo volveu á normalidade.
Un exemplo sinxelo: unha batería adicional para alimentar a nosa "caixa" avariouse ou por algún motivo quedou sen enerxía; simplemente instalando unha nova, despois dun tempo deberíamos recibir unha notificación de que a funcionalidade do scooter foi restaurada.
En Influx 2.0, Kapacitor pasou a formar parte de DB
Cronógrafo
Vin moitas solucións de IU diferentes para o seguimento, pero podo dicir que en termos de funcionalidade e UX, nada se compara con Chronograf.
Comezamos a usar a pila TICK, curiosamente, con Grafan como interface web.
Non vou describir a súa funcionalidade; todo o mundo coñece as súas amplas posibilidades para configurar calquera cousa.
Non obstante, Grafana segue sendo un instrumento completamente universal, mentres que Chronograf está deseñado principalmente para o seu uso con Influx.
E, por suposto, grazas a isto, Chronograf pode permitirse unha funcionalidade moito máis intelixente ou conveniente.
Quizais a principal comodidade de traballar con Chronograf sexa que podes ver o interior do teu InfluxDB a través de Explora.
Parece que Grafana ten unha funcionalidade case idéntica, pero en realidade, a configuración dun panel en Chronograf pódese facer cuns poucos clics do rato (ao mesmo tempo mirando a visualización alí), mentres que en Grafana aínda terás tarde ou cedo. para editar a configuración JSON (por suposto que Chronograf permite cargar os teus dashas configurados a man e editalos como JSON se é necesario, pero nunca tiven que tocalos despois de crealos na IU).
Kibana ten capacidades moito máis ricas para crear paneis e controis para eles, pero a UX para tales operacións é moi complexa.
Será necesario un bo entendemento para crear un panel de control cómodo. E aínda que a funcionalidade dos paneis de Chronograf é menor, facelos e personalizalos é moito máis sinxelo.
Os paneis en si, ademais do agradable estilo visual, en realidade non son diferentes dos paneis de Grafana ou Kibana:
Este é o aspecto da xanela de consulta:
É importante ter en conta, entre outras cousas, que coñecendo os tipos de campos da base de datos InfluxDB, o propio cronógrafo ás veces pode axudarche automaticamente a escribir unha consulta ou a escoller a función de agregación correcta como media.
E, por suposto, Chronograf é o máis cómodo posible para ver rexistros. Parece así:
Por defecto, os rexistros de Influx están adaptados para usar syslog e, polo tanto, teñen un parámetro importante: a gravidade.
O gráfico da parte superior é especialmente útil; nel podes ver os erros que se producen e a cor inmediatamente mostra claramente se a gravidade é maior.
Un par de veces detectamos erros importantes deste xeito, indo a ver os rexistros da última semana e vimos un pico vermello.
Por suposto, o ideal sería configurar alertas para este tipo de erros, xa que xa tiñamos todo para iso.
Incluso activamos isto durante un tempo, pero no proceso de preparación do piloto resultou que estabamos recibindo bastantes erros (incluídos os do sistema como a indisponibilidade da rede LTE), que tamén "enviou spam" á canle Slack. moito, sen causar ningún problema.gran beneficio.
A solución correcta sería xestionar a maioría destes tipos de erros, axustar a gravidade para eles e só entón activar a alerta.
Deste xeito, só se publicarían en Slack os erros novos ou importantes. Simplemente non houbo tempo suficiente para tal configuración dados os prazos axustados.
Autenticación
Tamén vale a pena mencionar que Chronograf admite OAuth e OIDC como autenticación.
Isto é moi cómodo, xa que che permite conectalo facilmente ao teu servidor e crear un SSO completo.
No noso caso, o servidor era — utilizouse para conectarse á supervisión, pero o mesmo servidor tamén se utilizou para autenticar scooters e solicitudes ao back-end.
"Administrador"
O último compoñente que describirei é o noso "panel de administración" autoescrito en Vue.
Basicamente, é só un servizo autónomo que mostra información de scooter das nosas propias bases de datos, microservizos e datos de métricas de InfluxDB de forma simultánea.
Ademais, trasladáronse alí moitas funcións administrativas, como un reinicio de emerxencia ou a apertura remota dun bloqueo para o equipo de soporte.
Tamén había mapas. Xa mencionei que comezamos con Grafana en lugar de Chronograf, porque para Grafana os mapas están dispoñibles en forma de complementos, nos que poderiamos ver as coordenadas dos scooters. Desafortunadamente, as capacidades dos widgets de mapas para Grafana son moi limitadas e, como resultado, foi moito máis fácil escribir a túa propia aplicación web con mapas en poucos días, para non só ver as coordenadas no momento, senón tamén mostrar o percorrido realizado polo scooter, poder filtrar os datos no mapa, etc. (toda esa funcionalidade que non puidemos configurar nun simple panel).
Unha das vantaxes xa mencionadas de Influx é a capacidade de crear facilmente as súas propias métricas.
Isto permite que se use para unha gran variedade de escenarios.
Tentamos rexistrar alí toda a información útil: carga da batería, estado do bloqueo, rendemento do sensor, bluetooth, GPS e moitos outros controis de saúde.
Mostramos todo isto no panel de administración.
Por suposto, o criterio máis importante para nós foi o estado de funcionamento do scooter; de feito, Influx comproba isto e móstrao na sección Nodos con "luces verdes".
Isto faise pola función — usámolo para comprender o rendemento da nosa caixa e enviar esas mesmas alertas a Slack.
Por certo, puxemos o nome dos scooters polos nomes dos personaxes dos Simpsons; era tan conveniente distinguilos uns dos outros.
E en xeral foi máis divertido deste xeito. Frases como "Rapaces, Smithers está morto!" Escoitáronse constantemente.
Métricas de cadea
É importante que InfluxDB che permita almacenar non só valores numéricos, como é o caso de Victoria Metrics.
Parece que isto non é tan importante; despois de todo, ademais dos rexistros, pódese almacenar calquera métrica en forma de números (só engade mapeamento para estados coñecidos, unha especie de enumeración)?
No noso caso, houbo polo menos un escenario no que as métricas de cadea foron moi útiles.
Ocorreu que o provedor dos nosos "cargadores intelixentes" era un terceiro, non tiñamos control sobre o proceso de desenvolvemento e a información que podían proporcionar estes cargadores.
Como resultado, a API de carga estaba lonxe de ser ideal, pero o principal problema era que non sempre podíamos comprender o seu estado.
Aquí foi onde Influx acudiu ao rescate. Simplemente escribimos o estado da cadea que nos chegou ao campo da base de datos InfluxDB sen cambios.
Durante algún tempo, só chegaron valores como "en liña" e "sen conexión", en función da información que se mostraba no noso panel de administración e enviáronse notificacións a Slack. Non obstante, nalgún momento, tamén comezaron a aparecer alí valores como "desconectado".
Como se viu máis tarde, este estado enviouse unha vez despois de perder a conexión, se o cargador non podía establecer unha conexión co servidor despois dun certo número de intentos.
Así, se só utilizamos un conxunto fixo de valores, é posible que non vexamos estes cambios no firmware no momento adecuado.
E, en xeral, as métricas de cadea ofrecen moitas máis posibilidades de uso; pode rexistrar practicamente calquera información nelas. Aínda que, por suposto, tamén cómpre usar esta ferramenta con coidado.
Ademais das métricas habituais, tamén gravamos a información de localización GPS en InfluxDB. Isto foi moi útil para controlar a localización dos scooters no noso panel de administración.
De feito, sempre soubemos onde e que scooter estaba no momento que necesitabamos.
Isto foinos moi útil cando buscabamos un scooter (ver conclusións ao final).
Seguimento de infraestruturas
Ademais dos propios scooters, tamén necesitabamos supervisar toda a nosa infraestrutura (bastante extensa).
Unha arquitectura moi xeral parecía algo así:
Se destacamos unha pila de seguimento puro, parecerase así:
O que nos gustaría comprobar na nube é:
- Bases de datos
- chaveiro
- Microservizos
Dado que todos os nosos servizos na nube están situados en Kubernetes, sería bo recompilar información sobre o seu estado.
Afortunadamente, Telegraf fóra da caixa pode recoller un gran número de métricas sobre o estado do clúster de Kubernetes, e Chronograf ofrece de inmediato fermosos paneis para iso.
Vixiamos principalmente o rendemento dos pods e o consumo de memoria. En caso de caída, alertas en Slack.
Hai dúas formas de rastrexar os pods en Kubernetes: DaemonSet e Sidecar.
Ambos métodos descríbense en detalle .
Usamos Telegraf Sidecar e, ademais de métricas, recompilamos rexistros de pod.
No noso caso, tivemos que xogar cos troncos. A pesar de que Telegraf pode extraer rexistros da API de Docker, queriamos ter unha colección uniforme de rexistros cos nosos dispositivos finais e un syslog configurado para contedores para iso. Quizais esta solución non fose fermosa, pero non houbo queixas sobre o seu traballo e os rexistros mostráronse ben en Chronograf.
Monitorización de seguimento???
Ao final, xurdiu a vella cuestión do seguimento dos sistemas de vixilancia, pero afortunadamente, ou por desgraza, simplemente non tivemos tempo suficiente para iso.
Aínda que Telegraf pode enviar facilmente as súas propias métricas ou recoller métricas da base de datos InfluxDB para envialas ao mesmo Influx ou a outro lugar.
Descubrimentos
Que conclusións sacamos dos resultados do piloto?
Como podes facer un seguimento?
En primeiro lugar, a pila TICK cumpriu plenamente as nosas expectativas e deunos aínda máis oportunidades das que esperabamos inicialmente.
Toda a funcionalidade que necesitábamos estaba presente. Todo o que fixemos con el funcionou sen problemas.
Produtividade
O principal problema coa pila TICK na versión gratuíta é a falta de capacidades de escalado. Isto non foi un problema para nós.
Non recompilamos datos/cifras de carga exactas, pero recompilamos datos duns 30 scooters á vez.
Cada un deles recolleu máis de tres ducias de métricas. Ao mesmo tempo, recolléronse rexistros dos dispositivos. A recollida e o envío de datos producíronse cada 10 segundos.
É importante ter en conta que despois dunha semana e media do piloto, cando se corrixiron a maior parte dos "problemas da infancia" e xa se resolveron os problemas máis importantes, tivemos que reducir a frecuencia de envío de datos ao servidor para 30 segundos. Isto fíxose necesario porque o tráfico das nosas tarxetas SIM LTE comezou a desaparecer rapidamente.
A maior parte do tráfico foi consumido polos rexistros; as propias métricas, aínda cun intervalo de 10 segundos, practicamente non o desperdiciaron.
Como resultado, despois dun tempo desactivamos por completo a recollida de rexistros nos dispositivos, xa que os problemas específicos xa eran obvios mesmo sen a recollida constante.
Nalgúns casos, se aínda era necesario ver os rexistros, simplemente conectamos a través de WireGuard mediante VPN.
Tamén engadirei que cada ambiente separado estaba separado entre si e a carga descrita anteriormente só era relevante para o ambiente de produción.
No contorno de desenvolvemento, creamos unha instancia InfluxDB separada que seguiu recollendo datos cada 10 segundos e non atopamos ningún problema de rendemento.
TICK - ideal para proxectos pequenos e medianos
Con base nesta información, concluiría que a pila TICK é ideal para proxectos relativamente pequenos ou proxectos que definitivamente non esperan ningún HighLoad.
Se non tes miles de pods ou centos de máquinas, incluso unha instancia de InfluxDB xestionará a carga ben.
Nalgúns casos, pode estar satisfeito con Influx Relay como solución primitiva de alta dispoñibilidade.
E, por suposto, ninguén che impide configurar a escala "vertical" e simplemente asignar diferentes servidores para diferentes tipos de métricas.
Se non estás seguro da carga esperada dos servizos de monitorización, ou tes a garantía de ter/terá unha arquitectura moi "pesada", non recomendaría usar a versión gratuíta da pila TICK.
Por suposto, unha solución sinxela sería a compra - pero aquí non podo comentar dalgún xeito, xa que eu mesmo non coñezo as sutilezas. Ademais de que é moi caro e definitivamente non é apto para pequenas empresas.
Neste caso, hoxe recomendaríache buscar métricas a través de Victoria Metrics e rexistros usando Loki.
É certo, volverei facer unha reserva de que Loki/Grafana son moito menos cómodos (pola súa maior versatilidade) que os TICK preparados, pero son gratuítos.
É importante: toda a información aquí descrita é relevante para a versión Influx 1.8, polo momento Influx 2.0 está a piques de ser lanzado.
Aínda que non tiven a oportunidade de probalo en condicións de combate e é difícil sacar conclusións sobre melloras, a interface definitivamente foi aínda mellor, a arquitectura simplificouse (sen kapacitor e cronógrafo),
apareceron modelos ("función asasina" - ). Pero, desafortunadamente, polo momento, a versión 2 non ten a clave para a que escollemos a primeira versión: non hai colección de rexistros.
Esta funcionalidade tamén aparecerá en Influx 2.0, pero non puidemos atopar ningún prazo, nin sequera aproximado.
Como non facer plataformas IoT (agora)
Ao final, despois de lanzar o piloto, nós mesmos montamos a nosa propia pila de IoT completa, a falta dunha alternativa adecuada para os nosos estándares.
Non obstante, recentemente está dispoñible en versión Beta - É unha mágoa que non estivese alí cando comezamos a facer o proxecto.
Estamos completamente satisfeitos co resultado final e coa plataforma baseada en Ansible + TICK + WireGuard que montamos nós mesmos. Pero hoxe, recomendaríalle botar unha ollada máis atenta a Balena antes de tentar construír a túa propia plataforma IoT.
Porque, en definitiva, pode facer a maior parte do que fixemos, e OpenBalena é gratuíto e de código aberto.
Xa sabe non só enviar actualizacións, senón que xa está integrada unha VPN e adaptada para o seu uso nun ambiente IoT.
E recentemente, incluso lanzaron o seu , que se conectan facilmente co seu ecosistema.
Ei, e o scooter que falta?
Así que o scooter, "Ralph", desapareceu sen deixar rastro.
Inmediatamente corremos a mirar o mapa no noso "panel de administración", con datos de métricas GPS de InfluxDB.
Grazas aos datos de seguimento, determinamos facilmente que o scooter saíu do aparcamento ao redor das 21:00 horas do día pasado, conduciu aproximadamente media hora ata algunha zona e estivo estacionado ata as 5 da mañá xunto a algunha casa alemá.
Despois das 5 da mañá, non se recibiu ningún dato de seguimento; isto significaba que a batería adicional estaba completamente descargada ou que o atacante finalmente descubriu como eliminar o hardware intelixente do scooter.
A pesar diso, a policía aínda estaba chamada ao enderezo onde se atopaba o scooter. O scooter non estaba alí.
Non obstante, o dono da casa tamén se mostrou sorprendido por isto, xa que en realidade levou este scooter a casa desde a oficina onte á noite.
Segundo se viu, un dos empregados de apoio chegou pola mañá cedo e colleu o scooter, ao ver que a súa batería adicional estaba completamente descargada e levouno (a pé) ao aparcadoiro. E fallou a batería adicional debido á humidade.
Roubámosnos o scooter. Por certo, non sei como e quen resolveu entón o problema co caso policial, pero o seguimento funcionou perfectamente...
Fonte: www.habr.com