Hace un año lanzamos una versión piloto de un proyecto promocional para .
Inicialmente, el proyecto se llamó Road-To-Barcelona, luego se convirtió en Road-To-Berlin (de ahí R2B en las capturas de pantalla), y finalmente se llamó xRide.
La idea principal del proyecto era la siguiente: en lugar de tener un servicio centralizado de alquiler de coches o scooters (estamos hablando de scooters, también conocidos como motos eléctricas, no de kickscooters/scooters), queríamos crear una plataforma para el alquiler descentralizado. Sobre las dificultades que encontramos. .
Inicialmente, el proyecto se centró en los automóviles, pero debido a los plazos, las largas comunicaciones con los fabricantes y una gran cantidad de restricciones de seguridad, se eligieron scooters eléctricos para el piloto.
El usuario instaló una aplicación iOS o Android en el teléfono, se acercó al scooter que le gustaba, después de lo cual el teléfono y el scooter establecieron una conexión de igual a igual, se intercambió ETH y el usuario pudo iniciar el viaje encendiendo el scooter a través de el teléfono. Al final del viaje, también era posible pagar el viaje utilizando Ethereum desde la billetera del usuario en el teléfono.
Además de los scooters, el usuario vio en la aplicación "cargadores inteligentes", al visitarlos, el usuario podía cambiar él mismo la batería actual si estaba baja.
Así es en general nuestro piloto, lanzado en septiembre del año pasado en dos ciudades alemanas: Bonn y Berlín.
Y entonces, un día, temprano en la mañana, en Bonn, nuestro equipo de soporte (ubicado en el lugar para mantener los scooters en buen estado) fue alertado: uno de los scooters había desaparecido sin dejar rastro.
¿Cómo encontrarlo y devolverlo?
En este artículo hablaré de esto, pero primero, de cómo construimos nuestra propia plataforma de IoT y cómo la monitoreamos.
¿Qué y por qué monitorear: scooters, infraestructuras, estaciones de carga?
Entonces, ¿qué queríamos monitorear en nuestro proyecto?
En primer lugar, se trata de los propios scooters: los scooters eléctricos en sí son bastante caros, no se puede lanzar un proyecto de este tipo sin estar suficientemente preparado; si es posible, conviene recopilar la mayor cantidad de información posible sobre los scooters: sobre su ubicación, nivel de carga. , etc.
Además, me gustaría controlar el estado de nuestra propia infraestructura de TI: bases de datos, servicios y todo lo que necesitan para funcionar. También era necesario monitorear el estado de los “cargadores inteligentes”, por si se averiaban o se quedaban sin baterías completas.
Scooters
¿Cuáles eran nuestros patinetes y qué queríamos saber sobre ellos?
Lo primero y más importante son las coordenadas GPS, ya que gracias a ellas podemos entender dónde están y hacia dónde se mueven.
Lo siguiente es la carga de la batería, gracias a la cual podemos determinar que la carga de los patinetes está llegando a su fin y enviar un exprimidor o al menos avisar al usuario.
Por supuesto, también es necesario comprobar qué está pasando con nuestros componentes de Hardware:
- ¿Funciona el bluetooth?
- ¿Funciona el módulo GPS?
- También tuvimos el problema de que el GPS podía enviar coordenadas incorrectas y quedarse atascado, y esto sólo se podía determinar mediante comprobaciones adicionales en el scooter.
y notificar al soporte lo antes posible para resolver el problema
- También tuvimos el problema de que el GPS podía enviar coordenadas incorrectas y quedarse atascado, y esto sólo se podía determinar mediante comprobaciones adicionales en el scooter.
Y por último: comprobaciones del software, empezando por el sistema operativo y el procesador, la red y la carga del disco, terminando con comprobaciones de nuestros propios módulos que son más específicos para nosotros (, ).
Materiales
¿Cuál fue nuestra parte “de hierro”?
Teniendo en cuenta el plazo más corto posible y la necesidad de creación rápida de prototipos, elegimos la opción más sencilla para la implementación y selección de componentes: Raspberry Pi.
Además del Rpi en sí, teníamos una placa personalizada (que nosotros mismos desarrollamos y encargamos a China para acelerar el proceso de ensamblaje de la solución final) y un conjunto de componentes: un relé (para encender/apagar el scooter), un lector de carga de batería, un módem, antenas. Todo esto estaba empaquetado de forma compacta en una “caja xRide” especial.
Cabe destacar también que toda la caja estaba alimentada por un power bank adicional, que a su vez se alimentaba de la batería principal del scooter.
Esto hizo posible utilizar el monitoreo y encender el scooter incluso después del final del viaje, ya que la batería principal se apagó inmediatamente después de girar la llave de encendido a la posición "apagado".
¿Estibador? ¿Linux simple? y despliegue
Volvamos al seguimiento, entonces Raspberry: ¿qué tenemos?
Una de las primeras cosas que quisimos utilizar para acelerar el proceso de implementación, actualización y entrega de componentes a dispositivos físicos fue Docker.
Desafortunadamente, rápidamente quedó claro que Docker en RPi, aunque funciona, tiene muchos gastos generales, particularmente en términos de consumo de energía.
La diferencia al usar el sistema operativo "nativo", aunque no tan fuerte, fue suficiente para que tuviéramos cuidado con la posibilidad de perder la carga demasiado rápido.
La segunda razón fue una de nuestras bibliotecas asociadas en Node.js (¡sic!), el único componente del sistema que no fue escrito en Go/C/C++.
Los autores de la biblioteca no tuvieron tiempo de proporcionar una versión funcional en ninguno de los idiomas "nativos".
No sólo el nodo en sí no es la solución más elegante para dispositivos de bajo rendimiento, sino que la biblioteca en sí consumía muchos recursos.
Nos dimos cuenta de que, incluso si quisiéramos, usar Docker sería una sobrecarga para nosotros. La elección se hizo a favor del sistema operativo nativo y trabajar directamente bajo él.
OS
Como resultado, nuevamente elegimos la opción más simple como sistema operativo y usamos Raspbian (compilación de Debian para Pi).
Escribimos todo nuestro software en Go, por lo que también escribimos el módulo de agente de hardware principal en nuestro sistema en Go.
Es él quien se encarga de trabajar con GPS, Bluetooth, leer la carga, encender el patinete, etc.
Desplegar
Inmediatamente surgió la pregunta sobre la necesidad de implementar un mecanismo para entregar actualizaciones a los dispositivos (OTA), tanto actualizaciones de nuestro agente/aplicación como actualizaciones del sistema operativo/firmware (ya que las nuevas versiones del agente podrían requerir actualizaciones del kernel). o componentes del sistema, bibliotecas, etc.).
Después de un análisis bastante largo del mercado, resultó que existen bastantes soluciones para entregar actualizaciones al dispositivo.
Desde utilidades relativamente simples, en su mayoría orientadas a actualización/arranque dual, como swupd/SWUpdate/OSTree, hasta plataformas completas como Mender y Balena.
En primer lugar, decidimos que estábamos interesados en soluciones integrales, por lo que la elección recayó inmediatamente en las plataformas.
Sí mismo fue excluido debido al hecho de que en realidad usa el mismo Docker dentro de su balenaEngine.
Pero observo que a pesar de esto, terminamos usando constantemente su producto. para firmware flash en tarjetas SD: una utilidad simple y extremadamente conveniente para esto.
Por lo tanto, al final la elección recayó en . Mender es una plataforma completa para ensamblar, entregar e instalar firmware.
En general, la plataforma se ve muy bien, pero nos tomó alrededor de una semana y media construir la versión correcta de nuestro firmware usando Mender Builder.
Y cuanto más nos sumergimos en las complejidades de su uso, más claro quedó que para implementarlo por completo necesitaríamos mucho más tiempo del que teníamos.
Lamentablemente, nuestros plazos ajustados nos obligaron a abandonar el uso de Mender y elegir uno aún más simple.
Ansible
La solución más sencilla en nuestra situación fue utilizar Ansible. Un par de manuales fueron suficientes para empezar.
Su esencia era que simplemente nos conectamos desde el host (servidor CI) a través de ssh a nuestros rasberries y les distribuimos actualizaciones.
Al principio, todo era simple: tenías que estar en la misma red que los dispositivos, el vertido se realizaba a través de Wi-Fi.
En la oficina había simplemente una docena de frambuesas de prueba conectadas a la misma red, cada dispositivo tenía una dirección IP estática también especificada en Ansible Inventory.
Fue Ansible quien entregó nuestro agente de monitoreo a los dispositivos finales.
3G / LTE
Desafortunadamente, este caso de uso para Ansible solo podía funcionar en modo de desarrollo antes de que tuviéramos scooters reales.
Porque los scooters, como comprenderá, no están conectados a un enrutador Wi-Fi, esperando constantemente actualizaciones a través de la red.
En realidad, los scooters no pueden tener otra conexión que no sea 3G/LTE móvil (y aun así no todo el tiempo).
Esto impone inmediatamente muchos problemas y limitaciones, como baja velocidad de conexión y comunicación inestable.
Pero lo más importante es que en una red 3G/LTE no podemos confiar simplemente en una IP estática asignada a la red.
Algunos proveedores de tarjetas SIM solucionan esto en parte; incluso hay tarjetas SIM especiales diseñadas para dispositivos IoT con direcciones IP estáticas. Pero no teníamos acceso a dichas tarjetas SIM y no podíamos utilizar direcciones IP.
Por supuesto, hubo ideas para hacer algún tipo de registro de direcciones IP, también conocido como descubrimiento de servicios, en algún lugar como Consul, pero tuvimos que abandonar esas ideas, ya que en nuestras pruebas la dirección IP podía cambiar con demasiada frecuencia, lo que generaba una gran inestabilidad.
Por esta razón, el uso más conveniente para entregar métricas no sería usar el modelo pull, donde acudiríamos a los dispositivos para obtener las métricas necesarias, sino push, entregando métricas desde el dispositivo directamente al servidor.
VPN
Como solución a este problema, elegimos VPN, específicamente .
Los clientes (scooters) al inicio del sistema se conectaron al servidor VPN y pudieron conectarse a ellos. Este túnel se utilizó para entregar actualizaciones.
En teoría, el mismo túnel podría usarse para monitorear, pero dicha conexión era más complicada y menos confiable que una simple conexión.
Recursos en la nube
Por último, es necesario monitorizar nuestros servicios en la nube y bases de datos, ya que para ello utilizamos Kubernetes, idealmente para que desplegar la monitorización en el cluster sea lo más sencillo posible. Lo ideal es utilizar , ya que para el despliegue lo utilizamos en la mayoría de los casos. Y, por supuesto, para monitorear la nube es necesario utilizar las mismas soluciones que para los propios scooters.
Dado
Uf, parece que hemos resuelto la descripción, hagamos una lista de lo que necesitábamos al final:
- Una solución rápida, ya que el seguimiento es necesario ya durante el proceso de desarrollo.
- Volumen/cantidad: se necesitan muchas métricas
- Se requiere recopilación de registros
- Fiabilidad: los datos son fundamentales para el éxito del lanzamiento
- No puedes usar el modelo pull, necesitas empujar
- Necesitamos un monitoreo unificado no solo del hardware, sino también de la nube.
La imagen final se parecía a esto.
Selección de pila
Entonces, nos enfrentamos a la cuestión de elegir una pila de seguimiento.
En primer lugar, buscábamos la solución todo en uno más completa que cubriera simultáneamente todos nuestros requisitos, pero que al mismo tiempo fuera lo suficientemente flexible como para adaptar su uso a nuestras necesidades. Aún así, nos impusieron muchas restricciones por hardware, arquitectura y plazos.
Existe una gran variedad de soluciones de monitorización, empezando por sistemas completos como , o y terminando con soluciones listas para usar para la gestión de flotas.
Inicialmente, esta última parecía una solución ideal para nosotros, pero algunos no tenían un monitoreo completo, otros tenían capacidades muy limitadas de las versiones gratuitas y otros simplemente no cubrían nuestros "deseos" o no eran lo suficientemente flexibles para adaptarse a nuestros escenarios. Algunos simplemente están desactualizados.
Después de analizar varias soluciones similares, rápidamente llegamos a la conclusión de que sería más fácil y rápido montar una pila similar nosotros mismos. Sí, será un poco más complicado que implementar una plataforma de gestión de flotas completamente lista para usar, pero no tendremos que hacer concesiones.
Es casi seguro que, entre toda la enorme abundancia de soluciones, ya existe una ya preparada que se adaptaría perfectamente a nosotros, pero en nuestro caso fue mucho más rápido ensamblar una determinada pila por nuestra cuenta y personalizarla "para nosotros mismos" que probar productos preparados.
Con todo esto, no nos esforzamos por ensamblar una plataforma de monitoreo completa nosotros mismos, sino que buscamos las pilas "listas para usar" más funcionales, solo con la capacidad de configurarlas de manera flexible.
(B)ALCE?
La primera solución que se consideró fue la conocida pila ELK.
De hecho, debería llamarse BELK, porque todo empieza con Beats. -
Por supuesto, ELK es una de las soluciones más famosas y poderosas en el campo del monitoreo, y más aún en la recopilación y procesamiento de registros.
Teníamos la intención de que ELK se utilizara para recopilar registros y también para el almacenamiento a largo plazo de métricas obtenidas de Prometheus.
Para la visualización puedes utilizar Grafan.
De hecho, la nueva pila ELK puede recopilar métricas de forma independiente (metricbeat) y Kibana también puede mostrarlas.
Pero aún así, ELK inicialmente surgió de los registros y hasta ahora la funcionalidad de las métricas tiene una serie de inconvenientes graves:
- Significativamente más lento que Prometheus
- Se integra en muchos menos lugares que Prometheus
- Es difícil configurar alertas para ellos.
- Las métricas ocupan mucho espacio
- Configurar paneles con métricas en Kiban es mucho más complicado que en Grafan
En general, las métricas en ELK son pesadas y aún no tan convenientes como en otras soluciones, de las cuales ahora hay mucho más que Prometheus: TSDB, Victoria Metrics, Cortex, etc., etc. Por supuesto, me gustaría mucho tener una solución todo en uno completa de inmediato, pero en el caso de metricbeat hubo demasiados compromisos.
Y la pila ELK en sí tiene varios momentos difíciles:
- Es pesado, a veces incluso muy pesado si recopilas una cantidad de datos bastante grande.
- Es necesario "saber cocinarlo", es necesario escalarlo, pero esto no es trivial.
- Versión gratuita simplificada: la versión gratuita no tiene alertas normales y en el momento de la selección no había autenticación
Debo decir que recientemente el último punto ha mejorado y además (incluida la autenticación), el modelo de precios en sí comenzó a cambiar.
Pero en el momento en que íbamos a implementar esta solución, no hubo ninguna alerta.
Quizás podríamos haber intentado crear algo usando ElastAlert u otras soluciones comunitarias, pero aun así decidimos considerar otras alternativas.
Loki - Grafana - Prometeo
Por el momento, una buena solución podría ser crear una pila de monitoreo basada exclusivamente en Prometheus como proveedor de métricas, Loki para registros y, para visualización, puede usar el mismo Grafana.
Desafortunadamente, en el momento del inicio del piloto de ventas del proyecto (septiembre-octubre de 19), Loki todavía estaba en la versión beta 0.3-0.4, y en el momento del inicio del desarrollo no podía considerarse como una solución de producción. en absoluto.
Todavía no tengo experiencia en el uso de Loki en proyectos serios, pero puedo decir que Promtail (un agente para recopilar registros) funciona muy bien tanto para bare metal como para pods en kubernetes.
GARRAPATA
Quizás la alternativa más valiosa (¿la única?) con todas las funciones a la pila ELK ahora solo pueda llamarse pila TICK: Telegraf, InfluxDB, Chronograf, Kapacitor.
Describiré todos los componentes a continuación con más detalle, pero la idea general es la siguiente:
- Telegraf - agente de recopilación de métricas
- InfluxDB - base de datos de métricas
- Kapacitor: procesador de métricas en tiempo real para alertas
- Chronograf - panel web para visualización
Para InfluxDB, Kapacitor y Chronograf existen gráficos de timón oficiales que utilizamos para implementarlos.
Cabe señalar que en la última versión de Influx 2.0 (beta), Kapacitor y Chronograf pasaron a formar parte de InfluxDB y ya no existen por separado.
Telégrafo
es un agente muy ligero para recopilar métricas en una máquina de estados.
Puede monitorear una gran cantidad de todo, desde a
servidor .
Tiene una serie de ventajas interesantes:
- Rápido y ligero (escrito en Go)
- Consume una cantidad mínima de recursos.
- Enviar métricas de forma predeterminada
- Recoge todas las métricas necesarias
- Métricas del sistema sin ninguna configuración
- Métricas de hardware como información de sensores.
- Es muy fácil agregar tus propias métricas.
- Muchos complementos listos para usar
- Recoge registros
Como las métricas de empuje eran necesarias para nosotros, todas las demás ventajas fueron adiciones más que agradables.
La recopilación de registros por parte del propio agente también es muy conveniente, ya que no es necesario conectar utilidades adicionales para registrar registros.
Influx ofrece la experiencia más conveniente para trabajar con registros si usa .
Telegraf es generalmente un gran agente para recopilar métricas, incluso si no utiliza el resto de la pila ICK.
Mucha gente lo cruza con ELK y otras bases de datos de series temporales por conveniencia, ya que puede escribir métricas en casi cualquier lugar.
Influjo DB
InfluxDB es el núcleo principal de la pila TICK, es decir, una base de datos de series temporales para métricas.
Además de las métricas, Influx también puede almacenar registros, aunque, en esencia, los registros son las mismas métricas, solo que en lugar de los indicadores numéricos habituales, la función principal se lleva a cabo mediante una línea de texto de registro.
InfluxDB también está escrito en Go y parece ejecutarse mucho más rápido en comparación con ELK en nuestro clúster (no el más potente).
Una de las ventajas interesantes de Influx también incluiría una API rica y muy conveniente para consultas de datos, que utilizamos de manera muy activa.
Desventajas: ¿$$$ o escalamiento?
La pila TICK tiene sólo un inconveniente que descubrimos: Дорогой. Aún más.
¿Qué tiene la versión paga que no tiene la versión gratuita?
Hasta donde pudimos entender, la única diferencia entre la versión paga de TICK stack y la gratuita son las capacidades de escalabilidad.
Es decir, puede generar un clúster con alta disponibilidad solo en .
Si desea HA en toda regla, deberá pagar o utilizar algunas muletas. Hay un par de soluciones comunitarias, por ejemplo parece una solución competente, pero está escrito que no es adecuada para la producción, así como
- una solución sencilla con transferencia de datos a través de NATS (también habrá que ampliarla, pero esto se puede solucionar).
Es una pena, pero ambos parecen estar abandonados: no hay nuevas confirmaciones, supongo que el problema es el lanzamiento pronto esperado de la nueva versión de Influx 2.0, en la que muchas cosas serán diferentes (no hay información sobre escalando en él todavía).
Oficialmente existe una versión gratuita. - de hecho, este es un HA primitivo, pero solo mediante equilibrio,
ya que todos los datos se escribirán en todas las instancias de InfluxDB detrás del equilibrador de carga.
el tiene algunos como problemas potenciales con la sobrescritura de puntos y la necesidad de crear bases para las métricas por adelantado
(lo que ocurre automáticamente durante el trabajo normal con InfluxDB).
Además de , esto significa una sobrecarga adicional para métricas duplicadas (tanto de procesamiento como de almacenamiento) que quizás no necesite, pero no hay forma de separarlas.
¿Métricas de Victoria?
Como resultado, a pesar de que estábamos completamente satisfechos con la pila TICK en todo excepto en el escalado pago, decidimos ver si había alguna solución gratuita que pudiera reemplazar la base de datos InfluxDB, dejando los componentes restantes de T_CK.
Hay muchas bases de datos de series temporales, pero la más prometedora es Victoria Metrics, tiene una serie de ventajas:
- Rápido y fácil, al menos según los resultados.
- Existe una versión en clúster, sobre la que ahora incluso hay buenas críticas.
- ella puede fragmentarse
- Soporta el protocolo InfluxDB
No teníamos la intención de crear una pila completamente personalizada basada en Victoria y la principal esperanza era que pudiéramos usarla como un reemplazo directo para InfluxDB.
Desafortunadamente, esto no es posible, a pesar de que el protocolo InfluxDB es compatible, solo funciona para registrar métricas; solo la API de Prometheus está disponible "afuera", lo que significa que no será posible configurar Chronograf en ella.
Además, solo se admiten valores numéricos para las métricas (usamos valores de cadena para las métricas personalizadas; más sobre esto en la sección ).
Obviamente, por la misma razón, la VM no puede almacenar registros como lo hace Influx.
Además, cabe señalar que en el momento de buscar la solución óptima, Victoria Metrics aún no era tan popular, la documentación era mucho menor y la funcionalidad era más débil.
(No recuerdo una descripción detallada de la versión del clúster y la fragmentación).
Selección de base
Como resultado, se decidió que para el piloto todavía nos limitaríamos a un único nodo InfluxDB.
Hubo varias razones principales para esta elección:
- Realmente nos gustó toda la funcionalidad de la pila TICK.
- Ya logramos implementarlo y funcionó muy bien.
- Los plazos se estaban acabando y no quedaba mucho tiempo para probar otras opciones.
- No esperábamos una carga tan pesada.
No teníamos muchos scooters para la primera fase del piloto y las pruebas durante el desarrollo no revelaron ningún problema de rendimiento.
Por lo tanto, decidimos que para este proyecto un nodo Influx sería suficiente para nosotros sin necesidad de escalar (ver conclusiones al final).
Hemos decidido la pila y la base; ahora hablaremos de los componentes restantes de la pila TICK.
condensador
Kapacitor es parte de la pila TICK, un servicio que puede monitorear las métricas que ingresan a la base de datos en tiempo real y realizar diversas acciones basadas en reglas.
En general, se posiciona como una herramienta para el seguimiento de posibles anomalías y el aprendizaje automático (no estoy seguro de que estas funciones tengan demanda), pero el caso más popular de su uso es más común: las alertas.
Así lo usamos para las notificaciones. Configuramos alertas de Slack cuando un scooter en particular se desconectaba, y se hizo lo mismo con los cargadores inteligentes y componentes de infraestructura importantes.
Esto permitió responder rápidamente a los problemas, así como recibir notificaciones de que todo había vuelto a la normalidad.
Un ejemplo sencillo: una batería adicional para alimentar nuestra “caja” se ha estropeado o por algún motivo se ha quedado sin carga, con solo instalar una nueva, al cabo de un tiempo deberíamos recibir una notificación de que la funcionalidad del patinete ha sido restablecida.
En Influx 2.0 Kapacitor pasó a formar parte de DB
Cronógrafo
He visto muchas soluciones de UI diferentes para monitoreo, pero puedo decir que en términos de funcionalidad y UX, nada se compara con Chronograf.
Comenzamos a usar la pila TICK, por extraño que parezca, con Grafan como interfaz web.
No describiré su funcionalidad, todos conocen sus amplias posibilidades para configurar cualquier cosa.
Sin embargo, Grafana sigue siendo un instrumento completamente universal, mientras que Chronograf está diseñado principalmente para usarse con Influx.
Y, por supuesto, gracias a esto, Chronograf puede permitirse una funcionalidad mucho más inteligente o cómoda.
Quizás la principal ventaja de trabajar con Chronograf es que puede ver el interior de su InfluxDB a través de Explore.
Parecería que Grafana tiene una funcionalidad casi idéntica, pero en realidad, configurar un panel en Chronograf se puede hacer con unos pocos clics del mouse (mientras mira la visualización allí), mientras que en Grafana, tarde o temprano, aún tendrá para editar la configuración JSON (por supuesto, Chronograf permite cargar sus dashas configurados manualmente y editarlos como JSON si es necesario, pero nunca tuve que tocarlos después de crearlos en la interfaz de usuario).
Kibana tiene capacidades mucho más ricas para crear paneles y controles para ellos, pero la UX para tales operaciones es muy compleja.
Se necesitará una buena comprensión para crear un panel conveniente. Y aunque la funcionalidad de los paneles de Chronograf es menor, crearlos y personalizarlos es mucho más sencillo.
Los paneles en sí, aparte del agradable estilo visual, en realidad no se diferencian de los paneles de Grafana o Kibana:
Así es como se ve la ventana de consulta:
Es importante tener en cuenta, entre otras cosas, que al conocer los tipos de campos en la base de datos de InfluxDB, el propio cronógrafo a veces puede ayudarle automáticamente a escribir una consulta o elegir la función de agregación correcta, como la media.
Y, por supuesto, Chronograf es lo más conveniente posible para ver registros. Se parece a esto:
De forma predeterminada, los registros de Influx están diseñados para usar syslog y, por lo tanto, tienen un parámetro importante: la gravedad.
El gráfico de la parte superior es especialmente útil, en él se pueden ver los errores que se producen y el color muestra inmediatamente claramente si la gravedad es mayor.
Un par de veces detectamos errores importantes de esta manera, al ver los registros de la última semana y ver un pico rojo.
Por supuesto, lo ideal sería configurar alertas para este tipo de errores, ya que ya teníamos todo para ello.
Incluso lo activamos por un tiempo, pero en el proceso de preparación del piloto resultó que recibimos muchos errores (incluidos errores del sistema como la falta de disponibilidad de la red LTE), que también "enviaban spam" al canal Slack. Mucho, sin causar ningún problema, gran beneficio.
La solución correcta sería manejar la mayoría de estos tipos de errores, ajustar su gravedad y solo entonces habilitar las alertas.
De esta manera, sólo se publicarán en Slack los errores nuevos o importantes. Simplemente no hubo suficiente tiempo para tal configuración debido a los ajustados plazos.
Autentificación
También vale la pena mencionar que Chronograf admite OAuth y OIDC como autenticación.
Esto es muy conveniente, ya que le permite conectarlo fácilmente a su servidor y crear SSO completo.
En nuestro caso, el servidor era — se usó para conectarse al monitoreo, pero el mismo servidor también se usó para autenticar scooters y solicitudes al back-end.
"Administración"
El último componente que describiré es nuestro “panel de administración” escrito por nosotros mismos en Vue.
Básicamente, es solo un servicio independiente que muestra información del scooter desde nuestras propias bases de datos, microservicios y datos de métricas de InfluxDB simultáneamente.
Además, muchas funciones administrativas se trasladaron allí, como un reinicio de emergencia o abrir un candado de forma remota para el equipo de soporte.
También había mapas. Ya mencioné que comenzamos con Grafana en lugar de Chronograf, porque para Grafana hay mapas disponibles en forma de complementos, en los que podemos ver las coordenadas de los scooters. Desafortunadamente, las capacidades de los widgets de mapas para Grafana son muy limitadas y, como resultado, fue mucho más fácil escribir su propia aplicación web con mapas en unos pocos días, para no solo ver las coordenadas en este momento, sino también mostrarlas. la ruta que sigue el patinete, poder filtrar los datos en el mapa, etc. (toda esa funcionalidad que no podríamos configurar en un simple panel de control).
Una de las ventajas ya mencionadas de Influx es la capacidad de crear fácilmente tus propias métricas.
Esto permite que se utilice para una gran variedad de escenarios.
Intentamos registrar toda la información útil allí: carga de la batería, estado de bloqueo, rendimiento del sensor, bluetooth, GPS y muchas otras comprobaciones de estado.
Mostramos todo esto en el panel de administración.
Por supuesto, el criterio más importante para nosotros fue el estado de funcionamiento del scooter; de hecho, Influx lo comprueba él mismo y lo muestra con "luces verdes" en la sección Nodos.
Esto se hace mediante la función – lo usamos para comprender el rendimiento de nuestra caja y enviar esas mismas alertas a Slack.
Por cierto, le pusimos a los scooters el nombre de los personajes de Los Simpson, era muy cómodo distinguirlos entre sí.
Y en general fue más divertido así. Constantemente se escuchaban frases como “¡Chicos, Smithers está muerto!”.
Métricas de cadena
Es importante que InfluxDB te permita almacenar no solo valores numéricos, como es el caso de Victoria Metrics.
Parecería que esto no es tan importante; después de todo, además de los registros, cualquier métrica se puede almacenar en forma de números (simplemente agregue mapeo para estados conocidos, ¿una especie de enumeración)?
En nuestro caso, hubo al menos un escenario en el que las métricas de cadenas fueron muy útiles.
Dio la casualidad de que el proveedor de nuestros “cargadores inteligentes” era un tercero, no teníamos control sobre el proceso de desarrollo ni sobre la información que estos cargadores podían suministrar.
Como resultado, la API de carga estaba lejos de ser ideal, pero el principal problema era que no siempre podíamos entender su estado.
Aquí es donde Influx acudió al rescate. Simplemente escribimos el estado de la cadena que nos llegó en el campo de la base de datos de InfluxDB sin cambios.
Durante algún tiempo, solo llegaron valores como "en línea" y "fuera de línea", según la información que se mostraba en nuestro panel de administración y las notificaciones se enviaban a Slack. Sin embargo, en algún momento también empezaron a aparecer allí valores como “desconectados”.
Como resultó más tarde, este estado se enviaba una vez después de una pérdida de conexión, si el cargador no podía establecer una conexión con el servidor después de un cierto número de intentos.
Por lo tanto, si solo usáramos un conjunto fijo de valores, es posible que no veamos estos cambios en el firmware en el momento adecuado.
Y, en general, las métricas de cadenas ofrecen muchas más posibilidades de uso; puede registrar prácticamente cualquier información en ellas. Aunque, por supuesto, también es necesario utilizar esta herramienta con cuidado.
Además de las métricas habituales, también registramos información de ubicación GPS en InfluxDB. Esto fue increíblemente útil para monitorear la ubicación de los scooters en nuestro panel de administración.
De hecho, siempre supimos dónde y qué scooter estaba en el momento que necesitábamos.
Esto nos resultó muy útil cuando buscábamos un scooter (ver conclusiones al final).
Monitoreo de infraestructura
Además de los scooters en sí, también necesitábamos monitorear toda nuestra (bastante extensa) infraestructura.
Una arquitectura muy general se veía así:
Si destacamos una pila de monitoreo pura, se ve así:
Lo que nos gustaría comprobar en la nube es:
- Bases de datos
- Capa clave
- Microservicios
Dado que todos nuestros servicios en la nube están ubicados en Kubernetes, sería bueno recopilar información sobre su estado.
Afortunadamente, Telegraf puede recopilar de fábrica una gran cantidad de métricas sobre el estado del clúster de Kubernetes, y Chronograf ofrece inmediatamente hermosos paneles para esto.
Monitoreamos principalmente el rendimiento de los pods y el consumo de memoria. En caso de caída, alertas en Slack.
Hay dos formas de realizar un seguimiento de los pods en Kubernetes: DaemonSet y Sidecar.
Ambos métodos se describen en detalle. .
Usamos Telegraf Sidecar y, además de las métricas, recopilamos registros de pods.
En nuestro caso, tuvimos que retocar los troncos. A pesar de que Telegraf puede extraer registros de la API de Docker, queríamos tener una colección uniforme de registros con nuestros dispositivos finales y configuramos syslog para contenedores para esto. Quizás esta solución no fue hermosa, pero no hubo quejas sobre su trabajo y los registros se mostraron bien en Chronograf.
Monitoreo de monitoreo???
Al final surgió la antigua cuestión de controlar los sistemas de vigilancia, pero afortunadamente o desafortunadamente simplemente no tuvimos suficiente tiempo para ello.
Aunque Telegraf puede enviar fácilmente sus propias métricas o recopilar métricas de la base de datos de InfluxDB para enviarlas al mismo Influx o a otro lugar.
Hallazgos
¿Qué conclusiones sacamos de los resultados del piloto?
¿Cómo se puede hacer el seguimiento?
En primer lugar, la pila TICK cumplió plenamente con nuestras expectativas y nos brindó incluso más oportunidades de las que esperábamos inicialmente.
Toda la funcionalidad que necesitábamos estaba presente. Todo lo que hicimos con él funcionó sin problemas.
Rendimiento
El principal problema con la pila TICK en la versión gratuita es la falta de capacidades de escalado. Esto no fue un problema para nosotros.
No recopilamos datos/cifras de carga exactas, pero recopilamos datos de unos 30 scooters a la vez.
Cada uno de ellos recopiló más de tres docenas de métricas. Al mismo tiempo, se recopilaron registros de los dispositivos. La recolección y envío de datos se produjo cada 10 segundos.
Es importante señalar que después de una semana y media del piloto, cuando la mayor parte de los “problemas de la infancia” estaban corregidos y los problemas más importantes ya estaban resueltos, tuvimos que reducir la frecuencia de envío de datos al servidor para 30 segundos. Esto se hizo necesario porque el tráfico en nuestras tarjetas SIM LTE comenzó a desaparecer rápidamente.
La mayor parte del tráfico fue consumida por los registros, las métricas mismas, incluso con un intervalo de 10 segundos, prácticamente no lo desperdiciaron.
Como resultado, después de un tiempo desactivamos por completo la recopilación de registros en los dispositivos, ya que problemas específicos ya eran obvios incluso sin una recopilación constante.
En algunos casos, si aún era necesario ver los registros, simplemente nos conectamos a través de WireGuard a través de VPN.
También agregaré que cada entorno individual estaba separado entre sí y que la carga descrita anteriormente era relevante solo para el entorno de producción.
En el entorno de desarrollo, creamos una instancia de InfluxDB separada que continuó recopilando datos cada 10 segundos y no tuvimos ningún problema de rendimiento.
TICK: ideal para proyectos pequeños y medianos
Con base en esta información, concluiría que la pila TICK es ideal para proyectos relativamente pequeños o proyectos que definitivamente no esperan ninguna carga alta.
Si no tiene miles de pods o cientos de máquinas, incluso una instancia de InfluxDB manejará bien la carga.
En algunos casos, es posible que esté satisfecho con Influx Relay como una solución primitiva de alta disponibilidad.
Y, por supuesto, nadie le impide configurar el escalado "vertical" y simplemente asignar diferentes servidores para diferentes tipos de métricas.
Si no está seguro de la carga esperada en los servicios de monitoreo, o si tiene garantizado que tendrá o tendrá una arquitectura muy "pesada", no recomendaría usar la versión gratuita de la pila TICK.
Por supuesto, una solución sencilla sería comprar - pero aquí no puedo comentar de alguna manera, ya que yo mismo no estoy familiarizado con las sutilezas. Además de que es muy caro y definitivamente no es adecuado para pequeñas empresas.
En este caso, hoy recomendaría buscar recopilar métricas a través de Victoria Metrics y registros usando Loki.
Es cierto que nuevamente haré una reserva de que Loki/Grafana son mucho menos convenientes (debido a su mayor versatilidad) que los TICK ya preparados, pero son gratuitos.
Es importante: toda la información aquí descrita es relevante para la versión Influx 1.8, por el momento Influx 2.0 está a punto de ser lanzada.
Si bien no he tenido la oportunidad de probarlo en condiciones de combate y es difícil sacar conclusiones sobre las mejoras, la interfaz definitivamente ha mejorado aún más, la arquitectura se ha simplificado (sin condensador ni cronografo),
aparecieron plantillas ("función asesina" - ). Pero, desafortunadamente, por el momento la versión 2 no tiene la clave por la que elegimos la primera versión: no hay recopilación de registros.
Esta funcionalidad también aparecerá en Influx 2.0, pero no pudimos encontrar fechas límite, ni siquiera aproximadas.
Cómo no hacer plataformas IoT (ahora)
Al final, después de lanzar el piloto, nosotros mismos montamos nuestra propia pila de IoT completa, a falta de una alternativa adecuada a nuestros estándares.
Sin embargo, recientemente está disponible en versión Beta. — es una pena que ella no estuviera presente cuando empezamos a hacer el proyecto.
Estamos completamente satisfechos con el resultado final y la plataforma basada en Ansible + TICK + WireGuard que montamos nosotros mismos. Pero hoy recomendaría echar un vistazo más de cerca a Balena antes de intentar construir usted mismo su propia plataforma de IoT.
Porque, en última instancia, puede hacer la mayor parte de lo que hicimos nosotros y OpenBalena es gratuito y de código abierto.
Ya sabe no solo cómo enviar actualizaciones, sino que también tiene una VPN integrada y diseñada para su uso en un entorno de IoT.
Y recientemente incluso lanzaron su , que se conecta fácilmente a su ecosistema.
Oye, ¿qué pasa con el scooter perdido?
Así, el scooter "Ralph" desapareció sin dejar rastro.
Inmediatamente corrimos a mirar el mapa en nuestro “panel de administración”, con datos de métricas de GPS de InfluxDB.
Gracias a los datos de seguimiento, pudimos determinar fácilmente que el scooter salió del aparcamiento alrededor de las 21:00 del día anterior, condujo aproximadamente media hora hasta una zona y estuvo aparcado hasta las 5 de la mañana junto a una casa alemana.
Después de las 5 a.m., no se recibieron datos de monitoreo; esto significaba que la batería adicional estaba completamente descargada o que el atacante finalmente descubrió cómo quitar el hardware inteligente del scooter.
A pesar de esto, la policía fue llamada a la dirección donde se encontraba el scooter. La moto no estaba allí.
Sin embargo, el dueño de la casa también se sorprendió, ya que anoche viajó en este scooter a casa desde la oficina.
Al final resultó que, uno de los empleados de soporte llegó temprano en la mañana y recogió el scooter, al ver que su batería adicional estaba completamente descargada y lo llevó (a pie) al estacionamiento. Y la batería adicional falló debido a la humedad.
Nos robamos el scooter a nosotros mismos. Por cierto, no sé cómo ni quién resolvió el problema del caso policial, pero el seguimiento funcionó perfectamente...
Fuente: habr.com