Surveiller Elasticsearch et OpenSearch

Ce que vous saurez

• Le verdict de la grappe sur elle-même. Elasticsearch et OpenSearch indiquent vert, jaune ou rouge. Ce guide les traduit en « en bon état », « avertissement » et « problème » dans Gryphon.
• Si elle répond tout court. Une grappe qui ne répond pas est aussi un problème, avec la raison donnée par curl dans le message.

Jaune signifie que chaque shard primaire est attribué, mais pas certains réplicas. Les recherches fonctionnent encore, mais vous avez perdu une copie. Rouge signifie que des shards primaires ne sont pas attribués : certaines données ne peuvent être ni cherchées ni écrites. La plupart des ennuis d’une grappe se voient ici en premier.

Ce que ceci ne peut pas vous dire : si les recherches sont rapides, ou si le disque se remplit. Ajoutez la vérification Espace disque de l’agent pour chaque chemin de données. Par défaut, Elasticsearch met les index d’un nœud en lecture seule quand son disque est plein à 95 %.

Avant de commencer

• Une machine de la grappe ajoutée comme hôte dans Gryphon, avec l’agent Gryphon. Un seul nœud suffit : la santé de la grappe est la même, quel que soit le nœud interrogé.
• curl sur cette machine, pour le script de l’étape 2.

La marche à suivre dépend de l’activation de la sécurité, qui l’est par défaut depuis Elasticsearch 8. Si curl http://127.0.0.1:9200/_cluster/health sur la machine répond avec la santé de la grappe, la sécurité est désactivée et l’étape 1 suffit. S’il répond par une erreur, ou ne répond qu’en https://, passez à l’étape 2.

Étapes

1Sécurité désactivée : une vérification HTTP

Ouvrez l’hôte, allez dans Services, choisissez Ajouter le service, puis HTTP (agent).

Le point d’accès de santé répond 200 quelle que soit la couleur ; la couleur va donc dans La réponse contient. Tout autre état que le vert est alors un problème. Il n’y a pas d’avertissement ici : le jaune et le rouge sont traités de la même façon. Pour un avertissement sur le jaune, utilisez le script de l’étape 2 sans ses identifiants. Voir Variantes.

2Sécurité activée : une clé d’API et un script

Le point d’accès de santé exige un utilisateur dès que la sécurité est activée. Créez une clé d’API qui ne peut que lire l’état de la grappe, en vous connectant une fois en tant que elastic pour le faire. Avec une installation par paquet, l’autorité de certification de la grappe se trouve dans /etc/elasticsearch/certs :

sudo curl --cacert /etc/elasticsearch/certs/http_ca.crt -u elastic \
    -H 'Content-Type: application/json' -X POST https://127.0.0.1:9200/_security/api_key \
    -d '{"name": "gryphon", "role_descriptors": {"gryphon": {"cluster": ["monitor"]}}}'

La réponse contient une valeur encoded. Écrivez-la dans un fichier que seul root peut lire, dans le format de configuration de curl. Copiez ensuite l’autorité de certification à un endroit où l’agent peut la lire. Le dossier de l’original appartient au groupe elasticsearch, et c’est un certificat public, pas un secret.

header = "Authorization: ApiKey the-encoded-value"

sudo chmod 600 /etc/gryphon/elasticsearch.curl
sudo install -m 0644 /etc/elasticsearch/certs/http_ca.crt /etc/gryphon/elasticsearch-ca.crt
sudo install -d -o root -g root -m 0755 /etc/gryphon/scripts

Activez les vérifications par script, et faites remettre par systemd une copie du fichier de clé à l’agent à chaque démarrage ; la clé n’apparaît ainsi jamais dans un script ni sur une ligne de commande :

GWC_SCRIPTS_DIR=/etc/gryphon/scripts

[Service]
LoadCredential=elasticsearch:/etc/gryphon/elasticsearch.curl

sudo systemctl restart gryphon-agent

Enregistrez ceci sous /etc/gryphon/scripts/elasticsearch-health et rendez-le exécutable avec sudo chmod 755 /etc/gryphon/scripts/elasticsearch-health :

#!/bin/sh
# Elasticsearch's own verdict on its cluster: green, yellow or red.
ES=https://127.0.0.1:9200

health=$(curl -fsS -m 5 --cacert /etc/gryphon/elasticsearch-ca.crt -K "$CREDENTIALS_DIRECTORY/elasticsearch" \
    "$ES/_cat/health?h=status,node.total,unassign" 2>&1) || {
    case "$health" in
    *"error: 401"* | *"error: 403"*)
        echo "UNKNOWN: Elasticsearch refused the API key: $health"
        exit 3 ;;
    esac
    echo "CRITICAL: Elasticsearch did not answer: $health"
    exit 2
}
set -- $health
status=$1 nodes=$2 unassigned=$3

case "$status" in
green)
    echo "OK: cluster is green; nodes: $nodes"
    exit 0 ;;
yellow)
    echo "WARNING: cluster is yellow, $unassigned replica shards unassigned"
    exit 1 ;;
red)
    echo "CRITICAL: cluster is red, $unassigned shards unassigned"
    exit 2 ;;
esac
echo "UNKNOWN: unexpected answer: $health"
exit 3

Le code de sortie est l’état : 0 en bon état, 1 avertissement, 2 problème, 3 inconnu. La première ligne affichée est le message que vous verrez dans Gryphon et dans l’alerte. Une clé révoquée ou mal tapée donne un état inconnu, pas un problème de grappe, puisque c’est Gryphon qui ne voit pas, et non la grappe qui est en panne.

Ajoutez ensuite la vérification :

Faire un essai

1. Utilisez Vérifier maintenant sur la vérification. Une grappe en bon état dit qu’elle est verte, et combien de nœuds elle compte.
2. Sur une grappe de test à un seul nœud, créez un index qui veut un réplica qu’il ne pourra jamais avoir : curl -X PUT https://127.0.0.1:9200/gryphon-test -H 'Content-Type: application/json' -d '{"settings": {"number_of_replicas": 1}}', avec les mêmes --cacert et -u elastic qu’avant. La grappe passe au jaune, et la vérification la suit en avertissement.
3. Supprimez l’index avec -X DELETE sur la même adresse. La vérification revient en bon état.

Variantes

OpenSearch

OpenSearch répond à la même requête de santé dans le même format. Il n’a pas de clés d’API ; créez donc un utilisateur interne avec la permission cluster_monitor, et mettez plutôt son nom d’utilisateur et son mot de passe dans le fichier d’identifiants : user = "gryphon:the-password". Pointez --cacert vers l’autorité de certification de votre grappe. Avec le plugiciel de sécurité désactivé, utilisez la vérification HTTP de l’étape 1, ou le script avec l’adresse changée pour http:// et les options --cacert et -K retirées.

En marche ou en panne, sans aucune clé

Avec la sécurité activée, une vérification HTTPS (agent) sur 127.0.0.1, port 9200, avec Codes d’état acceptés réglé à 401, confirme qu’Elasticsearch répond en TLS sans connexion. Réglez Vérifier le certificat à false, car l’autorité de certification de la grappe n’est pas une autorité à laquelle l’agent fait confiance. Cette vérification ne dit rien de la couleur de la grappe, mais elle n’exige aucune clé.

Plusieurs grappes

Copiez le script sous un autre nom pour chacune, comme elasticsearch-health-logs, avec sa propre adresse ES, son certificat et son identifiant. Les scripts s’exécutent sans arguments ; chaque grappe a donc son propre fichier.