#!/bin/bash
# GENERE par Set-OPS (role serveur_loki). Ne pas editer a la main.
#
# SONDE « ingestion » — l'ingesteur est pret, pas seulement le port ouvert
#
# Contrat : docs/supervision-conception.md (API des greffons Nagios) — une ligne, 0/1/2.
# Mise en defaut PAR PARAMETRE : `serveur_loki_sonde_url` (port ferme).
set -uo pipefail

URL={{ serveur_loki_sonde_url }}

# `/ready` ET PAS UN connect(). Loki ouvre son port bien avant que son ingesteur ne soit
# pret ; pendant cette fenetre il accepte et perd. C'est exactement « un connect() ne
# prouve rien », applique a un demon qui demarre.
s=$(curl -sk --max-time 10 "${URL}/ready" 2>/dev/null)
[[ -n "${s}" ]] || { echo "Loki ne repond pas sur ${URL}."; exit 2; }
if printf '%s' "${s}" | grep -qi '^ready'; then
  echo "Loki pret a ingerer."
  exit 0
fi

# LE DELAI DE STABILISATION N'EST PAS UNE PANNE, ET LE MESSAGE LE DIT LUI-MEME.
# Apres un redemarrage, Loki repond « Ingester not ready: waiting for Ns AFTER BEING
# READY » — l'ingesteur EST pret, il purge son delai. Mesure du 2026-09-10 : l'anneau
# etait `ACTIVE` et la reponse est passee a `ready` moins d'une minute plus tard.
#
# J'ai d'abord conclu « panne persistante » sur deux lectures prises a quelques secondes
# d'intervalle, juste apres un redemarrage. Deux mesures rapprochees ne distinguent pas un
# etat d'un instant. On nomme donc ce cas pour ce qu'il est : un AVERTISSEMENT transitoire,
# pas une panne — sans pour autant le taire, parce qu'un delai qui ne finirait jamais
# serait, lui, une vraie panne.
if printf '%s' "${s}" | grep -qi 'after being ready'; then
  echo "Loki sort d'un redemarrage (delai de stabilisation) : ${s:0:80}"
  exit 1
fi
echo "Loki n'est PAS pret a ingerer : ${s:0:90}"
exit 2