Contrail Networking Analytics
Présentation : Analyses
L’analyse est un ensemble de fonctionnalités facultatives de La version 22.1 de Juniper Cloud-Native Contrail® Networking™. Il est fourni séparément des composants CNI centraux de Contrail Networking et dispose de sa propre procédure d’installation. Le package est constitué d’une combinaison de logiciels open source et de logiciels développés par Juniper.
Les fonctionnalités d’analyse sont classées dans les domaines fonctionnels de haut niveau suivants :
- Métriques : données chronologiques statistiques collectées à partir des composants Contrail Networking et du système Kubernetes de base.
- Enregistrements de flux et de session : informations sur le trafic réseau collectées à partir du vRouter Contrail Networking.
- Sandesh User Visible Entities (UVE) : enregistrements représentant l’état à l’échelle du système des objets visibles externes qui sont collectés à partir du vRouter contrail Networking et des composants de nœud de contrôle.
- Journaux : consigner les messages collectés sur les pods Kubernetes.
- Introspect : un utilitaire de diagnostic qui permet de parcourir l’état interne des composants Contrail Networking.
Métriques
Modèle de données
Les informations métriques sont basées sur un modèle de données de séries temporelles numériques. Chaque point de données d’une série est un échantillon d’un état système qui est collecté à intervalle régulier. Une valeur échantillonné est enregistrée ainsi qu’un horodatage auquel la collecte s’est produite. Un exemple d’enregistrement peut également contenir un ensemble optionnel de paires clé-valeur appelés labels. Les étiquettes offrent une capacité de dimension pour les métriques où une combinaison donnée de labels pour le même nom de mesure identifie une instanciation dimensionnelle particulière de cette mesure. Par exemple, une métrique nommée api_http_requests_total
peut utiliser des étiquettes afin d’offrir une visibilité sur le nombre de requêtes au niveau de l’URL et du type de méthode. Dans l’exemple suivant, l’enregistrement métrique d’une valeur d’échantillon de 10 inclut un ensemble de labels qui indiquent le type de demande.
api_http_requests_total{method="POST", handler="/messages"} 10
Types de données métriques
Bien que toutes les valeurs métriques ne soient que des nombres, il existe un concept de type dans ce modèle de données numérique. Une métrique est considérée comme l’un des types suivants :
- Compteur : mesure cumulative qui représente un compteur monotoniquement croissant dont la valeur ne peut augmenter ou être réinitialisée à zéro qu’au redémarrage.
- Jauge : mesure qui représente une valeur numérique unique pouvant arbitrairement monter et descendre.
- Histogramme : un histogramme extrait des observations (généralement des éléments tels que la durée des requêtes ou la taille de la réponse) et les compte dans des compartiments configurables. L’histogramme fournit également une somme de toutes les valeurs observées.
- Résumé : semblable à un histogramme, un récapitulatif des observations d’échantillons (généralement des éléments tels que la durée des requêtes et la taille des réponses). Bien qu’il fournit également un compte total des observations et une somme de toutes les valeurs observées, le résumé calcule les quantiles configurables sur une fenêtre de temps coulissante.
La fonctionnalité métrique de Contrail Networking est implémentée par Prometheus. Pour plus d’informations sur le modèle de données métriques, reportez-vous à la documentation sur Prometheus.
Mesures prises en charge
L’ensemble des mesures prises en charge par la solution d’analyse sont classés comme indiqué ci-dessous :
- Liste de mesures Contrail Networking : métriques collectées à partir des composants du vRouter et du nœud de contrôle.
- Liste de mesures Kubernetes : métriques collectées à partir de divers composants Kubernetes, tels que
apiserver
,etcd
,kubelet
, et ainsi de suite. - Métriques des nœuds de cluster : métriques au niveau de l’hôte collectées à partir des nœuds du cluster Kubernetes.
Alertes
Les alertes sont générées sur la base d’une analyse des données métriques collectées. Chaque type d’alerte pris en charge repose sur une définition de règle qui contient les informations suivantes :
- Nom de l’alerte : identifiant de chaîne unique pour le type d’alerte.
- Expression de condition : expression du langage de requête Prometheus qui est évaluée par rapport aux valeurs métriques collectées afin de déterminer si la condition d’alerte existe.
- Durée des conditions : délai nécessaire à la condition problématique pour générer l’alerte.
- Gravité : niveau d’alerte (critique, majeur, avertissement, info).
- Résumé : brève description de la condition problématique.
- Description : description détaillée de la condition problématique.
La solution d’analyse Contrail Networking installe un ensemble de règles d’alerte prédéfinies. Vous pouvez également définir vos propres règles d’alerte personnalisées. Cela est pris en charge par la création de ressources Kubernetes PrometheusRule dans l’espace de noms où le graphique de barre d’analyse est déployé. Un exemple de règle d’alerte personnalisée est illustré ci-dessous.
apiVersion: monitoring.coreos.com/v1 kind: PrometheusRule metadata: name: acme-corp-rules spec: groups: - name: acme-corp.rules rules: - alert: HostUnusualNetworkThroughputOut expr: "sum by (instance) (rate(node_network_transmit_bytes_total[2m])) / 1024 / 1024 > 100" labels: severity: warning annotations: summary: "Host unusual network throughput out (instance {{ $labels.instance }})" description: "Host network interfaces are sending too much data (> 100 MB/s)\n VALUE = {{ $value }}"
Les alertes générées sont stockées sous forme d’enregistrements dans Prometheus et peuvent être consultées dans l’interface utilisateur de Grafana. Le composant AlertManager prend également en charge l’intégration avec des systèmes externes tels que PagerDuty, OpsGenie, par e-mail, etc. pour les notifications d’alertes.
Architecture
Comme le montre la figure 1, Prometheus est le composant central de l’architecture métrique. Prometheus implémente les fonctionnalités suivantes :
- Collecte : mécanisme d’interrogation périodique qui appelle des appels d’API sur d’autres composants (exportateurs) pour extraire des valeurs pour un ensemble de mesures.
- Stockage : base de données chronologiques qui fournit la persistance des mesures recueillies auprès des exportateurs.
- Requête : API prenant en charge un langage d’expression appelé PromQL (Prometheus Query Language) qui permet de récupérer les informations de mesure historiques de la base de données.
- Alertes : cadre permettant de définir des règles qui produisent des alertes lorsque certaines conditions sont observées dans les données métriques collectées.

