16 modems, 4 opérateurs cellulaires = Débit sortant 933.45 Mbit/s
introduction
Bonjour! Cet article explique comment nous avons écrit un nouveau système de surveillance pour nous-mêmes. Il se distingue des systèmes existants par sa capacité à obtenir des métriques synchrones à haute fréquence et une très faible consommation de ressources. Le taux d'interrogation peut atteindre 0.1 milliseconde avec une précision de synchronisation entre les métriques de 10 nanosecondes. Tous les fichiers binaires occupent 6 mégaoctets.
À propos du projet
Nous avons un produit assez spécifique. Nous produisons une solution complète pour résumer le débit et la tolérance aux pannes des canaux de transmission de données. C'est lorsqu'il y a plusieurs canaux, disons Opérateur1 (40 Mbit/s) + Opérateur2 (30 Mbit/s) + Autre chose (5 Mbit/s), le résultat est un canal stable et rapide, dont la vitesse sera quelque chose comme ceci : (40+ 30+5)x0.92=75×0.92=69 Mbit/s.
De telles solutions sont demandées lorsque la capacité d’un canal est insuffisante. Par exemple, les transports, les systèmes de vidéosurveillance et le streaming vidéo en temps réel, la diffusion d'émissions de télévision et de radio en direct, toutes les installations de banlieue où parmi les opérateurs de télécommunications il n'y a que des représentants des Big Four et la vitesse sur un modem/canal n'est pas suffisante .
Pour chacun de ces domaines, nous produisons une gamme distincte d'appareils, mais leur partie logicielle est presque la même et un système de surveillance de haute qualité est l'un de ses principaux modules, sans la mise en œuvre correcte dont le produit ne serait pas possible.
Au cours de plusieurs années, nous avons réussi à créer un système de surveillance multi-niveaux, rapide, multiplateforme et léger. C'est ce que nous voulons partager avec notre communauté respectée.
Formulation du problème
Le système de surveillance fournit des métriques de deux classes fondamentalement différentes : les métriques en temps réel et toutes les autres. Le système de surveillance avait uniquement les exigences suivantes :
- Acquisition synchrone à haute fréquence de métriques en temps réel et leur transfert sans délai au système de gestion des communications.
La haute fréquence et la synchronisation des différentes métriques ne sont pas seulement importantes, elles sont vitales pour analyser l'entropie des canaux de transmission de données. Si dans un canal de transmission de données le délai moyen est de 30 millisecondes, alors une erreur de synchronisation entre les métriques restantes d'une milliseconde seulement entraînera une dégradation de la vitesse du canal résultant d'environ 5 %. Si nous effectuons un mauvais timing d'une milliseconde sur 1 canaux, la dégradation de la vitesse peut facilement chuter jusqu'à 4 %. De plus, l'entropie dans les canaux change très rapidement, donc si nous la mesurons moins d'une fois toutes les 30 millisecondes, sur les canaux rapides avec un petit retard, nous obtiendrons une dégradation à grande vitesse. Bien entendu, une telle précision n’est pas nécessaire pour toutes les mesures ni dans toutes les conditions. Lorsque le retard dans le canal est de 0.5 millisecondes et que nous travaillons avec celui-ci, une erreur de 500 milliseconde sera presque imperceptible. De plus, pour les métriques du système de survie, nous disposons de taux d'interrogation et de synchronisation suffisants de 1 secondes, mais le système de surveillance lui-même doit être capable de fonctionner avec des taux d'interrogation ultra-élevés et une synchronisation ultra-précise des métriques. - Consommation minimale de ressources et une seule pile.
L'appareil final peut être soit un puissant complexe embarqué capable d'analyser la situation sur la route ou d'effectuer un enregistrement biométrique de personnes, soit un ordinateur monocarte de la taille d'une paume qu'un soldat des forces spéciales porte sous son gilet pare-balles pour transmettre des vidéos. en temps réel dans de mauvaises conditions de communication. Malgré une telle variété d’architectures et de puissances de calcul, nous aimerions avoir la même pile logicielle. - Architecture parapluie
Les métriques doivent être collectées et regroupées sur l'appareil final, stockées localement et visualisées en temps réel et rétrospectivement. S'il existe une connexion, transférez les données vers le système de surveillance central. Lorsqu'il n'y a pas de connexion, la file d'attente d'envoi doit s'accumuler et ne pas consommer de RAM. - API pour l'intégration dans le système de surveillance du client, car personne n'a besoin de plusieurs systèmes de surveillance. Le client doit collecter les données de tous les appareils et réseaux dans une seule surveillance.
Qu'est-il arrivé
Afin de ne pas alourdir la lecture déjà impressionnante, je ne donnerai pas d'exemples et de mesures de tous les systèmes de surveillance. Cela mènera à un autre article. Je dirai simplement que nous n'avons pas réussi à trouver un système de surveillance capable de prendre deux métriques simultanément avec une erreur inférieure à 1 milliseconde et qui fonctionne aussi bien sur une architecture ARM avec 64 Mo de RAM que sur une architecture x86_64 avec 32 Mo de RAM. Go de RAM. C’est pourquoi nous avons décidé d’écrire le nôtre, capable de faire tout cela. Voici ce que nous avons obtenu :
Résumer le débit de trois canaux pour différentes topologies de réseau
Visualisation de quelques indicateurs clés
Architecture
Nous utilisons Golang comme langage de programmation principal, à la fois sur l'appareil et dans le centre de données. Il a grandement simplifié la vie grâce à sa mise en œuvre du multitâche et à la possibilité d'obtenir un fichier binaire exécutable lié statiquement pour chaque service. En conséquence, nous économisons considérablement les ressources, les méthodes et le trafic nécessaires au déploiement du service sur les appareils finaux, le temps de développement et le débogage du code.
Le système est mis en œuvre selon le principe modulaire classique et contient plusieurs sous-systèmes :
- Enregistrement des métriques.
Chaque métrique est servie par son propre thread et synchronisée sur tous les canaux. Nous avons pu atteindre une précision de synchronisation allant jusqu'à 10 nanosecondes. - Stockage des métriques
Nous devions choisir entre écrire notre propre stockage pour les séries chronologiques ou utiliser quelque chose qui était déjà disponible. La base de données est nécessaire pour les données rétrospectives soumises à une visualisation ultérieure. C'est-à-dire qu'elle ne contient pas de données sur les retards dans le canal toutes les 0.5 millisecondes ni sur les lectures d'erreurs dans le réseau de transport, mais il y a une vitesse sur chaque interface toutes les 500 millisecondes. Outre les exigences élevées en matière de multiplateforme et de faible consommation de ressources, il est extrêmement important pour nous de pouvoir traiter. les données sont là où elles sont stockées. Cela permet d'économiser d'énormes ressources informatiques. Nous utilisons le SGBD Tarantool dans ce projet depuis 2016 et jusqu'à présent, nous ne voyons pas de remplacement à l'horizon. Flexible, avec une consommation optimale des ressources, un support technique plus que adéquat. Tarantool implémente également un module SIG. Bien sûr, il n'est pas aussi puissant que PostGIS, mais il est suffisant pour nos tâches de stockage de certaines métriques liées à la localisation (pertinentes pour le transport). - Visualisation des métriques
Tout est relativement simple ici. Nous récupérons les données de l'entrepôt et les affichons en temps réel ou rétrospectivement. - Synchronisation des données avec le système de surveillance central.
Le système de surveillance central reçoit les données de tous les appareils, les stocke avec un historique spécifié et les envoie au système de surveillance du client via API. Contrairement aux systèmes de surveillance classiques, dans lesquels la « tête » se promène et collecte les données, nous avons le schéma inverse. Les appareils eux-mêmes envoient des données lorsqu'il existe une connexion. C'est un point très important, car il vous permet de recevoir des données de l'appareil pendant les périodes pendant lesquelles elles n'étaient pas disponibles et de ne pas charger de chaînes et de ressources pendant que l'appareil est indisponible. Nous utilisons le serveur de surveillance Influx comme système de surveillance central. Contrairement à ses analogues, il peut importer des données rétrospectives (c'est-à-dire avec un horodatage différent du moment où les métriques ont été reçues). Les métriques collectées sont visualisées par Grafana, modifiées avec un fichier. Cette pile standard a également été choisie car elle dispose d'intégrations API prêtes à l'emploi avec presque tous les systèmes de surveillance client. - Synchronisation des données avec un système central de gestion des appareils.
Le système de gestion des appareils implémente le Zero Touch Provisioning (mise à jour du firmware, configuration, etc.) et, contrairement au système de surveillance, ne reçoit que des problèmes par appareil. Il s'agit de déclencheurs pour le fonctionnement des services de surveillance matériels embarqués et de toutes les mesures des systèmes de survie : température du CPU et du SSD, charge du CPU, espace libre et santé SMART sur les disques. Le stockage du sous-système est également construit sur Tarantool. Cela nous donne une vitesse significative dans l'agrégation des séries temporelles sur des milliers d'appareils et résout également complètement le problème de la synchronisation des données avec ces appareils. Tarantool dispose d’un excellent système de file d’attente et de livraison garantie. Nous avons sorti cette fonctionnalité importante de la boîte, super !
Système de gestion de réseau
Quelle est la prochaine
Jusqu’à présent, notre maillon le plus faible est le système de surveillance central. Il est implémenté à 99.9 % sur une pile standard et présente un certain nombre d'inconvénients :
- InfluxDB perd des données en cas de coupure de courant. En règle générale, le client collecte rapidement tout ce qui provient des appareils et la base de données elle-même ne contient pas de données datant de plus de 5 minutes, mais à l'avenir, cela pourrait devenir pénible.
- Grafana rencontre un certain nombre de problèmes d'agrégation des données et de synchronisation de son affichage. Le problème le plus courant survient lorsque la base de données contient une série temporelle avec un intervalle de 2 secondes commençant, par exemple, à 00:00:00, et que Grafana commence à afficher les données sous forme d'agrégation à partir de +1 seconde. En conséquence, l’utilisateur voit un graphique dansant.
- Quantité excessive de code pour l'intégration d'API avec des systèmes de surveillance tiers. Il peut être rendu beaucoup plus compact et bien sûr réécrit en Go)
Je pense que vous avez tous parfaitement vu à quoi ressemble Grafana et connaissez ses problèmes sans moi, je ne vais donc pas surcharger le post de photos.
Conclusion
Je n'ai délibérément pas décrit les détails techniques, mais j'ai décrit uniquement la conception de base de ce système. Premièrement, pour décrire techniquement complètement le système, un autre article sera nécessaire. Deuxièmement, tout le monde ne sera pas intéressé par cela. Écrivez dans les commentaires les détails techniques que vous aimeriez connaître.
Si quelqu'un a des questions dépassant le cadre de cet article, vous pouvez m'écrire à a.rodin @ qedr.com
Source: habr.com