# Monitoring externe — app.cvmatching.fr

Dossier volontairement **séparé du SaaS** : héberge-le ailleurs si possible
(autre compte d'hébergement, autre serveur — même une petite instance
gratuite suffit). Si une panne totale du serveur du SaaS le mettait hors
service lui aussi, il ne pourrait jamais t'alerter. Si tu ne peux vraiment
le mettre que sur le même serveur, place-le au moins **hors de la racine
web publique** de l'app (comme ici, en dehors du dossier `app/`).

## Installation

1. Copie ce dossier `monitoring/` là où tu veux l'exécuter (il faut PHP en
   ligne de commande avec l'extension curl — `php -m | grep curl` pour
   vérifier).
2. Ouvre `config.php` et renseigne :
   - `alert_email` : ton adresse.
   - `alert_email_from` : idéalement un expéditeur sur un domaine
     *différent* de celui surveillé (voir plus bas si `mail()` ne part
     pas).
   - `targets` : ajoute d'autres URLs si tu veux aussi surveiller une page
     de connexion, un endpoint API, etc.
3. Teste manuellement :
   ```
   php check.php
   cat monitor.log
   ```
   Tu dois voir une ligne du type `OK  Page d'accueil (... ms)`.
4. Ajoute une tâche cron (toutes les 5 minutes par exemple) :
   ```
   */5 * * * * php /chemin/vers/monitoring/check.php >> /dev/null 2>&1
   ```

## Pages surveillées

`config.php` couvre maintenant toutes les pages navigables du SaaS :
pages publiques (accueil, connexion, inscription, mot de passe oublié...),
pages de travail (tableau de bord, recherche, conversion en lot, matching
inversé, rédaction d'offre, bibliothèque candidat...), la page d'achat
(tarifs & crédits) et les pages d'administration.

Les pages qui exigent une connexion redirigent une requête anonyme vers
`login.php` ; comme le monitor suit les redirections, la vérification se
termine sur la page de connexion (d'où `expect_contains: 'Connexion'` pour
toutes ces entrées). Ça confirme que l'app répond et que rien ne plante
avant la redirection — mais ça ne teste pas le contenu réel de ces pages
une fois connecté. Si tu veux un test plus poussé (vérifier qu'un CV se
convertit vraiment, par exemple), il faudrait un compte de test dédié et
un script différent — dis-moi si tu veux qu'on le prépare.

## Comportement

- N'alerte qu'après 2 échecs consécutifs (réglable via
  `failures_before_alert`) pour éviter les faux positifs sur un simple
  aléa réseau ponctuel.
- Une fois l'alerte « en panne » envoyée, elle n'est pas répétée à chaque
  passage du cron : un rappel toutes les heures seulement (réglable via
  `realert_after_seconds`), tant que ça n'est pas revenu.
- Une alerte « de nouveau en ligne » part dès le retour à la normale.
- `state.json` mémorise l'état entre deux exécutions — ne le supprime pas
  en cours de route (ça redéclenchera une alerte au prochain passage si le
  site est encore en panne à ce moment-là).
- `monitor.log` garde un historique, avec rotation simple au-delà de 2 Mo.

## Si les e-mails d'alerte n'arrivent pas

Beaucoup d'hébergements mutualisés bloquent ou filtrent `mail()`. Deux
solutions si ça ne part pas :
- utilise `alert_webhook_url` dans `config.php` à la place ou en plus
  (compatible Slack, Discord, ou un service simple comme ntfy.sh) ;
- héberge ce dossier ailleurs qu'où tourne actuellement `mail()` —
  justement l'intérêt de ne pas dépendre du même hébergeur que le SaaS.