Il y a un an, nous avons lancé une version pilote d'un projet promotionnel pour .
Initialement, le projet s'appelait Road-To-Barcelona, plus tard il est devenu Road-To-Berlin (d'où R2B dans les captures d'écran), et finalement il s'est appelé xRide.
L'idée principale du projet était la suivante : au lieu d'avoir un service centralisé de location de voitures ou de scooters (nous parlons de scooters, c'est-à-dire de motos électriques, pas de kickscooters/scooters), nous voulions créer une plateforme de location décentralisée. Sur les difficultés que nous avons rencontrées .
Initialement, le projet se concentrait sur les voitures, mais en raison des délais, des communications extrêmement longues avec les fabricants et du grand nombre de restrictions de sécurité, les scooters électriques ont été choisis pour le projet pilote.
L'utilisateur a installé une application iOS ou Android sur le téléphone, s'est approché du scooter qu'il aimait, après quoi le téléphone et le scooter ont établi une connexion peer-to-peer, l'ETH a été échangé et l'utilisateur a pu commencer le trajet en allumant le scooter via le téléphone. À la fin du voyage, il était également possible de payer le voyage en utilisant Ethereum depuis le portefeuille de l’utilisateur sur le téléphone.
En plus des scooters, l'utilisateur a vu dans l'application des « chargeurs intelligents », en visitant lesquels l'utilisateur pouvait changer lui-même la batterie actuelle si elle était faible.
C'est globalement à cela que ressemblait notre pilote, lancé en septembre de l'année dernière dans deux villes allemandes : Bonn et Berlin.
Et puis, un jour, à Bonn, tôt le matin, notre équipe support (localisée sur place pour maintenir les scooters en état de marche) a été alertée : un des scooters avait disparu sans laisser de trace.
Comment le retrouver et le restituer ?
Dans cet article, je parlerai de cela, mais d'abord de la façon dont nous avons construit notre propre plate-forme IoT et comment nous l'avons surveillée.
Quoi et pourquoi surveiller : les scooters, les infrastructures, les bornes de recharge ?
Alors, que voulions-nous surveiller dans notre projet ?
Tout d'abord, ce sont les scooters eux-mêmes - les scooters électriques eux-mêmes sont assez chers, on ne peut pas lancer un tel projet sans être suffisamment préparé ; si possible, vous souhaitez collecter un maximum d'informations sur les scooters : sur leur emplacement, leur niveau de charge , etc.
De plus, je souhaite surveiller l'état de notre propre infrastructure informatique - bases de données, services et tout ce dont ils ont besoin pour fonctionner. Il était également nécessaire de surveiller l’état des « chargeurs intelligents », au cas où ils tomberaient en panne ou seraient à court de batteries.
Trottinettes
Quels étaient nos scooters et que voulions-nous savoir à leur sujet ?
La première et la plus importante chose, ce sont les coordonnées GPS, car grâce à elles nous pouvons comprendre où ils se trouvent et où ils se déplacent.
Vient ensuite la charge de la batterie, grâce à laquelle nous pouvons déterminer que la charge des scooters touche à sa fin et envoyer un presse-agrumes ou au moins avertir l'utilisateur.
Bien entendu, il est également nécessaire de vérifier ce qui se passe avec nos composants matériels :
- est-ce que le Bluetooth fonctionne ?
- le module GPS lui-même fonctionne-t-il ?
- Nous avons également eu un problème avec le fait que le GPS pouvait envoyer des coordonnées incorrectes et rester bloqué, et cela ne pouvait être déterminé que par des contrôles supplémentaires sur le scooter,
et informez le support dès que possible pour résoudre le problème
- Nous avons également eu un problème avec le fait que le GPS pouvait envoyer des coordonnées incorrectes et rester bloqué, et cela ne pouvait être déterminé que par des contrôles supplémentaires sur le scooter,
Et enfin : des contrôles du logiciel, en commençant par l'OS et le processeur, la charge du réseau et des disques, pour finir par des contrôles de nos propres modules qui nous sont plus spécifiques (, ).
Matériel
Quelle était notre part de « fer » ?
Compte tenu du délai le plus court possible et de la nécessité d'un prototypage rapide, nous avons choisi l'option la plus simple pour la mise en œuvre et la sélection des composants - Raspberry Pi.
En plus du Rpi lui-même, nous avions une carte personnalisée (que nous avons nous-mêmes développée et commandée en Chine pour accélérer le processus d'assemblage de la solution finale) et un ensemble de composants - un relais (pour allumer/éteindre le scooter), un lecteur de charge de batterie, un modem, des antennes. Tout cela a été emballé de manière compacte dans une « boîte xRide » spéciale.
Il convient également de noter que l’ensemble du boîtier était alimenté par une batterie externe supplémentaire, elle-même alimentée par la batterie principale du scooter.
Cela a permis d'utiliser la surveillance et d'allumer le scooter même après la fin du voyage, puisque la batterie principale était éteinte immédiatement après avoir tourné la clé de contact en position « off ».
Docker? Linux simple ? et déploiement
Revenons à la surveillance, alors Raspberry, qu'avons-nous ?
L'une des premières choses que nous voulions utiliser pour accélérer le processus de déploiement, de mise à jour et de livraison des composants sur les appareils physiques était Docker.
Malheureusement, il est rapidement devenu évident que Docker sur RPi, bien qu'il fonctionne, entraîne de nombreuses dépenses, notamment en termes de consommation d'énergie.
La différence avec l'OS « natif », bien que moins forte, était tout de même suffisante pour nous méfier d'une éventuelle perte de charge trop rapide.
La deuxième raison était l'une de nos bibliothèques partenaires sur Node.js (sic !) - le seul composant du système qui n'était pas écrit en Go/C/C++.
Les auteurs de la bibliothèque n'ont pas eu le temps de fournir une version de travail dans aucune des langues « maternelles ».
Non seulement le nœud lui-même n’est pas la solution la plus élégante pour les appareils peu performants, mais la bibliothèque elle-même était très gourmande en ressources.
Nous avons réalisé que, même si nous le voulions, utiliser Docker représenterait une surcharge trop importante pour nous. Le choix s'est porté en faveur du système d'exploitation natif et du travail directement sous celui-ci.
OS
En conséquence, nous avons encore une fois choisi l’option la plus simple comme système d’exploitation et utilisé Raspbian (version Debian pour Pi).
Nous écrivons tous nos logiciels en Go, nous avons donc également écrit le module principal d'agent matériel de notre système en Go.
C'est lui qui se charge de travailler avec le GPS, le Bluetooth, de lire la charge, d'allumer le scooter, etc.
Déployer
La question s'est immédiatement posée de la nécessité de mettre en œuvre un mécanisme de fourniture de mises à jour aux appareils (OTA) - à la fois des mises à jour de notre agent/application lui-même et des mises à jour du système d'exploitation/micrologiciel lui-même (puisque les nouvelles versions de l'agent pourraient nécessiter des mises à jour du noyau). ou composants système, bibliothèques, etc.) .
Après une analyse assez longue du marché, il s'est avéré qu'il existe de nombreuses solutions pour fournir des mises à jour à l'appareil.
Des utilitaires relativement simples, principalement orientés mise à jour/double démarrage, comme swupd/SWUpdate/OSTree, aux plates-formes à part entière comme Mender et Balena.
Tout d’abord, nous avons décidé que nous étions intéressés par des solutions de bout en bout, le choix s’est donc immédiatement porté sur les plateformes.
Lui-même a été exclu car il utilise en fait le même Docker dans son balenaEngine.
Mais je constate que malgré cela, nous avons fini par utiliser constamment leur produit pour le firmware flash sur les cartes SD - un utilitaire simple et extrêmement pratique pour cela.
C’est pourquoi le choix s’est finalement porté sur . Mender est une plateforme complète pour assembler, fournir et installer un firmware.
Dans l'ensemble, la plate-forme a fière allure, mais il nous a fallu environ une semaine et demie rien que pour créer la version correcte de notre firmware à l'aide du constructeur mender.
Et plus nous nous plongeions dans les subtilités de son utilisation, plus il devenait évident que pour le déployer pleinement, il nous faudrait beaucoup plus de temps que nous n'en avions.
Hélas, nos délais serrés nous ont obligés à abandonner l’utilisation de Mender et à en choisir une encore plus simple.
Ansible
La solution la plus simple dans notre situation était d'utiliser Ansible. Quelques playbooks suffisaient pour commencer.
Leur essence était que nous nous connections simplement depuis l'hôte (serveur CI) via ssh à nos framboises et leur distribuions des mises à jour.
Au tout début, tout était simple : il fallait être sur le même réseau que les appareils, le versement se faisait via Wi-Fi.
Au bureau, il y avait simplement une douzaine de framboises de test connectées au même réseau, chaque appareil avait une adresse IP statique également spécifiée dans Ansible Inventory.
C'est Ansible qui a livré notre agent de surveillance aux appareils finaux
3G / LTE
Malheureusement, ce cas d'utilisation d'Ansible ne pouvait fonctionner qu'en mode développement avant que nous ayons de véritables scooters.
Parce que les scooters, comme vous le comprenez, ne restent pas connectés à un seul routeur Wi-Fi, attendant constamment des mises à jour sur le réseau.
En réalité, les scooters ne peuvent avoir aucune connexion autre que la 3G/LTE mobile (et encore pas tout le temps).
Cela impose immédiatement de nombreux problèmes et limitations, tels qu'une faible vitesse de connexion et une communication instable.
Mais le plus important est que dans un réseau 3G/LTE, nous ne pouvons pas simplement nous fier à une IP statique attribuée au réseau.
Ce problème est partiellement résolu par certains fournisseurs de cartes SIM ; il existe même des cartes SIM spéciales conçues pour les appareils IoT avec des adresses IP statiques. Mais nous n’avions pas accès à de telles cartes SIM et ne pouvions pas utiliser d’adresses IP.
Bien sûr, il y avait des idées pour faire une sorte d'enregistrement des adresses IP, c'est-à-dire une découverte de service quelque part comme Consul, mais nous avons dû abandonner de telles idées, car dans nos tests, l'adresse IP pouvait changer trop souvent, ce qui conduisait à une grande instabilité.
Pour cette raison, l'utilisation la plus pratique pour fournir des métriques ne serait pas d'utiliser le modèle pull, dans lequel nous accèderions aux appareils pour obtenir les métriques nécessaires, mais le modèle push, qui transmettrait les métriques de l'appareil directement au serveur.
VPN
Pour résoudre ce problème, nous avons choisi le VPN, en particulier .
Les clients (scooters) au démarrage du système se sont connectés au serveur VPN et ont pu s'y connecter. Ce tunnel était utilisé pour délivrer les mises à jour.
En théorie, le même tunnel pourrait être utilisé pour la surveillance, mais une telle connexion était plus compliquée et moins fiable qu'un simple push.
Ressources cloud
Enfin, il est nécessaire de surveiller nos services cloud et nos bases de données, puisque nous utilisons pour eux Kubernetes, idéalement pour que le déploiement de la surveillance dans le cluster soit le plus simple possible. Idéalement, en utilisant , puisque pour le déploiement, nous l'utilisons dans la plupart des cas. Et bien sûr, pour surveiller le cloud, vous devez utiliser les mêmes solutions que pour les scooters eux-mêmes.
Étant donné
Ouf, nous semblons avoir réglé la description, faisons une liste de ce dont nous avions besoin au final :
- Une solution rapide, car un suivi est nécessaire dès le processus de développement
- Volume/quantité – de nombreuses mesures nécessaires
- La collecte des journaux est requise
- Fiabilité : les données sont essentielles au succès du lancement
- Vous ne pouvez pas utiliser le modèle pull - vous avez besoin de pousser
- Nous avons besoin d'une surveillance unifiée non seulement du matériel, mais également du cloud.
L'image finale ressemblait à ceci
Sélection de pile
Nous avons donc été confrontés à la question du choix d'une pile de surveillance.
Tout d’abord, nous recherchions la solution tout-en-un la plus complète qui couvrirait simultanément tous nos besoins, tout en étant suffisamment flexible pour adapter son utilisation à nos besoins. Pourtant, de nombreuses restrictions nous étaient imposées par le matériel, l'architecture et les délais.
Il existe une grande variété de solutions de surveillance, à commencer par des systèmes à part entière comme , ou et se terminant par des solutions prêtes à l'emploi pour la gestion de flotte.
Au départ, cette dernière solution nous semblait être une solution idéale, mais certaines n'avaient pas de surveillance complète, d'autres avaient des capacités très limitées des versions gratuites, et d'autres encore ne couvraient tout simplement pas nos « désirs » ou n'étaient pas assez flexibles pour s'adapter à nos scénarios. Certains sont tout simplement obsolètes.
Après avoir analysé un certain nombre de solutions similaires, nous sommes rapidement arrivés à la conclusion qu'il serait plus facile et plus rapide d'assembler nous-mêmes une pile similaire. Oui, ce sera un peu plus compliqué que de déployer une plateforme de gestion de flotte entièrement prête à l’emploi, mais nous n’aurons pas à faire de compromis.
Presque certainement, dans toute l'immense abondance de solutions, il en existe déjà une toute faite qui nous conviendrait parfaitement, mais dans notre cas, il était beaucoup plus rapide d'assembler nous-mêmes une certaine pile et de la personnaliser « pour nous-mêmes » plutôt que tester des produits prêts à l'emploi.
Avec tout cela, nous ne nous sommes pas efforcés d'assembler nous-mêmes une plate-forme de surveillance complète, mais recherchions les piles « prêtes à l'emploi » les plus fonctionnelles, uniquement avec la possibilité de les configurer de manière flexible.
(B)ELK?
La première solution réellement envisagée était la célèbre pile ELK.
En fait, il devrait s'appeler BELK, car tout commence avec Beats -
Bien entendu, ELK est l’une des solutions les plus connues et les plus puissantes dans le domaine de la surveillance, et plus encore dans la collecte et le traitement des logs.
Nous avions prévu qu'ELK soit utilisé pour collecter des journaux ainsi que pour le stockage à long terme des métriques obtenues de Prometheus.
Pour la visualisation, vous pouvez utiliser Grafan.
En fait, la nouvelle pile ELK peut collecter des métriques de manière indépendante (metricbeat) et Kibana peut également les afficher.
Néanmoins, ELK est initialement né de journaux et, jusqu'à présent, la fonctionnalité des métriques présente un certain nombre d'inconvénients sérieux :
- Beaucoup plus lent que Prométhée
- S'intègre dans beaucoup moins d'endroits que Prometheus
- Il est difficile de configurer des alertes pour eux
- Les métriques prennent beaucoup de place
- Mettre en place des tableaux de bord avec des métriques dans Kiban est beaucoup plus compliqué que dans Grafan
En général, les métriques dans ELK sont lourdes et pas encore aussi pratiques que dans d'autres solutions, dont il existe désormais bien plus que Prometheus : TSDB, Victoria Metrics, Cortex, etc., etc. Bien sûr, j'aimerais vraiment disposer immédiatement d'une solution tout-en-un à part entière, mais dans le cas de metricbeat, il y avait trop de compromis.
Et la pile ELK elle-même connaît un certain nombre de moments difficiles :
- C’est lourd, parfois même très lourd si l’on collecte une quantité de données assez importante
- Il faut « savoir le cuisiner » - il faut le mettre à l'échelle, mais ce n'est pas anodin à faire
- Version gratuite allégée - la version gratuite n'a pas d'alerte normale et au moment de la sélection, il n'y avait pas d'authentification
Je dois dire que récemment le dernier point s'est amélioré et en plus (y compris l'authentification), le modèle de tarification lui-même a commencé à changer.
Mais au moment où nous allions déployer cette solution, il n’y avait aucune alerte.
Nous aurions peut-être pu essayer de créer quelque chose en utilisant ElastAlert ou d'autres solutions communautaires, mais nous avons quand même décidé d'envisager d'autres alternatives.
Loki - Grafana - Prométhée
Pour le moment, une bonne solution pourrait être de créer une pile de surveillance basée uniquement sur Prometheus en tant que fournisseur de métriques, Loki pour les journaux, et pour la visualisation, vous pouvez utiliser le même Grafana.
Malheureusement, au moment du début du pilote commercial du projet (septembre-octobre 19), Loki était encore en version bêta 0.3-0.4, et au moment du début du développement il ne pouvait pas être considéré comme une solution de production. du tout.
Je n'ai pas encore d'expérience dans l'utilisation réelle de Loki dans des projets sérieux, mais je peux dire que Promtail (un agent de collecte de journaux) fonctionne très bien à la fois pour le bare-metal et les pods dans Kubernetes.
COCHER
Peut-être que l'alternative complète la plus intéressante (la seule ?) à la pile ELK ne peut désormais s'appeler que la pile TICK - Telegraf, InfluxDB, Chronograf, Kapacitor.
Je vais décrire tous les composants ci-dessous plus en détail, mais l'idée générale est la suivante :
- Telegraf - agent de collecte de métriques
- InfluxDB - base de données de métriques
- Kapacitor - processeur de métriques en temps réel pour les alertes
- Chronograf - panneau web pour la visualisation
Pour InfluxDB, Kapacitor et Chronograf, il existe des graphiques de barre officiels que nous avons utilisés pour les déployer.
A noter que dans la dernière version d'Influx 2.0 (bêta), Kapacitor et Chronograf sont devenus partie intégrante d'InfluxDB et n'existent plus séparément.
Télégraphe
est un agent très léger pour collecter des métriques sur une machine à états.
Il peut surveiller une quantité énorme de tout, depuis à
serveur .
Il présente de nombreux avantages intéressants :
- Rapide et léger (écrit en Go)
- Mange un minimum de ressources
- Push métriques par défaut
- Collecte toutes les mesures nécessaires
- Métriques système sans aucun paramètre
- Mesures matérielles telles que les informations provenant des capteurs
- Il est très simple d'ajouter vos propres métriques
- De nombreux plugins prêts à l'emploi
- Collecte les journaux
Puisque nous avions besoin de mesures push, tous les autres avantages étaient des ajouts plus que plaisants.
La collecte des journaux par l'agent lui-même est également très pratique, car il n'est pas nécessaire de connecter des utilitaires supplémentaires pour enregistrer les journaux.
Influx offre l'expérience la plus pratique pour travailler avec les journaux si vous utilisez .
Telegraf est généralement un excellent agent pour collecter des métriques, même si vous n'utilisez pas le reste de la pile ICK.
De nombreuses personnes le croisent avec ELK et diverses autres bases de données de séries chronologiques pour plus de commodité, car il peut écrire des métriques presque n'importe où.
InfluxDB
InfluxDB est le noyau principal de la pile TICK, à savoir une base de données de séries chronologiques pour les métriques.
En plus des métriques, Influx peut également stocker des journaux, bien que, en substance, les journaux correspondants soient exactement les mêmes métriques, mais au lieu des indicateurs numériques habituels, la fonction principale est réalisée par une ligne de texte de journal.
InfluxDB est également écrit en Go et semble fonctionner beaucoup plus rapidement que ELK sur notre cluster (pas le plus puissant).
L'un des avantages intéressants d'Influx inclurait également une API très pratique et riche pour les requêtes de données, que nous avons utilisée très activement.
Inconvénients - $$$ ou mise à l'échelle ?
La pile TICK n'a qu'un seul inconvénient que nous avons découvert : ma chérie. Encore plus.
Qu’est-ce que la version payante a de plus que la version gratuite ?
D'après ce que nous avons pu comprendre, la seule différence entre la version payante de la pile TICK et la version gratuite réside dans les capacités de mise à l'échelle.
À savoir, vous pouvez créer un cluster avec haute disponibilité uniquement dans .
Si vous voulez une HA à part entière, vous devez soit payer, soit utiliser des béquilles. Il existe quelques solutions communautaires - par exemple cela ressemble à une solution compétente, mais il est écrit qu'elle n'est pas adaptée à la production, ainsi que
- une solution simple avec pompage de données via NATS (il faudra également la mettre à l'échelle, mais cela peut être résolu).
C'est dommage, mais les deux semblent avoir été abandonnés - il n'y a pas de nouveaux commits, je suppose que le problème est la sortie prochainement attendue de la nouvelle version d'Influx 2.0, dans laquelle beaucoup de choses seront différentes (il n'y a aucune information sur mise à l'échelle encore).
Officiellement, il existe une version gratuite - en fait, il s'agit d'un HA primitif, mais uniquement par équilibrage,
puisque toutes les données seront écrites dans toutes les instances InfluxDB derrière l'équilibreur de charge.
Il en a comme les problèmes potentiels d'écrasement des points et la nécessité de créer des bases de métriques à l'avance
(ce qui se produit automatiquement lors du travail normal avec InfluxDB).
Outre , cela signifie une surcharge supplémentaire pour les métriques en double (traitement et stockage) dont vous n'avez peut-être pas besoin, mais il n'existe aucun moyen de les séparer.
Victoria Métriques ?
En conséquence, malgré le fait que nous étions entièrement satisfaits de la pile TICK dans tout ce qui n'est pas la mise à l'échelle payante, nous avons décidé de voir s'il existait des solutions gratuites qui pourraient remplacer la base de données InfluxDB, tout en laissant les composants T_CK restants.
Il existe de nombreuses bases de données de séries chronologiques, mais la plus prometteuse est Victoria Metrics, elle présente de nombreux avantages :
- Rapide et facile, du moins selon les résultats
- Il existe une version cluster, sur laquelle il y a même de bonnes critiques maintenant
- Elle peut éclater
- Prend en charge le protocole InfluxDB
Nous n'avions pas l'intention de créer une pile entièrement personnalisée basée sur Victoria et le principal espoir était de pouvoir l'utiliser en remplacement d'InfluxDB.
Malheureusement, cela n'est pas possible, bien que le protocole InfluxDB soit pris en charge, il ne fonctionne que pour enregistrer des métriques - seule l'API Prometheus est disponible "à l'extérieur", ce qui signifie qu'il ne sera pas possible d'y installer Chronograf.
De plus, seules les valeurs numériques sont prises en charge pour les métriques (nous avons utilisé des valeurs de chaîne pour les métriques personnalisées - plus d'informations à ce sujet dans la section ).
Évidemment, pour la même raison, la VM ne peut pas stocker les journaux comme le fait Influx.
Il convient également de noter qu'au moment de la recherche de la solution optimale, Victoria Metrics n'était pas encore aussi populaire, la documentation était beaucoup plus petite et les fonctionnalités étaient plus faibles.
(Je ne me souviens pas d'une description détaillée de la version du cluster et du partitionnement).
Sélection de bases
En conséquence, il a été décidé que pour le pilote, nous nous limiterions toujours à un seul nœud InfluxDB.
Plusieurs raisons principales ont motivé ce choix :
- Nous avons vraiment aimé toutes les fonctionnalités de la pile TICK
- Nous avons déjà réussi à le déployer et cela a très bien fonctionné
- Les délais étaient comptés et il ne restait plus beaucoup de temps pour tester d’autres options.
- Nous ne nous attendions pas à une charge aussi lourde
Nous n'avions pas beaucoup de scooters pour la première phase du projet pilote, et les tests effectués pendant le développement n'ont révélé aucun problème de performances.
Par conséquent, nous avons décidé que pour ce projet, un seul nœud Influx nous suffirait sans nécessiter de mise à l'échelle (voir conclusions à la fin).
Nous avons décidé de la pile et de la base - maintenant des composants restants de la pile TICK.
Capacitor
Kapacitor fait partie de la pile TICK, un service qui peut surveiller les métriques entrant dans la base de données en temps réel et effectuer diverses actions basées sur des règles.
En général, il se positionne comme un outil de suivi des anomalies potentielles et d'apprentissage automatique (je ne suis pas sûr que ces fonctions soient demandées), mais le cas le plus courant de son utilisation est plus courant : l'alerte.
C'est ainsi que nous l'avons utilisé pour les notifications. Nous avons configuré des alertes Slack lorsqu'un scooter particulier était hors ligne, et nous avons fait de même pour les chargeurs intelligents et les composants d'infrastructure importants.
Cela a permis de répondre rapidement aux problèmes et de recevoir des notifications indiquant que tout était revenu à la normale.
Un exemple simple : une batterie supplémentaire pour alimenter notre « box » est en panne ou, pour une raison quelconque, est à court de puissance ; en installant simplement une nouvelle, nous devrions recevoir après un certain temps une notification indiquant que les fonctionnalités du scooter ont été restaurées.
Dans Influx 2.0, Kapacitor est devenu une partie de DB
Chronographe
J'ai vu de nombreuses solutions d'interface utilisateur différentes pour la surveillance, mais je peux dire qu'en termes de fonctionnalités et d'UX, rien ne se compare à Chronograf.
Nous avons commencé à utiliser la pile TICK, curieusement, avec Grafan comme interface Web.
Je ne décrirai pas ses fonctionnalités, tout le monde connaît ses larges possibilités de personnalisation.
Cependant, Grafana reste un instrument totalement universel, tandis que Chronograf est principalement conçu pour être utilisé avec Influx.
Et bien sûr, grâce à cela, Chronograf peut s’offrir des fonctionnalités bien plus astucieuses ou pratiques.
Le principal avantage de travailler avec Chronograf est peut-être que vous pouvez visualiser l'intérieur de votre InfluxDB via Explore.
Il semblerait que Grafana ait des fonctionnalités presque identiques, mais en réalité, la configuration d'un tableau de bord dans Chronograf peut se faire en quelques clics de souris (tout en regardant la visualisation là-bas), alors que dans Grafana, vous aurez toujours tôt ou tard pour modifier la configuration JSON (bien sûr, Chronograf permet de télécharger vos dashas configurés manuellement et de les modifier en JSON si nécessaire - mais je n'ai jamais eu à les toucher après les avoir créés sur l'interface utilisateur).
Kibana dispose de capacités beaucoup plus riches pour créer des tableaux de bord et des contrôles, mais l'UX pour de telles opérations est très complexe.
Il faudra une bonne compréhension pour créer un tableau de bord pratique. Et bien que les fonctionnalités des tableaux de bord Chronograf soient moindres, leur création et leur personnalisation sont beaucoup plus simples.
Les tableaux de bord eux-mêmes, outre le style visuel agréable, ne sont en réalité pas différents des tableaux de bord de Grafana ou Kibana :
Voici à quoi ressemble la fenêtre de requête :
Il est important de noter, entre autres, que connaissant les types de champs dans la base de données InfluxDB, le chronographe lui-même peut parfois vous aider automatiquement à rédiger une requête ou à choisir la bonne fonction d'agrégation comme la moyenne.
Et bien sûr, Chronograf est aussi pratique que possible pour visualiser les journaux. Cela ressemble à ceci :
Par défaut, les journaux Influx sont conçus pour utiliser syslog et ont donc un paramètre important : la gravité.
Le graphique en haut est particulièrement utile : vous pouvez y voir les erreurs qui se produisent et la couleur indique immédiatement clairement si la gravité est plus élevée.
Plusieurs fois, nous avons détecté des bugs importants de cette façon, en consultant les journaux de la semaine dernière et en voyant un pic rouge.
Bien sûr, l’idéal serait de mettre en place des alertes pour de telles erreurs, puisque nous avions déjà tout pour cela.
Nous l'avons même activé pendant un certain temps, mais au cours du processus de préparation du pilote, il s'est avéré que nous recevions beaucoup d'erreurs (y compris des erreurs système, comme l'indisponibilité du réseau LTE), qui ont également « spammé » le canal Slack. beaucoup, sans poser de problèmes, un grand avantage.
La bonne solution serait de gérer la plupart de ces types d’erreurs, d’en ajuster la gravité, puis d’activer ensuite les alertes.
De cette façon, seules les erreurs nouvelles ou importantes seraient publiées sur Slack. Compte tenu des délais serrés, il n’y avait tout simplement pas assez de temps pour une telle configuration.
Authentification
Il convient également de mentionner que Chronograf prend en charge OAuth et OIDC comme authentification.
C'est très pratique, car cela vous permet de le connecter facilement à votre serveur et de créer un SSO à part entière.
Dans notre cas, le serveur était — il était utilisé pour se connecter à la surveillance, mais le même serveur était également utilisé pour authentifier les scooters et les requêtes vers le back-end.
"Administrateur"
Le dernier composant que je décrirai est notre « panneau d'administration » auto-écrit dans Vue.
Fondamentalement, il s'agit simplement d'un service autonome qui affiche simultanément les informations sur les scooters de nos propres bases de données, microservices et données métriques d'InfluxDB.
De plus, de nombreuses fonctions administratives y ont été déplacées, comme un redémarrage d'urgence ou l'ouverture d'un verrou à distance pour l'équipe de support.
Il y avait aussi des cartes. J'ai déjà mentionné que nous avons commencé avec Grafana au lieu de Chronograf - car pour Grafana, des cartes sont disponibles sous forme de plugins, sur lesquels nous pouvons visualiser les coordonnées des scooters. Malheureusement, les capacités des widgets cartographiques pour Grafana sont très limitées et, par conséquent, il était beaucoup plus facile d'écrire votre propre application Web avec des cartes en quelques jours, afin non seulement de voir les coordonnées du moment, mais également d'afficher l'itinéraire emprunté par le scooter, pouvoir filtrer les données sur la carte, etc. (toute cette fonctionnalité que l'on ne pourrait pas configurer dans un simple tableau de bord).
L'un des avantages déjà mentionnés d'Influx est la possibilité de créer facilement vos propres métriques.
Cela lui permet d’être utilisé dans une grande variété de scénarios.
Nous avons essayé d'y enregistrer toutes les informations utiles : charge de la batterie, état du verrouillage, performances du capteur, Bluetooth, GPS et bien d'autres contrôles de santé.
Nous avons affiché tout cela sur le panneau d'administration.
Bien entendu, le critère le plus important pour nous était l'état de fonctionnement du scooter - en fait, Influx le vérifie lui-même et l'indique avec des « voyants verts » dans la section Nœuds.
Ceci est fait par la fonction — nous l'avons utilisé pour comprendre les performances de notre box et envoyer ces mêmes alertes à Slack.
À propos, nous avons nommé les scooters d'après les noms des personnages des Simpsons - c'était tellement pratique de les distinguer les uns des autres.
Et en général, c'était plus amusant ainsi. Des phrases comme « Les gars, Smithers est mort ! » étaient constamment entendues.
Métriques de chaîne
Il est important qu'InfluxDB vous permette de stocker non seulement des valeurs numériques, comme c'est le cas avec Victoria Metrics.
Il semblerait que ce ne soit pas si important - après tout, à l'exception des journaux, toutes les métriques peuvent être stockées sous forme de nombres (il suffit d'ajouter un mappage pour les états connus - une sorte d'énumération) ?
Dans notre cas, il y avait au moins un scénario dans lequel les métriques de chaîne étaient très utiles.
Il se trouve que le fournisseur de nos « chargeurs intelligents » était un tiers, nous n'avions aucun contrôle sur le processus de développement et sur les informations que ces chargeurs pouvaient fournir.
En conséquence, l’API de chargement était loin d’être idéale, mais le principal problème était que nous ne pouvions pas toujours comprendre leur état.
C'est là qu'Influx est venu à la rescousse. Nous avons simplement écrit le statut de la chaîne qui nous est parvenu dans le champ de la base de données InfluxDB sans modification.
Pendant un certain temps, seules des valeurs telles que « en ligne » et « hors ligne », en fonction des informations affichées dans notre panneau d'administration, et des notifications ont été envoyées à Slack. Cependant, à un moment donné, des valeurs telles que « déconnecté » ont également commencé à apparaître.
Comme il s'est avéré plus tard, cet état était envoyé une seule fois après une perte de connexion, si le chargeur ne parvenait pas à établir une connexion avec le serveur après un certain nombre de tentatives.
Ainsi, si nous n’utilisions qu’un ensemble fixe de valeurs, nous pourrions ne pas voir ces changements dans le firmware au bon moment.
Et en général, les métriques de chaîne offrent beaucoup plus de possibilités d'utilisation : vous pouvez y enregistrer pratiquement n'importe quelle information. Bien sûr, vous devez également utiliser cet outil avec précaution.
En plus des métriques habituelles, nous avons également enregistré les informations de localisation GPS dans InfluxDB. Cela s'est avéré incroyablement utile pour surveiller l'emplacement des scooters dans notre panneau d'administration.
En fait, nous savions toujours où et quel scooter se trouvait au moment où nous en avions besoin.
Cela nous a été très utile lors de la recherche d'un scooter (voir conclusions à la fin).
Surveillance des infrastructures
En plus des scooters eux-mêmes, nous devions surveiller l'ensemble de notre infrastructure (plutôt étendue).
Une architecture très générale ressemblait à ceci :
Si nous mettons en évidence une pure pile de surveillance, elle ressemble à ceci :
Ce que nous aimerions vérifier dans le cloud, c'est :
- bases de données
- Cape de clé
- Microservices
Puisque tous nos services cloud sont situés dans Kubernetes, il serait bien de collecter des informations sur son état.
Heureusement, Telegraf est capable de collecter un grand nombre de métriques sur l'état du cluster Kubernetes, et Chronograf propose immédiatement de superbes tableaux de bord pour cela.
Nous avons principalement surveillé les performances des pods et la consommation de mémoire. En cas de chute, alertes dans Slack.
Il existe deux façons de suivre les pods dans Kubernetes : DaemonSet et Sidecar.
Les deux méthodes sont décrites en détail .
Nous avons utilisé Telegraf Sidecar et, en plus des métriques, collecté des journaux de pods.
Dans notre cas, nous avons dû bricoler les journaux. Malgré le fait que Telegraf puisse extraire les journaux de l'API Docker, nous souhaitions disposer d'une collection uniforme de journaux avec nos appareils finaux et avons configuré syslog pour les conteneurs à cet effet. Peut-être que cette solution n'était pas belle, mais il n'y a eu aucune plainte concernant son travail et les journaux étaient bien affichés dans Chronograf.
Surveillance du moniteur ???
En fin de compte, la question séculaire du contrôle des systèmes de surveillance s'est posée, mais heureusement ou malheureusement, nous n'avons tout simplement pas eu assez de temps pour cela.
Bien que Telegraf puisse facilement envoyer ses propres métriques ou collecter des métriques à partir de la base de données InfluxDB pour les envoyer soit au même Influx, soit ailleurs.
résultats
Quelles conclusions avons-nous tirées des résultats du pilote ?
Comment pouvez-vous effectuer une surveillance ?
Tout d’abord, la stack TICK a pleinement répondu à nos attentes et nous a offert encore plus d’opportunités que ce à quoi nous nous attendions initialement.
Toutes les fonctionnalités dont nous avions besoin étaient présentes. Tout ce que nous avons fait avec a fonctionné sans problème.
Performance
Le principal problème de la pile TICK dans la version gratuite est le manque de capacités de mise à l'échelle. Ce n'était pas un problème pour nous.
Nous n'avons pas collecté de données/chiffres exacts sur la charge, mais nous avons collecté des données sur environ 30 scooters à la fois.
Chacun d’eux a collecté plus de trois douzaines de mesures. Dans le même temps, les journaux des appareils ont été collectés. La collecte et l'envoi des données ont eu lieu toutes les 10 secondes.
Il est important de noter qu'après une semaine et demie de pilote, lorsque la plupart des « problèmes d'enfance » ont été corrigés et que les problèmes les plus importants avaient déjà été résolus, nous avons dû réduire la fréquence d'envoi des données au serveur pour 30 secondes. Cela est devenu nécessaire car le trafic sur nos cartes SIM LTE a commencé à disparaître rapidement.
La majeure partie du trafic était consommée par les journaux, les métriques elles-mêmes, même avec un intervalle de 10 secondes, ne le gaspillaient pratiquement pas.
En conséquence, après un certain temps, nous avons complètement désactivé la collecte de journaux sur les appareils, car des problèmes spécifiques étaient déjà évidents même sans collecte constante.
Dans certains cas, si la visualisation des journaux était encore nécessaire, nous nous connections simplement via WireGuard via VPN.
J'ajouterai également que chaque environnement distinct que nous avions était séparé les uns des autres et que la charge décrite ci-dessus ne concernait que l'environnement de production.
Dans l'environnement de développement, nous avons créé une instance InfluxDB distincte qui a continué à collecter des données toutes les 10 secondes et nous n'avons rencontré aucun problème de performances.
TICK - idéal pour les petits et moyens projets
Sur la base de ces informations, je conclurais que la pile TICK est idéale pour les projets relativement petits ou pour les projets qui n'attendent certainement pas de HighLoad.
Si vous ne disposez pas de milliers de pods ou de centaines de machines, même une seule instance InfluxDB gérera très bien la charge.
Dans certains cas, vous pouvez vous contenter d’Influx Relay en tant que solution primitive de haute disponibilité.
Et, bien sûr, personne ne vous empêche de mettre en place une mise à l’échelle « verticale » et simplement d’allouer différents serveurs pour différents types de métriques.
Si vous n'êtes pas sûr de la charge attendue sur les services de surveillance, ou si vous êtes assuré d'avoir/aura une architecture très « lourde », je ne vous recommanderais pas d'utiliser la version gratuite de la pile TICK.
Bien sûr, une solution simple serait d'acheter - mais ici, je ne peux pas commenter d'une manière ou d'une autre, car je ne connais pas moi-même les subtilités. Outre le fait que cela coûte très cher et ne convient absolument pas aux petites entreprises.
Dans ce cas, aujourd'hui, je recommanderais d'envisager de collecter des métriques via Victoria Metrics et des journaux à l'aide de Loki.
Certes, je ferai encore une réserve sur le fait que Loki/Grafana sont beaucoup moins pratiques (en raison de leur plus grande polyvalence) que les TICK tout faits, mais ils sont gratuits.
Il est important: toutes les informations décrites ici sont pertinentes pour la version Influx 1.8, pour le moment Influx 2.0 est sur le point de sortir.
Même si je n'ai pas eu l'occasion de l'essayer en conditions de combat et qu'il est difficile de tirer des conclusions sur les améliorations, l'interface est définitivement devenue encore meilleure, l'architecture a été simplifiée (sans kapacitor ni chronograf),
des modèles sont apparus (« fonctionnalité qui tue » - ). Mais malheureusement, pour le moment, la version 2 n'a pas l'élément clé pour lequel nous avons choisi la première version : il n'y a pas de collecte de journaux.
Cette fonctionnalité apparaîtra également dans Influx 2.0, mais nous n'avons trouvé aucun délai, même approximatif.
Comment ne pas créer de plateformes IoT (maintenant)
En fin de compte, après avoir lancé le pilote, nous avons nous-mêmes assemblé notre propre pile IoT à part entière, en l'absence d'alternative adaptée à nos normes.
Cependant, depuis peu, il est disponible en version bêta — c'est dommage qu'elle n'était pas là quand nous avons commencé à réaliser le projet.
Nous sommes entièrement satisfaits du résultat final et de la plateforme basée sur Ansible + TICK + WireGuard que nous avons nous-mêmes assemblée. Mais aujourd’hui, je recommanderais d’examiner de plus près Balena avant d’essayer de créer vous-même votre propre plateforme IoT.
Parce qu'en fin de compte, il peut faire la plupart de ce que nous avons fait, et OpenBalena est gratuit et open source.
Il sait déjà non seulement comment envoyer des mises à jour, mais un VPN est également déjà intégré et adapté pour être utilisé dans un environnement IoT.
Et tout récemment, ils ont même sorti leur , qui se connecte facilement à leur écosystème.
Hé, et le scooter disparu ?
Le scooter « Ralph » a donc disparu sans laisser de trace.
Nous avons immédiatement couru regarder la carte dans notre « panneau d'administration », avec les données de métriques GPS d'InfluxDB.
Grâce aux données de surveillance, nous avons facilement déterminé que le scooter avait quitté le parking vers 21 heures le jour dernier, avait roulé environ une demi-heure jusqu'à une zone et était resté garé jusqu'à 00 heures du matin à côté d'une maison allemande.
Après 5 heures du matin, aucune donnée de surveillance n'a été reçue : soit la batterie supplémentaire était complètement déchargée, soit l'attaquant avait enfin compris comment retirer le matériel intelligent du scooter.
Malgré cela, la police a quand même été appelée à l'adresse où se trouvait le scooter. Le scooter n'était pas là.
Cependant, le propriétaire de la maison a également été surpris par cela, puisqu'il est rentré du bureau en scooter hier soir.
Il s'est avéré qu'un des employés d'assistance est arrivé tôt le matin et a récupéré le scooter, voyant que sa batterie supplémentaire était complètement déchargée, et l'a emmené (à pied) jusqu'au parking. Et la batterie supplémentaire est tombée en panne à cause de l'humidité.
Nous nous sommes volé le scooter. D'ailleurs, je ne sais pas comment et qui a ensuite résolu le problème avec la police, mais la surveillance a parfaitement fonctionné...
Source: habr.com