Le monitoring SaaS, c'est l'un des domaines où la maturité d'un éditeur se voit le plus vite. Un simple uptime check externe vous dit si votre site répond, pas s'il fonctionne correctement pour vos utilisateurs. Une dégradation de latence sur l'API de paiement, une saturation progressive d'une file Messenger, une explosion des temps de requête BDD : autant de signaux faibles qui précèdent l'incident, mais qu'aucun ping ICMP ne capte. La stack open source Grafana + Prometheus + Loki est devenue le standard de fait pour observer ces signaux faibles, sans dépendance à un acteur extra-européen type Datadog ou New Relic.
Pourquoi monitorer au-delà du simple uptime check
Un uptime check répond à une question binaire : le site répond-il en 200 OK ? Mais la majorité des incidents qui dégradent la satisfaction utilisateur ne basculent jamais en 500. Une page qui charge en 8 secondes au lieu de 800 ms, une recherche qui timeout silencieusement, un export PDF qui plante sur 5 % des cas : tout ça passe sous le radar d'un simple uptime.
Trois bénéfices concrets justifient un monitoring complet sur un SaaS B2B. La détection précoce des dégradations permet d'intervenir avant que les clients ne déposent un ticket. La satisfaction utilisateur devient mesurable et corrélable à des métriques applicatives. La conformité SLA contractuelle exige une preuve auditable de la disponibilité réelle, pas juste de la disponibilité ressentie.
D'expérience, sur les SaaS Symfony en version LTS que je maintiens, l'investissement dans une stack monitoring complète se rentabilise dès le premier incident évité, et systématiquement lors des due diligence client.
Les 3 piliers de l'observabilité
L'observabilité s'organise autour de trois familles de signaux complémentaires. Aucune ne remplace les autres.
- Métriques : valeurs numériques agrégées dans le temps (CPU, mémoire, requêtes/sec, latence P95). Volumétrie faible, rétention longue, idéales pour les tableaux de bord et les alertes sur seuils.
- Logs : événements textuels datés (requêtes HTTP, erreurs applicatives, audit). Volumétrie élevée, rétention plus courte, indispensables pour le debug post-incident.
- Traces : suivi distribué d'une requête à travers les services (frontend, API, BDD, files). Volumétrie variable, échantillonnage fréquent, utiles pour identifier les goulets d'étranglement.
À ces trois piliers s'ajoute un quatrième élément transverse : les alertes, déclenchées sur seuils ou anomalies, qui transforment l'observation passive en action opérationnelle.
Le triptyque open source : Prometheus, Loki, Grafana
Les trois outils sont développés de manière coordonnée, principalement par Grafana Labs, et conçus pour fonctionner ensemble.
- Prometheus : moteur de collecte et de stockage de métriques temps réel. Modèle pull (Prometheus interroge les exporters), langage de requête PromQL, projet CNCF gradué depuis 2018.
- Loki : système d'agrégation de logs inspiré de Prometheus mais dédié aux logs. Indexation par labels seulement (pas de full-text), volumétrie économique, requêtage via LogQL.
- Grafana : couche de visualisation et d'alerting. Tableaux de bord composables, support natif de Prometheus et Loki, gestion des alertes via AlertManager ou son moteur intégré.
La cohérence du triptyque, c'est son atout majeur : un même tableau de bord Grafana corrèle visuellement une hausse d'erreurs 5xx (Prometheus) avec les logs applicatifs concernés (Loki) sur la même fenêtre temporelle.
Pourquoi cette stack plutôt que Datadog ou New Relic
Datadog et New Relic sont d'excellents produits. Mais leur modèle pose trois problèmes pour un éditeur SaaS européen indépendant ou TPE.
- Souveraineté : ce sont des SaaS américains soumis au Cloud Act. Vos logs, qui peuvent contenir des données personnelles européennes, transitent et sont stockés hors UE. Le RGPD complique sérieusement leur usage.
- Coût : la facturation à l'host, à la métrique, ou au gigaoctet de logs explose dès que le SaaS prend du volume. Sur un éditeur en croissance, la facture annuelle dépasse vite plusieurs milliers d'euros, à comparer au coût d'auto-hébergement Prometheus + Loki + Grafana qui se compte en quelques dizaines d'euros par mois pour la même charge.
- Verrouillage : les agents propriétaires, les requêtes spécifiques, les tableaux de bord non exportables créent une dépendance forte qui rend la migration coûteuse.
La stack open source se déploie sur votre propre infrastructure souveraine (Scaleway, OVH, Infomaniak ou auto-hébergement Proxmox), s'intègre nativement à l'écosystème Symfony via le client PHP Prometheus ou OpenTelemetry, et reste 100 % exportable via les standards ouverts.
Architecture type pour un SaaS B2B
Voici l'architecture que je déploie le plus souvent sur les SaaS Symfony que j'accompagne, sur un setup Proxmox ou un dédié OVH/Scaleway.
| Composant | Rôle | Localisation |
|---|---|---|
| Node Exporter | Métriques système (CPU, RAM, disque, réseau) | Sur chaque VM / conteneur |
| MariaDB Exporter | Métriques BDD (connexions, queries, slow log) | Sur le nœud BDD |
| PHP-FPM Exporter | Métriques PHP (workers actifs, queue) | Sur les nœuds applicatifs |
| Symfony Prometheus client | Métriques métier (latence par route, erreurs) | Embarqué dans l'application |
| Promtail | Collecte des logs et envoi vers Loki | Sur chaque nœud |
| Prometheus | Stockage métriques, scraping des exporters | Nœud monitoring central |
| Loki | Stockage et indexation des logs | Nœud monitoring central |
| Grafana | Tableaux de bord et alerting | Nœud monitoring central |
| AlertManager | Routage des alertes (Slack, email, PagerDuty) | Nœud monitoring central |
Le nœud monitoring central est dédié et dimensionné pour stocker plusieurs mois de métriques et quelques semaines de logs. Sur les SaaS B2B de taille moyenne, une VM 4 vCPU / 8 Go RAM / 200 Go SSD suffit largement.
Les métriques essentielles à monitorer
Tout monitorer, c'est ne rien monitorer. Voici la liste minimale que je mets systématiquement en place sur les SaaS B2B Symfony.
- Disponibilité : taux d'uptime mesuré côté serveur et côté supervision externe (sonde indépendante).
- Latence applicative : percentiles P50, P95, P99 sur les routes critiques. Le P95 est le bon indicateur de qualité ressentie.
- Taux d'erreur HTTP 5xx : alerte si plus de 1 % des requêtes retournent une erreur serveur sur une fenêtre de 5 minutes.
- Saturation CPU, RAM, disque : alerte préventive à 80 %, alerte critique à 95 %.
- BDD MariaDB : nombre de connexions actives, slow queries (> 1 s), taille de la base, lag de réplication si applicable.
- Files Messenger : taille de chaque queue, lag de traitement, taux d'échecs. Une queue qui grossit linéairement est le signal le plus fiable d'une saturation backend.
- Certificats TLS : alerte 30 jours avant expiration, redondante avec le renouvellement Let's Encrypt automatisé.
Cette liste se complète selon le métier : taux de conversion d'un funnel, durée d'export, taux de bounces email, etc. Le principe reste le même : alerter sur les indicateurs qui prédisent l'incident, pas seulement ceux qui le constatent une fois qu'il est là.
OpenTelemetry : l'évolution standard
OpenTelemetry est le standard CNCF unifié pour la collecte de métriques, logs et traces. À terme, il remplacera les clients Prometheus spécifiques par un format universel, agnostique du backend de stockage.
Pour un SaaS Symfony 2026, je recommande de partir directement sur l'OpenTelemetry SDK PHP côté applicatif, en exposant les métriques au format Prometheus pour conserver la compatibilité avec la stack Grafana / Prometheus / Loki. Cette approche évite le verrouillage technique tout en bénéficiant de la maturité actuelle de Prometheus.
Mettre en place une stack monitoring sur votre SaaS
Le déploiement initial d'une stack Grafana + Prometheus + Loki sur un SaaS Symfony existant tient en quelques jours d'accompagnement : provisionning du nœud monitoring, instrumentation de l'application via le client PHP Prometheus, configuration des exporters système et BDD, premiers tableaux de bord et règles d'alerte. Le retour sur investissement se mesure dès le premier incident détecté en avance, et systématiquement lors des audits clients.
Pour bien situer le monitoring dans la stratégie globale, mon article sur Proxmox pour TPE détaille l'infrastructure cible souveraine, et mon guide Core Web Vitals SaaS Symfony aborde le monitoring côté navigateur (RUM) qui complète le monitoring côté serveur. Comme tous mes accompagnements, le périmètre et le tarif sont définis sur devis personnalisé après un échange initial gratuit de 30 minutes. Mon guide du développement SaaS sur-mesure détaille le cycle complet d'un projet de la conception à la maintenance. Le formulaire de contact permet de prendre date.
