Présentation de la nouvelle vue des métriques : surveillance des ressources des conteneurs à l'aide d'InfluxDB

Depuis novembre 2015, le CLI Scalingo a fourni une utilisation des ressources des conteneurs en temps réel. Parfois, vous devez aller plus loin pour vraiment comprendre les comportements de votre application. Vous devez voir l'évolution de ces valeurs pour en tirer du sens. C'est pourquoi nous avons travaillé sur une nouvelle vue métriques pour le tableau de bord Scalingo.

Vue globale

La vue des métriques est accessible depuis le tableau de bord Scalingo, juste en dessous de la section Conteneurs. Cette page contient deux parties principales : graphismes d'application et graphismes des conteneurs. Vous pouvez ajuster la période de visualisation à 3h, 12h, 24h, 48h et 72h passées. Nous essayons de détecter automatiquement votre fuseau horaire à partir de votre navigateur et vous pouvez toujours le changer plus tard si nécessaire.

 Graphismes d'application

Le graphique d'application affiche des données globales qui ne sont pas spécifiques aux conteneurs : événements et métriques de routage.

Le graphique des événements est là pour vous montrer tous les événements qui se sont produits pendant la période de visualisation. Cela peut vous aider à lier un comportement d'application avec des événements qui se sont déroulés sur la plateforme, par exemple détecter un déploiement qui contient une fuite de mémoire ou suivre le comportement de votre application après une montée en charge (ou une baisse).

Beaucoup d'événements sont disponibles sur la timeline de votre application mais nous pensons que seuls quelques-uns sont pertinents dans la vue des métriques :

• Événement de redémarrage

• Événement de déploiement

• Événement de montée en charge

Nous ajouterons de nouveaux types d'événements dans les semaines à venir (vous trouverez la liste complète des événements dans notre documentation pour développeurs).

Le graphique du routeur est là pour vous montrer combien de requêtes votre application reçoit par minute. Il vous affiche deux types de données différents. Le premier est le nombre de requêtes par minute, le célèbre RPM, et le second est le nombre de réponses d'erreur serveur générées par votre application (réponses HTTP dans la plage 500).

Remarque : Les erreurs 504 peuvent être générées par notre proxy si votre application met plus de 30 secondes à répondre. Plus d'informations sont disponibles dans la documentation de routage.

 Graphismes des conteneurs

Les graphiques des conteneurs utilisent les types de conteneurs définis dans votre procfile.

Pour chaque type de conteneur, deux graphiques sont affichés. Le premier montre l'utilisation du CPU et le second l'utilisation de la mémoire et de SWAP de ce type de conteneur. Pour le graphique de la mémoire, nous superposons votre utilisation de la mémoire (en bleu) et votre utilisation de SWAP (en rouge). Ainsi, vous pouvez facilement voir l'utilisation totale de la mémoire de votre application.

Astuce : Votre application est-elle lente ? Vérifiez votre utilisation de SWAP ! Si votre application effectue beaucoup de SWAP, cela affectera considérablement les performances de votre application. Vous feriez mieux de réduire votre utilisation de la mémoire ou d'utiliser une taille de conteneur plus grande.

Remarque : La ligne de SWAP n'est affichée que si l'utilisation de SWAP dépasse 2 % de votre limite de mémoire du conteneur.

Si vous avez plus d'un conteneur d'un type spécifique, ces graphiques montreront la moyenne de l'utilisation du CPU / consommation de mémoire de tous vos conteneurs du même type.

Vue détaillée

Si vous avez plus d'un conteneur d'un type défini dans votre procfile, vous pourrez accéder à une vue détaillée de votre conteneur. Les graphiques sont exactement les mêmes sauf qu'ils sont maintenant par conteneur (et non par type de conteneur). Cela vous aidera à repérer un conteneur bogué et donc à simplifier le processus de débogage.

Intégration API

Comme chaque autre fonctionnalité, les métriques sont entièrement intégrées dans notre API. L'endpoint pour accéder aux données est documenté ici.

Les métriques sont collectées toutes les minutes. Cependant, pour éviter une forte utilisation des ressources de notre pile de métriques, l'API vous enverra un maximum de 300 points par graphique. Pour avoir une précision d'une minute, votre période de visualisation ne doit pas dépasser 300 minutes.

Comment cela fonctionne-t-il ?

Les données proviennent de deux sources de données différentes. La première est les serveurs frontend Scalingo (3). Depuis le début, Scalingo utilise Nginx pour proxy et équilibrer les requêtes vers les conteneurs d'applications.

Afin de collecter et de stocker les informations sur les requêtes, nous utilisons le NGINX Lua Module qui nous permet d'intercepter de nombreux événements Nginx et d'exécuter du code Lua. Bien sûr, nous avons gardé à l'esprit que ce code sera exécuté pour chaque requête envoyée à notre plateforme, donc le code doit s'exécuter le plus rapidement possible et la base de code doit être aussi légère que possible. C'est pourquoi les liaisons Nginx n'envoient que des données brutes à un serveur Redis qui est utilisé comme tampon. Chaque minute, notre agrégateur de métriques de routeur (6) collectera les données dans le tampon Redis, les agrégera et les enverra à notre adaptateur de stockage de métriques (5).

La seconde source de données est les conteneurs d'application. Pour obtenir la consommation de ressources des conteneurs, nous utilisons notre solution interne appelée Acadock qui a été introduite dans un ancien article de blog. Une fois par minute, ces données sont collectées sur chaque nœud par notre agrégateur de métriques de conteneurs (4) et envoyées à notre adaptateur de stockage de métriques.

Nous nous appuyons sur InfluxDB comme backend pour stocker toutes les données métriques. Afin d'être indépendants de ce backend, nous avons implémenté un service intermédiaire appelé Adaptateur de Stockage de Métriques qui traduit les appels API internes en requêtes InfluxDB. Ce niveau parle JSON et fournit un protocole standard pour accéder et récupérer les données métriques.

D'ailleurs, nous sommes très satisfaits d'InfluxDB. Cela correspond parfaitement à nos besoins et s'est avéré très fiable. Nous avons réalisé une POC (Proof of Concept) il y a près de 9 mois entre OpenTSDB, Prometheus et InfluxDB. Même si à l'époque, Influx n'était pas la base de données de séries temporelles la plus performante, elle a prouvé qu'elle s'améliorait très rapidement.

Enfin, lorsque votre navigateur affiche un graphique de métriques, il appelle notre API (7). La requête est transmise à notre adaptateur de stockage de métriques via un endpoint authentifié.

À l'avenir

Nous prévoyons déjà d'améliorer quelques aspects de ce nouveau composant Métriques. Par exemple, nous allons bientôt ajouter des mises à jour en temps réel, des graphiques de temps de réponse et un mécanisme d'alerte (la possibilité de déclencher des notifications lorsque vos conteneurs atteignent une certaine valeur).

De plus, comme nous utilisons InfluxDB en tant que produit interne, pourquoi ne pas le rendre disponible à tous nos clients en tant qu'option supplémentaire ?

Restez à l'écoute !