Salud

Development

curl -fsS http://127.0.0.1:8091/health
curl -fsS http://127.0.0.1:8091/institution/status
curl -fsS http://127.0.0.1:8093/healthz
curl -fsS http://127.0.0.1:8094/health
# Si el stack conversation-ui está arriba:
curl -s -o /dev/null -w '%{http_code}\n' http://127.0.0.1:3080/
containers ps --format '{{.Names}}\t{{.Status}}' | grep sis-conversation-ui
ci-check          # compose + suites + guardianes; no vuelca secretos

ci-check es la validación única. No corras compose config a solas: imprime secretos.

VPS

containers ps -a --format '{{.Names}}\t{{.Status}}' | grep -E 'society|sis-conversation-ui'
ss -ltnp | grep -E '8091|8093|8094|3080|3081'
curl -s -o /dev/null -w '%{http_code}\n' https://sis.<cliente>.do/

tools/ops/prod-healthcheck.sh cada 5 min → badge del README (healthchecks.io). Rojo = algún VPS dejó de reportar, no un diagnóstico fino.

Barrido de huérfanos (también lo hace prod-up.sh al final):

for c in $(containers ps --format '{{.Names}}' | grep '^society'); do
  net=$(containers inspect $c --format '{{range $k,$v := .NetworkSettings.Networks}}{{$k}}{{end}}')
  [ -z "$net" ] && echo "$c SIN RED"
done

proxy de entrada no tiene directiva log en el proxy de cliente de referencia: sin access log. Tráfico real = upstream.

Tras tocar proxy de entrada: los 11 doalmacén de objetoss de siempre son el canario (incluido onto.* cuando existe). Un 200 en el servicio nuevo y un 502 en chat. es un deploy a medias.