16 modems, 4 opérateurs mobiles = Vitesse de sortie 933,45 Mbit/s
Introduction
Bonjour ! Cet article parle de notre nouvelle système de surveillance que nous avons développée. Elle 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. La fréquence 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 proposons une solution complète pour la sommation de la bande passante et la résilience des canaux de transmission de données. C'est lorsqu'il y a plusieurs canaux, par exemple Opérateur1 (40 Mbit/s) + Opérateur2 (30 Mbit/s) + Autre chose (5 Mbit/s), ce qui donne un canal stable et rapide dont la vitesse sera approximativement : (40+30+5) x 0,92 = 75 x 0,92 = 69 Mbit/s.
De telles solutions sont demandées là où la capacité de n'importe quel canal unique est insuffisante. Par exemple, le transport, les systèmes de vidéosurveillance et de diffusion en continu en temps réel, la diffusion de programmes télévisés et radiophoniques en direct, tous les sites éloignés où les opérateurs de télécommunications sont uniquement les représentants des quatre grands et où la vitesse sur un modem/canal est insuffisante.
Pour chacun de ces domaines, nous lançons une gamme d'appareils distincts, toutefois la partie logicielle est presque identique et un bon système de surveillance est l'un de ses principaux modules, sans la bonne mise en œuvre, le produit serait impossible.
En quelques années, nous avons réussi à créer un système de surveillance multilingue, rapide, multiplateforme et léger. C'est ce que nous souhaitons partager avec la communauté respectée.
Définition du problème
Le système de surveillance permet l'obtention de 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 seulement les exigences suivantes :
- Obtention synchrone de métriques en temps réel à haute fréquence et transmission vers le système de gestion de la communication sans délais.
Une fréquence élevée et la synchronisation de différentes métriques ne sont pas seulement importantes, elles sont vitales pour l'analyse de l'entropie des canaux de transmission des données. Si un canal de transmission a un temps de latence moyen de 30 millisecondes, une erreur de synchronisation de seulement une milliseconde par rapport aux autres métriques entraînera une dégradation de la vitesse du canal résultant d'environ 5 %. Si nous faisons une erreur de synchronisation de 1 milliseconde dans 4 canaux, la dégradation de la vitesse peut facilement atteindre 30 %. De plus, l'entropie dans les canaux change très rapidement, donc si nous mesurons moins souvent qu'une fois toutes les 0.5 millisecondes, nous obtiendrons une forte dégradation de la vitesse sur des canaux rapides avec de faibles latences. Bien sûr, une telle précision n'est pas nécessaire pour toutes les métriques et dans toutes les conditions. Lorsque la latence dans le canal est de 500 millisecondes, et que nous travaillons avec de tels canaux, une erreur de 1 milliseconde sera presque imperceptible. De plus, pour les métriques des systèmes de survie, une fréquence d'interrogation et de synchronisation de 2 secondes est suffisante, néanmoins, le système de surveillance lui-même doit être capable de fonctionner avec des fréquences d'interrogation exceptionnellement élevées et une synchronisation très précise des métriques. - Consommation minimale de ressources et une seule pile.
Un dispositif final peut être un puissant complexe embarqué capable d'analyser la situation sur la route ou d'effectuer une identification biométrique des individus, tout comme un ordinateur monocarte de la taille de la paume qui est porté sous une combinaison par un soldat des forces spéciales pour transmettre des vidéos en temps réel dans des conditions de mauvaise connectivité. Malgré cette diversité d'architectures et de puissances de calcul, nous souhaitons disposer d'une pile logicielle uniforme. - Architecture en chapeau
Les métriques doivent être collectées et agrégées sur le dispositif final, avoir un système de stockage local et une visualisation en temps réel ainsi qu'en rétrospective. En cas de connexion, les données doivent être transmises au système central de surveillance. Lorsque la connexion n'est pas disponible, la file d'attente d'envoi doit s'accumuler sans consommer de mémoire vive. - 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 rassembler des données de tous les dispositifs et réseaux en une seule surveillance.
Ce qui a été réalisé
Pour ne pas alourdir ce long article déjà imposant, je ne fournirai pas d'exemples ni de mesures de tous les systèmes de surveillance. Cela nécessiterait un autre article. Il suffit de dire qu'il nous a été impossible de trouver un système de surveillance capable de prendre deux métriques simultanément avec une marge d'erreur inférieure à 1 milliseconde et qui fonctionne de manière tout aussi efficace sur l'architecture ARM avec 64 Mo de RAM que sur l'architecture x86_64 avec 32 Go de RAM. C'est pourquoi nous avons décidé d'écrire le nôtre, qui possède toutes ces fonctionnalités. Voilà ce que nous avons obtenu :
Somme de la bande passante de trois canaux pour différentes topologies de réseau
Visualisation de certaines métriques clés
Architecture
Comme langage de programmation principal, tant sur l'appareil que dans le centre de données, nous utilisons Golang. Il a considérablement simplifié notre vie grâce à sa mise en œuvre de la multitâche et à la possibilité d'obtenir un fichier binaire exécutable statiquement lié pour chaque service. En conséquence, nous économisons considérablement sur les ressources, les modalités et le trafic de déploiement du service sur les appareils finaux, ainsi que sur le temps de développement et de débogage du code.
Le système est réalisé selon le principe modulaire classique et contient plusieurs sous-systèmes :
- Enregistrement des métriques.
Chaque métrique est gérée par son propre thread et synchronisée via des canaux. Nous avons réussi à obtenir une précision de synchronisation allant jusqu'à 10 nanosecondes. - Stockage des métriques
Nous hésitions entre créer notre propre stockage pour les séries temporelles ou utiliser quelque chose d'existant. La base de données est nécessaire pour les données rétrospectives qui seront ensuite visualisées. C'est-à-dire qu'elle ne contient pas de données sur les délais dans le canal toutes les 0,5 millisecondes ou sur les erreurs dans le réseau de transport, mais elle contient la vitesse sur chaque interface toutes les 500 millisecondes. En plus d'exigences élevées en matière de compatibilité multiplateforme et de faible consommation de ressources, il est extrêmement important pour nous d'avoir la possibilité de traiter les données là où elles sont stockées. Cela économise considérablement les ressources de calcul. Depuis 2016, nous utilisons la base de données Tarantool pour ce projet et nous ne voyons pas pour l'instant d'alternative. Flexible, avec une consommation optimale des ressources et un support technique plus que adéquat. De plus, Tarantool intègre un module GIS. Bien qu'il ne soit pas aussi puissant que PostGIS, il suffit pour nos besoins de stockage de certaines métriques liées aux emplacements (pertinent pour le transport). - Visualisation des métriques
Ici, tout est relativement simple. Nous prenons les données du stockage et les affichons soit en temps réel, soit de manière rétrospective. - Synchronisation des données avec le système central de monitoring.
Le système central de monitoring accepte les données de tous les dispositifs, les stocke avec une rétrospective donnée et les renvoie via une API au système de monitoring du client. Contrairement aux systèmes de monitoring classiques, où la « tête » va collecter les données, nous avons un schéma inversé. Les dispositifs envoient eux-mêmes les données quand il y a une connexion. C'est un point très important, car cela permet d'obtenir des données du dispositif durant les périodes où il n'était pas accessible sans saturer les canaux et les ressources lorsque le dispositif n'est pas disponible. Comme système central de monitoring, nous utilisons Influx monitoring server. Contrairement aux alternatives, il peut importer les données rétrospectives (c'est-à-dire avec un horodatage différent de celui du moment de réception de la métrique). Les métriques collectées sont visualisées par une version améliorée de Grafana. Ce stack standard a été choisi aussi parce qu'il dispose d'API d'intégration prêtes à l'emploi avec pratiquement n'importe quel système de monitoring du client. - Synchronisation des données avec le système central de gestion des dispositifs.
Le système de gestion des appareils implémente le Zero Touch Provisioning (mise à jour du firmware, configurations, etc.) et, contrairement au système de surveillance, ne reçoit que des problèmes liés aux appareils. Ce sont des déclencheurs pour le fonctionnement des services de surveillance matérielle embarqués et toutes les métriques des systèmes de support à la vie : température du CPU et du SSD, charge CPU, espace libre et état S.M.A.R.T des disques. Le stockage de la sous-système est également construit sur Tarantool. Cela nous donne une vitesse significative dans l'agrégation des séries temporelles à travers des milliers d'appareils, et résout complètement la question de la synchronisation des données avec ces appareils. Tarantool intègre un excellent système de files d'attente et de livraison garantie. Cette fonctionnalité importante nous est fournie par défaut, génial !
Système de gestion de réseau
Que faire ensuite
Pour l'instant, le maillon le plus faible est notre système de surveillance central. Il est réalisé à 99,9 % avec une pile standard et présente plusieurs inconvénients :
- InfluxDB perd des données en cas de coupure de courant. En règle générale, le client récupère rapidement tout ce qui est reçu des appareils et dans la base de données, il n'y a pas de données plus anciennes que 5 minutes, mais cela pourrait devenir un problème à l'avenir.
- Grafana a plusieurs problèmes d'agrégation des données et de synchronisation de leur affichage. Le problème le plus fréquent est que lorsqu'il y a une série temporelle dans la base avec un intervalle de 2 secondes à partir de 00:00:00, Grafana commence à afficher les données agrégées avec un décalage d'une seconde. En conséquence, l'utilisateur voit un graphique qui danse.
- Un excès de code pour l'intégration API avec des systèmes de surveillance tiers. On pourrait le rendre beaucoup plus compact et bien sûr le réécrire en Go)
Je suppose que vous avez tous vu à quoi ressemble Grafana et que vous connaissez ses problèmes, donc je ne vais pas surcharger le post avec des images.
Conclusion
J'ai délibérément choisi de ne pas décrire les détails techniques et de seulement décrire le design de base de ce système. D'une part, pour décrire techniquement le système, il faudrait un autre article. D'autre part, cela n'intéressera pas tout le monde. Écrivez dans les commentaires quels détails techniques vous aimeriez connaître.
Si quelqu'un a des questions au-delà de cet article, vous pouvez m'écrire à l'adresse a.rodin @ qedr.com
Source : habr.com
