|
Ce document a été traduit à l'aide d'une technologie de traduction automatique. Bien que nous nous efforcions de fournir des traductions exactes, nous ne fournissons aucune garantie quant à l'exhaustivité, l'exactitude ou la fiabilité du contenu traduit. En cas de divergence, la version originale anglaise prévaut et fait foi. |
Ajoutez un moniteur de seuil aux composants en utilisant le CLI
Présentation
SUSE Observability fournit des moniteurs prêts à l’emploi, qui offrent une surveillance des problèmes courants pouvant survenir dans un cluster Kubernetes. Il est également possible de configurer des moniteurs personnalisés pour les métriques collectées par SUSE Observability ou les métriques d’application ingérées depuis Prometheus.
Étapes
Étapes pour créer un moniteur :
À titre d’exemple, les étapes ajouteront un moniteur pour le Replica counts des déploiements Kubernetes.
Rédigez le plan du moniteur
Créez un nouveau fichier YAML appelé monitor.yaml et ajoutez ce modèle YAML pour créer votre propre moniteur. Ouvrez-le dans votre éditeur de code préféré pour le modifier tout au long de ce guide. À la fin, le SUSE Observability CLI sera utilisé pour créer et mettre à jour le moniteur dans SUSE Observability.
nodes:
- _type: Monitor
arguments:
metric:
query:
unit:
aliasTemplate:
comparator:
threshold:
failureState:
urnTemplate:
titleTemplate:
description:
function: {{ get "urn:stackpack:common:monitor-function:threshold" }}
identifier: urn:custom:monitor:...
intervalSeconds: 30
name:
remediationHint:
status:
tags: {}
Les champs de ce modèle sont :
-
_type: SUSE Observability doit savoir qu’il s’agit d’un moniteur, donc la valeur doit toujours êtreMonitor -
query: Une requête PromQL. Utilisez l’explorateur métrique de votre instance SUSE Observability, http://your-instance/#/metrics, et utilisez-le pour construire une requête pour la métrique d’intérêt. -
unit: L’unité des valeurs dans la série temporelle renvoyée par la ou les requêtes, utilisée pour rendre l’axe Y du graphique. Voir la référence des unités prises en charge pour toutes les unités. -
aliasTemplate: Un alias pour les séries temporelles dans le graphique métrique. Ceci est un modèle qui peut substituer des étiquettes des séries temporelles en utilisant l’espace réservé${my_label}. -
comparator: Choisissez l’un des LTE/LT/GTE/GT pour comparer le seuil par rapport à la métrique. Les séries temporelles pour lesquelles<metric> <comparator> <threshold>est vrai produiront l’état d’échec. -
threshold: Un seuil numérique à comparer. -
failureState: Soit "CRITIQUE" soit "DÉVIANT". "CRITIQUE" apparaîtra en rouge dans SUSE Observability et "DÉVIANT" en orange, pour indiquer une gravité différente. -
urnTemplate: Un modèle pour construire l’urn du composant dont le résultat du moniteur sera lié à. -
titleTemplate: Un titre pour le résultat d’un moniteur. Parce que plusieurs résultats de moniteur peuvent être liés au même composant, il est possible de substituer les étiquettes des séries temporelles en utilisant le${my_label}espace réservé. -
description: Une description du moniteur. -
function: Une référence à la fonction de moniteur qui exécutera le moniteur. Actuellement, seul{{ get "urn:stackpack:kubernetes-v2:shared:monitor-function:threshold" }}est pris en charge. -
identifier: Un identifiant de la formeurn:custom:monitor:….qui identifie de manière unique le moniteur lors de la mise à jour de sa configuration. -
intervalSeconds: L’intervalle auquel le moniteur s’exécute. Pour les métriques en temps réel régulières, 30 secondes sont conseillées. Pour les requêtes analytiques de métriques de longue durée, un intervalle plus grand est recommandé. -
name: Le nom du moniteur -
remediationHint: Une description de ce que l’utilisateur peut faire en cas d’échec du moniteur. Le format est markdown, avec éventuellement l’utilisation de variables handlebars pour personnaliser l’indice en fonction des séries temporelles ou d’autres données (plus d’explications ci-dessous). -
status: Soit"DISABLED"soit"ENABLED". Détermine si le moniteur s’exécutera ou non. -
tags: Ajoutez des étiquettes au moniteur pour aider à les organiser dans l’aperçu des moniteurs de votre instance SUSE Observability, http://your-SUSE Observability-instance/#/monitors
Par exemple, cela pourrait être le début d’un moniteur qui surveille les répliques disponibles d’un déploiement :
nodes:
- _type: Monitor
arguments:
metric:
query: "kubernetes_state_deployment_replicas_available"
unit: "short"
aliasTemplate: "Deployment replicas"
comparator: "LTE"
threshold: 0.0
failureState: "DEVIATING"
urnTemplate:
description: "Monitor whether a deployment has replicas.
function: {{ get "urn:stackpack:kubernetes-v2:shared:monitor-function:threshold" }}
identifier: urn:custom:monitor:deployment-has-replicas
intervalSeconds: 30
name: Deployment has replicas
remediationHint:
status: "ENABLED"
tags:
- "deployments"
Les urnTemplate et remediationHint seront remplis dans les étapes suivantes.
Associez les résultats du moniteur aux bons composants
Les résultats d’un moniteur doivent être liés aux composants dans SUSE Observability, pour être visibles et utilisables. Le résultat d’un moniteur est lié à un composant en utilisant le composant identifiers. Chaque composant dans SUSE Observability a un ou plusieurs identifiants qui identifient de manière unique le composant. Pour lier un résultat d’un moniteur à un composant, il est nécessaire de fournir le urnTemplate. Le urnTemplate substitue les étiquettes dans les séries temporelles du résultat du moniteur dans le modèle, produisant un identifiant correspondant à un composant. Cela est mieux illustré par l’exemple :
La métrique utilisée dans cet exemple est la métrique kubernetes_state_deployment_replicas_available. Exécutez la métrique dans l’explorateur de métriques pour observer quelles étiquettes sont disponibles sur la série temporelle :
Dans le tableau ci-dessus, il est montré que la métrique a des étiquettes comme cluster_name, namespace et deployment.
Parce que la métrique est observée sur des déploiements, il est plus logique de lier les résultats du moniteur aux composants de déploiement. Pour ce faire, il est nécessaire de comprendre comment les identifiants pour les déploiements sont construits :
-
Dans l’interface utilisateur, naviguez vers la vue
deploymentset sélectionnez un seul déploiement. -
Ouvrez la vue
Topologyet cliquez sur le composant de déploiement. -
En développant le
Propertiesdans le panneau de droite de l’écran, les identifiants s’afficheront après avoir survolé comme indiqué ci-dessous :
L’identifiant est affiché sous la forme urn:kubernetes:/preprod-dev.preprod.stackstate.io:calico-system:deployment/calico-typha. Cela montre que l’identifiant est construit en fonction du nom du cluster, de l’espace de noms et du nom du déploiement. Sachant cela, il est maintenant possible de construire le urnTemplate :
...
urnTemplate: "urn:kubernetes:/${cluster_name}:${namespace}:deployment/${deployment}"
...
Pour vérifier si le urnTemplate est correct, cela est expliqué plus loin ci-dessous.
Écrivez l’indice de remédiation
L’indice de remédiation est là pour aider les utilisateurs à trouver la cause d’un problème lorsqu’un moniteur se déclenche. L’indice de remédiation est rédigé en markdown. Il est également possible d’utiliser les étiquettes qui se trouvent sur la série temporelle du résultat du moniteur en utilisant un modèle handlebars, comme dans l’exemple suivant :
...
remediationHint: |-
To remedy this issue with the deployment {{ labels.deployment }}, consider taking the following steps:
1. Look at the logs of the pods created by the deployment
...
Créez ou mettez à jour le moniteur dans SUSE Observability
Après avoir complété le monitor.yaml, utilisez le SUSE Observability CLI pour créer ou mettre à jour le moniteur :
sts monitor apply -f monitor.yamlVérifiez si le moniteur produit les résultats attendus, en utilisant les étapes ci-dessous.
|
L’identifiant est utilisé comme clé unique d’un moniteur. Changer l’identifiant créera un nouveau moniteur au lieu de mettre à jour l’existant. |
La commande sts monitor a plus d’options, par exemple, elle peut lister tous les moniteurs :
sts monitor listPour supprimer un moniteur, utilisez
sts monitor delete --id <id>Pour modifier un moniteur, modifiez l’original du moniteur qui a été appliqué, puis appliquez à nouveau. Ou il existe une commande sts monitor edit pour modifier le moniteur configuré directement dans l’instance SUSE Observability :
sts monitor edit --id <id>Le <id> dans cette commande n’est pas l’identifiant mais le numéro dans la colonne Id de la sortie sts monitor list.
Activer ou désactiver le moniteur
Un moniteur peut être activé ou désactivé. Activé signifie que le moniteur produira des résultats, désactivé signifie qu’il supprimera toute sortie. Utilisez les commandes suivantes pour activer/désactiver :
sts monitor enable/disable --id <id>Vérification des résultats d’un moniteur
Il est bon de valider, après la création d’un moniteur, s’il produit le résultat attendu. Les étapes suivantes peuvent être suivies :
Vérifiez l’exécution du moniteur
Allez sur la page d’aperçu des moniteurs (http://votre-instance-SUSE Observability/#/monitors) et trouvez votre moniteur.
-
Vérifiez que la colonne
Statusest dans l’étatEnabled. Si le moniteur est dans l’étatDisabled, activez-le. Si le statut est dans l’étatError, suivez les étapes ci-dessous pour déboguer. -
Vérifiez que vous voyez le nombre attendu d’états dans la colonne
Clear/Deviating/Critical. Si le nombre d’états est significativement inférieur ou supérieur au nombre de composants que vous souhaitiez surveiller, la requête PromQL pourrait donner trop de résultats.
Vérifiez la liaison du moniteur.
Observez si le moniteur produit un résultat sur l’un des composants qu’il est censé surveiller. Si le moniteur n’apparaît pas, suivez ces étapes pour remédier à la situation.
Problèmes courants
Le résultat du moniteur n’apparaît pas sur un composant
Vérifiez d’abord si le moniteur produit des résultats. Si c’est le cas mais que les résultats du moniteur n’apparaissent pas sur les composants, il pourrait y avoir un problème avec la liaison. Utilisez d’abord la commande suivante pour vérifier :
sts monitor status --id <id>Si la sortie contient Monitor health states with identifier which has no matching topology element (<nr>): …., cela montre que le urnTemplate peut ne pas générer un identifiant correspondant à la topologie. Pour remédier à cela, revoyez votre urnTemplate.