Les autres composants de l’architecture métrique sont les suivants :
- Grafana : un service qui fournit une interface utilisateur Web permettant à l’utilisateur de visualiser les données métriques dans des graphiques.
- AlertManager : service d’intégration qui informe les systèmes externes des alertes générées par Prometheus.
Configuration
La fonctionnalité de métriques ne nécessite aucune configuration par l’utilisateur final. L’installation de l’analytique se charge de configurer Prometheus pour collecter auprès de l’ensemble des exportateurs qui fournissent toutes les mesures décrites dans la section Mesures prises en charge ci-dessus. Un groupe de règles d’alerte par défaut est également automatiquement configuré dans le cadre de l’installation. Cette fonctionnalité de base peut cependant être étendue par l’utilisateur final grâce à une configuration supplémentaire après l’installation. Par exemple, il est possible de définir des règles d’alerte spécifiques aux clients et de configurer AlertManager pour s’intégrer à n’importe quel système externe pris en charge dans votre environnement.
La configuration de Prometheus et AlertManager implique un composant architectural supplémentaire appelé Opérateur Prometheus. Comme le montre la figure 2, la configuration est spécifiée en tant que ressources personnalisées Kubernetes. L’opérateur est chargé de traduire le contenu de ces ressources dans la configuration native comprise par les composants Prometheus, de mettre à jour les composants en conséquence, puis de redémarrer les composants chaque fois qu’un changement de configuration particulier nécessite un redémarrage.

La documentation sur l’ensemble des ressources prises en charge par l’opérateur est disponible sur l’API Opérateur Prometheus. Il est toutefois recommandé aux clients de limiter leurs configurations au sous-ensemble de types de ressources liés à la définition des règles d’alerte et à l’intégration de systèmes externes.
Grafana
L’interface utilisateur principale pour l’affichage des données métriques et des alertes est Grafana. Le service Grafana est configuré automatiquement avec Prometheus comme source de données dans le cadre de l’installation analytique. Un ensemble de tableaux de bord par défaut sont également créés.
Accédez à l’interface utilisateur Web de Grafana à l’adresse : https://<k8sClusterIP>/grafana/login
. Les informations d’identification par défaut sont l’utilisateur admin
et le mot de passe prom-operator
.