Somme de la vitesse sur 16 modems de 4 opérateurs mobiles. Vitesse sortante dans un flux - 933,45 Mbps
Présentation
Salut Cet article explique comment nous avons écrit un nouveau système de surveillance pour nous-mêmes. Il se distingue des modèles existants par la possibilité d'acquisition synchrone à haute fréquence de métriques et une très faible consommation de ressources. La fréquence d'interrogation peut atteindre 0,1 millisecondes 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 données. C'est quand il y a plusieurs canaux, par exemple, Operator1 (40Mbit / s) + Operator2 (30Mbit / s) + Quelque chose d'autre (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 = 75x0,92 = 69 Mbps.
De telles solutions sont demandées lorsque la capacité d'un canal est insuffisante. Par exemple, le transport, la vidéosurveillance en temps réel et les systèmes de streaming vidéo, les émissions de télévision et de radio en direct, tous les objets en dehors de la ville où les opérateurs de télécommunications n'ont 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, cependant, 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 serait impossible.
Depuis plusieurs années, nous avons réussi à créer un système de surveillance multi-niveaux rapide, multiplateforme et léger. Ce que nous voulons partager avec une communauté réputée.
Énoncé du problème
Le système de surveillance fournit des métriques pour deux classes fondamentalement différentes: les métriques en temps réel et tout le reste. Le système de surveillance avait les exigences suivantes:
- Acquisition synchrone haute fréquence de métriques en temps réel et leur transfert vers le système de contrôle de la communication sans délai.
La haute fréquence 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 de données. S'il y a un retard moyen de 30 millisecondes dans un canal de données, une erreur de synchronisation entre les métriques restantes d'une seule milliseconde entraînera une dégradation de la vitesse du canal résultant d'environ 5%. Si l'on fait une erreur de synchronisation pendant 1 milliseconde sur 4 canaux, la dégradation de la vitesse peut facilement tomber à 30%. De plus, l'entropie dans les canaux change très rapidement, donc si nous la mesurons moins d'une fois toutes les 0,5 millisecondes, sur les canaux rapides avec un petit retard, nous obtiendrons une dégradation à haute vitesse. Bien sûr, une telle précision n'est pas nécessaire pour toutes les mesures et pas dans toutes les conditions. Lorsque le retard dans le canal est de 500 millisecondes et que nous travaillons avec cela, l'erreur de 1 milliseconde sera à peine perceptible. De plus, pour les métriques des systèmes de survie, les fréquences d'interrogation et de synchronisation de 2 secondes nous suffisent, cependant, le système de surveillance lui-même devrait être capable de fonctionner avec des fréquences d'interrogation ultra élevées et une synchronisation métrique ultra précise. - Consommation minimale de ressources et une seule pile.
Le dernier appareil peut être un puissant complexe embarqué capable d'analyser la situation sur la route ou d'enregistrer les données biométriques des personnes, ou un ordinateur monoplace de la taille d'une paume porté par un soldat des forces spéciales sous un blindage corporel pour transmettre des vidéos en temps réel dans de mauvaises conditions de communication. Malgré une telle variété d'architectures et de puissance de calcul, nous aimerions avoir la même pile logicielle. - Architecture de parapluie
Les mesures doivent être collectées et agrégées sur l'appareil final, avoir un système de stockage local et une visualisation en temps réel et rétrospectivement. Si la communication est disponible, 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. - Une API pour l'intégration dans le système de surveillance d'un client, car personne n'a besoin de beaucoup de systèmes de surveillance. Le client doit collecter les données de tous les appareils et réseaux en une seule surveillance.
Qu'est-il arrivé?
Afin de charger le longrid déjà impressionnant, je ne donnerai pas d'exemples et de mesures de tous les systèmes de surveillance. Cela tirera un autre article. Je dirai simplement que nous n'avons pas pu trouver de système de surveillance capable de prendre deux mesures en même temps avec une erreur inférieure à 1 milliseconde et qui fonctionne de manière tout aussi efficace sur une architecture ARM avec 64 Mo de RAM et une architecture x86_64 avec 32 Go de RAM. Par conséquent, nous avons décidé d'écrire le nôtre, ce qui peut faire exactement cela. Voici ce que nous avons obtenu:
Addition du débit de trois canaux pour différentes topologies de réseau
Visualisation de certaines métriques clés
L'architecture
En tant que langage de programmation principal, à la fois sur l'appareil et dans le centre de données, nous utilisons Golang. Il a grandement simplifié sa vie en implémentant le multitâche et la possibilité d'obtenir un binaire exécutable lié statiquement pour chaque service. En conséquence, nous économisons considérablement les ressources, les méthodes et le trafic de déploiement des services vers les terminaux, le temps de développement et le débogage de code.
Le système est implémenté selon le principe modulaire classique et contient plusieurs sous-systèmes:
- Enregistrement des métriques.
Chaque métrique est desservie par son propre flux et synchronisée via des canaux. Nous avons réussi à obtenir une précision de synchronisation allant jusqu'à 10 nanosecondes. - Stockage métrique
Nous avons choisi entre écrire notre référentiel pour les séries temporelles ou utiliser l'un des disponibles. La base de données est nécessaire pour les données rétrospectives, qui sont sujettes à une visualisation ultérieure. En d'autres termes, elle ne contient pas de données sur les retards dans le canal toutes les 0,5 millisecondes ni d'indication d'erreur dans le réseau de transport, mais il existe une vitesse sur chaque interface toutes les 500 millisecondes. En plus des exigences élevées en matière de multiplateforme et de faible consommation de ressources, il est extrêmement important pour nous de pouvoir traiter. données au même endroit où elles sont stockées. Cela économise énormément de ressources informatiques. Depuis 2016, nous utilisons Tarantool DBMS dans ce projet et jusqu'à présent, nous n'en voyons pas de remplacement à l'horizon. Flexible, avec une consommation optimale des ressources, un support technique plus qu'adéquat. Tarantool dispose également d'un module SIG. Il n'est certainement pas aussi puissant que PostGIS, mais il suffit pour nos tâches de stockage de métriques liées à un emplacement (pertinentes pour le transport). - Visualisation des métriques
Ici, tout est relativement simple. Nous prenons les données du stockage et les affichons en temps réel ou rétrospectivement. - Synchronisation des données avec un système de surveillance central.
Le système de surveillance central reçoit les données de tous les appareils, les stocke avec une rétrospective donnée et les envoie via l'API au système de surveillance du client. Contrairement aux systèmes de surveillance classiques, dans lesquels la «tête» marche et collecte des données - nous avons le schéma inverse. Les appareils eux-mêmes envoient des données en cas de connexion. Il s'agit d'un point très important, car il vous permet de recevoir des données de l'appareil pendant les périodes où il n'était pas disponible et de ne pas charger les canaux et les ressources lorsque l'appareil n'est pas disponible. En tant que système de surveillance central, nous utilisons le serveur de surveillance Influx. Contrairement aux analogues, il peut importer des données rétrospectives (c'est-à-dire avec un horodatage différent du moment où la métrique a été reçue) Les métriques collectées sont visualisées par un fichier Grafana modifié. Cette pile standard a également été choisie car elle possède des API d'intégration prêtes à l'emploi avec presque tous les systèmes de surveillance des clients. - Synchronisation des données avec un système central de gestion des appareils.
Le système de gestion des appareils implémente Zero Touch Provisioning (mise à jour du micrologiciel, configuration, etc.) et, contrairement au système de surveillance, ne reçoit que les problèmes d'appareils. Ce sont les déclencheurs des services de surveillance du matériel embarqué et toutes les métriques des systèmes de support de la vie: température du CPU et 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 de séries chronologiques sur des milliers d'appareils, et résout également complètement le problème de synchronisation des données avec ces appareils. Tarantool a un excellent système de mise en file d'attente et une livraison garantie. Nous avons sorti cette fonctionnalité importante de la boîte, super!
Système de gestion de réseau
Et ensuite
Jusqu'à présent, le maillon le plus faible de notre pays est le système central de surveillance. Il est implémenté à 99,9% sur la pile standard et présente un certain nombre d'inconvénients:
- InfluxDB perd des données lorsque l'alimentation est coupée. En règle générale, le client prend rapidement tout ce qui vient des appareils et il n'y a pas de données de plus de 5 minutes dans la base de données elle-même, mais à l'avenir, cela peut être pénible.
- Grafana a un certain nombre de problèmes avec l'agrégation de données et la synchronisation de leur affichage. Le problème le plus courant est lorsque la base de données contient une série chronologique avec un intervalle de 2 secondes à partir de 00:00:00 et que Grafana commence à afficher les données d'agrégation à partir de +1 seconde. En conséquence, l'utilisateur voit un graphique de danse.
- Excès de code pour l'intégration d'API avec des systèmes de surveillance tiers. Peut être rendu beaucoup plus compact et bien sûr réécrire pour aller)
Je suppose que vous avez tous parfaitement vu à quoi ressemble Grafana et sans moi vous connaissez ses problèmes, donc je ne surchargerai pas le post avec des photos.
Conclusion
Je n'ai délibérément pas décrit les détails techniques, mais seulement la conception de support de ce système. Premièrement, afin de décrire techniquement complètement le système, un autre article est nécessaire. Deuxièmement, tout le monde ne sera pas intéressé. Écrivez dans les commentaires les détails techniques que vous souhaitez connaître.
Si quelqu'un a des questions en dehors de cet article, je peux écrire à a.rodin @ qedr.com