Concevoir une observabilité résiliente en périphérie avec AWS et Prometheus

Viren Patel a publié le 6 octobre 2026 un guide technique détaillant la construction d'un pipeline d'observabilité de niveau production pour les dispositifs en périphérie. L'article présente une architecture combinant des composants serverless AWS avec des métriques compatibles Prometheus pour surveiller la santé et la disponibilité du matériel distribué à grande échelle.

Ce qui s'est passé

Le guide aborde le défi de la surveillance de milliers de dispositifs en périphérie déployés sur divers sites clients. Ces appareils exécutent des logiciels locaux dépendants de la connectivité réseau, de la santé matérielle et d'une configuration correcte. Sans surveillance active, un appareil peut passer silencieusement hors ligne, perdre l'accès au réseau local, manquer d'espace de stockage ou ne plus respecter les exigences du système d'exploitation. La solution proposée répond à deux questions critiques pour les opérateurs : l'appareil est-il vivant, et est-il sain ?

L'architecture utilise deux chemins d'ingestion distincts qui convergent vers un seul backend de séries temporelles. Le premier chemin implique des signaux de présence directs, où chaque dispositif en périphérie pousse une petite charge utile selon une cadence prévisible. Le second chemin utilise une fonction Lambda planifiée pour interroger une API externe de gestion des appareils. Cette approche pull enrichit les données avec des télémétries matérielles et de conformité que les appareils ne poussent pas eux-mêmes, telles que la température du CPU ou la santé de la batterie. Les deux flux sont normalisés au format de métriques Prometheus avant le stockage.

Le système repose fortement sur les composants serverless AWS pour gérer l'échelle sans infrastructure toujours active. API Gateway et les autorisateurs Lambda gèrent l'authentification et le routage, garantissant que les numéros de série des appareils sont validés par rapport à l'identité de l'appelant. Simple Queue Service (SQS) met en tampon les signaux de présence entrants, protégeant le système contre les pics de trafic et permettant une logique de nouvelle tentative. Une file d'attente de messages non traitables (dead-letter queue) capture les messages malformés ou échoués pour investigation, empêchant la perte de données. Enfin, une Lambda de sortie de file convertit ces charges utiles en métriques et les écrit dans le backend.

Détails clés

• Backend de métriques : Le système utilise VictoriaMetrics plutôt que Prometheus standard car il prend en charge le protocole remote-write tout en offrant des coûts inférieurs et de meilleures performances pour les données à haute cardinalité.
• Charge utile du signal de présence : Les appareils envoient des charges utiles JSON minimales contenant un numéro de série et un compteur, incluant éventuellement l'état de la connectivité réseau.
• Validation des données : Le schéma est strict, rejetant les champs inattendus pour prévenir les erreurs silencieuses, et les numéros de série sont validés par rapport aux identités authentifiées.
• Piste d'audit : Chaque charge utile de métriques est sauvegardée sur Amazon S3 avec expiration de cycle de vie, permettant aux équipes de rejouer ou d'inspecter les données brutes si nécessaire.
• Alertes doubles : La santé des appareils est surveillée via des alertes Grafana sur les données VictoriaMetrics, tandis que la santé du pipeline (âge de la file, taux d'erreurs) est surveillée via des alarmes CloudWatch.
• Stratégie de traitement par lots : La synchronisation planifiée de la télémétrie découpe la sortie en lots inférieurs à 1,5 Mo avec un backoff exponentiel pour rester dans les limites de charge utile lors des mises à jour de la flotte complète.

Contexte

L'observabilité dans les systèmes distribués repose souvent sur des bases de données de séries temporelles, qui stockent des points de données indexés par le temps. Prometheus est un outil open source populaire à cet effet, utilisant un langage de requête appelé PromQL. Cependant, Prometheus peut avoir du mal avec la haute cardinalité, qui survient lorsque les métriques possèdent de nombreuses combinaisons uniques d'étiquettes, comme des milliers de numéros de série d'appareils uniques. VictoriaMetrics est une alternative compatible conçue pour gérer cette échelle plus efficacement.

Les architectures serverless, telles que celles construites sur AWS Lambda, permettent au code de s'exécuter en réponse à des événements sans provisionner de serveurs. Ce modèle est idéal pour les pipelines d'ingestion connaissant un trafic variable, car l'infrastructure évolue automatiquement. L'utilisation de files d'attente comme SQS dissocie l'ingestion des données de leur traitement, garantissant que les pics temporaires de rapports d'appareils ne submergent pas la base de données de métriques.

Pourquoi c'est important

Pour les équipes exploitant leurs propres logiciels, notamment celles gérant des déploiements IoT ou en périphérie, la visibilité est critique. Un appareil qui semble en ligne mais a perdu sa connexion réseau locale représente un mode de défaillance différent de celui d'un appareil complètement éteint. En séparant les vérifications de disponibilité de la télémétrie approfondie, les opérateurs peuvent diagnostiquer les problèmes plus rapidement. L'architecture décrite garantit que ces signaux distincts sont unifiés dans un seul tableau de bord, réduisant la charge cognitive pour les ingénieurs de support.

La fiabilité du pipeline de surveillance lui-même est souvent négligée. Si le système d'ingestion tombe en panne, les tableaux de bord peuvent afficher des données obsolètes, amenant les équipes à croire que les appareils sont sains alors qu'ils ne le sont pas. En surveillant les métriques de santé interne du pipeline, telles que la profondeur de la file et les taux d'erreur Lambda, les équipes peuvent distinguer une panne de flotte globale d'une défaillance de la surveillance. Cette séparation empêche une fausse confiance et accélère la réponse aux incidents.

L'utilisation d'une validation stricte et de files d'attente de messages non traitables protège également l'intégrité des données. Dans les grandes flottes, des appareils mal configurés ou des acteurs malveillants pourraient tenter d'injecter de mauvaises données. La validation des numéros de série par rapport aux identités authentifiées et le rejet des champs inconnus garantissent que les métriques restent fiables. La sauvegarde S3 fournit un filet de sécurité supplémentaire, permettant aux équipes de récupérer après des erreurs de traitement sans perdre les données historiques.

Ce que vous pouvez faire

• Implémentez une validation de schéma stricte pour la télémétrie entrante afin de rejeter les données malformées tôt dans le pipeline.
• Utilisez une file d'attente de messages non traitables pour isoler les messages échoués en vue d'une analyse ultérieure plutôt que de les supprimer silencieusement.
• Séparez la surveillance du pipeline d'ingestion de celle des appareils pour détecter indépendamment les défaillances des outils.
• Stockez les charges utiles brutes dans un stockage objet comme S3 pour créer une piste d'audit utilisable pour le débogage ou le rejeu.
• Normalisez différentes sources de données dans un format de métriques commun, tel que les jauges Prometheus, pour simplifier les requêtes et les alertes.
• Validez les identités des appareils par rapport aux appelants authentifiés pour empêcher qu'un appareil n'imite les métriques d'un autre.