Défis

Observabilite pour Startups : Logs, Metriques et Traces sans se Ruiner

Par Marc Molas·4 juin 2024·10 min de lecture

Si vous apprenez les problemes en production par vos utilisateurs, vous n'avez pas d'observabilite -- vous avez un canal de support.

C'est une situation plus courante qu'il n'y parait. L'application plante, un client envoie un email furieux, l'equipe se met a fouiller les logs dans la console AWS, quelqu'un dit "chez moi ca marche" et deux heures passent avant que quelqu'un trouve le probleme. Ca vous rappelle quelque chose ?

L'observabilite n'est pas un luxe de grandes entreprises avec des equipes SRE dediees. C'est la capacite de comprendre ce qui se passe dans votre systeme sans avoir a deviner. Et dans une startup, ou chaque incident peut vous couter des utilisateurs (et le prochain tour de financement), c'est un investissement qui se rembourse des le premier jour.

Les trois piliers de l'observabilite

Il existe un framework classique qui divise l'observabilite en trois piliers : logs, metriques et traces. Ils ne sont pas interchangeables -- chacun repond a une question differente.

Logs : Que s'est-il passe ? Ce sont des enregistrements d'evenements discrets. Un utilisateur a tente de se connecter, une transaction a echoue, un service a redemarre.
Metriques : Combien et a quelle vitesse ? Ce sont des donnees numeriques agregees dans le temps. Latence moyenne, taux d'erreurs, utilisation CPU.
Traces : Ou dans le systeme ? C'est le parcours d'une requete a travers plusieurs services. La requete entre par l'API gateway, passe au service d'authentification, interroge la base de donnees, appelle le service de paiement.

Vous n'avez pas besoin des trois des le premier jour. Mais vous devez comprendre quand integrer chacun.

Logs : la base de tout

Tout systeme genere des logs. La difference reside dans le fait de les generer de maniere utile ou de simplement faire console.log("erreur ici") en esperant que ca suffise.

Le logging structure est la premiere chose a implementer. Au lieu de chaines de caracteres en vrac, generez des logs au format JSON avec des champs coherents : timestamp, niveau, service, message, request ID, utilisateur. Cela permet de rechercher, filtrer et agreger automatiquement.

{
  "timestamp": "2024-06-04T10:23:45Z",
  "level": "error",
  "service": "payment-api",
  "message": "Payment processing failed",
  "requestId": "abc-123",
  "userId": "user-456",
  "errorCode": "GATEWAY_TIMEOUT"
}

Les niveaux de log doivent avoir un sens. Si tout est INFO ou tout est ERROR, vous n'avez pas de niveaux -- vous avez du bruit. Definissez une convention claire : DEBUG pour le developpement, INFO pour les flux normaux, WARN pour les situations recuperables, ERROR pour les pannes qui necessitent une attention.

Centralisez vos logs. Si vous devez faire du SSH sur trois serveurs differents pour investiguer un probleme, vous avez deja perdu. Options selon le budget :

Budget minimal : Loki + Grafana (open source, leger, parfait pour commencer)
Cloud natif : CloudWatch Logs (AWS), Cloud Logging (GCP)
Tout-en-un : Datadog, New Relic (plus cher, mais plus complet)
Classique : ELK Stack (Elasticsearch, Logstash, Kibana) -- puissant mais necessite de la maintenance

Metriques : les 4 signaux dores

Google a defini les 4 signaux dores du monitoring, et ils restent le meilleur point de depart :

Latence : Combien de temps met votre service a repondre ? Pas seulement la moyenne -- ce sont les percentiles p95 et p99 qui comptent. Si votre latence moyenne est de 200ms mais que le p99 est a 5 secondes, vous avez un probleme que la moyenne masque.
Trafic : Combien de requetes recevez-vous ? Cela vous aide a comprendre les patterns d'utilisation et a detecter les anomalies (pics inattendus ou chutes soudaines).
Erreurs : Quel pourcentage de requetes echouent ? Tant les erreurs explicites (HTTP 5xx) que les implicites (reponses correctes mais avec des donnees erronees).
Saturation : A quel point votre systeme est-il charge ? CPU, memoire, disque, connexions a la base de donnees. Quand quelque chose sature, tout le reste commence a se degrader.

Il y a une distinction importante entre metriques applicatives et metriques d'infrastructure. Les metriques d'infrastructure (CPU, memoire, disque) vous disent que quelque chose ne va pas. Les metriques applicatives (requetes par seconde, taux d'erreurs, latence par endpoint) vous disent ce qui ne va pas. Vous avez besoin des deux.

Outils :

Prometheus + Grafana : Le standard open source. Prometheus collecte et stocke les metriques, Grafana les visualise. Gratuit, puissant, avec un ecosysteme enorme.
Datadog : Metriques, logs et traces sur une seule plateforme. Excellent mais couteux -- attention a la facture.
New Relic : Similaire a Datadog. Dispose d'un tier gratuit decent pour demarrer.

Traces : quand un seul service ne suffit plus

Si vous avez un monolithe simple, vous n'avez probablement pas encore besoin de traces distribuees. Mais des que vous avez deux services ou plus qui communiquent entre eux, les traces deviennent essentielles.

Une trace distribuee vous montre le parcours complet d'une requete a travers votre systeme. Vous voyez exactement ou le temps est consomme, ou ca echoue et quel service cause le goulot d'etranglement.

OpenTelemetry s'est impose comme le standard pour l'instrumentation. C'est open source, vendor-neutral, et supporte les logs, les metriques et les traces. Si vous allez investir du temps a instrumenter votre code, faites-le avec OpenTelemetry -- vous ne vous attachez a aucun fournisseur specifique.

Outils :

Jaeger : Open source, cree par Uber. Parfait pour demarrer avec les traces distribuees.
Zipkin : Autre option open source, plus simple que Jaeger.
Datadog APM / New Relic : Si vous utilisez deja leur plateforme pour les metriques, ajouter les traces est naturel.

Le stack adapte aux startups

N'essayez pas de tout implementer d'un coup. Voici une progression sensee :

Phase 1 -- Le minimum viable (des le jour 1) :

Logging structure en JSON
Logs centralises (Loki + Grafana ou CloudWatch)
Metriques de base d'infrastructure (ce que votre cloud provider offre gratuitement)
Alertes sur les erreurs HTTP 5xx et la latence

Phase 2 -- Maturation (quand vous avez des utilisateurs reels) :

Metriques applicatives avec Prometheus + Grafana
Dashboards par service avec les 4 signaux dores
Alertes plus sophistiquees avec niveaux de severite

Phase 3 -- Distribution (quand vous avez plusieurs services) :

OpenTelemetry pour l'instrumentation
Traces distribuees avec Jaeger ou votre APM de preference
Correlation entre logs, metriques et traces (le request ID est la cle)

Optimisation des couts : ne vous ruinez pas a monitorer

L'observabilite peut devenir couteuse rapidement. Datadog est excellent jusqu'a ce que vous voyiez la facture. Voici quelques strategies :

Sampling des traces : Vous n'avez pas besoin de tracer 100 % des requetes. 10 a 20 % suffisent generalement pour detecter les problemes. Tracez toujours les requetes en erreur.
Politiques de retention : Avez-vous besoin des logs d'il y a 6 mois ? Probablement pas pour le debugging quotidien. Definissez des retentions courtes pour les donnees detaillees et longues pour les metriques agregees.
Niveaux de log en production : N'envoyez pas de logs DEBUG en production. C'est du bruit couteux. INFO et au-dessus suffisent generalement.
Alertes intelligentes : Chaque alerte non actionnable est un cout -- pas seulement financier, mais en attention de l'equipe.

Alertes : l'art de ne pas generer de fatigue

Une mauvaise strategie d'alertes est pire que pas d'alertes du tout. Si votre equipe recoit 50 notifications par jour, elle apprendra a toutes les ignorer -- y compris celle qui compte.

Alertez sur les symptomes, pas sur les causes. Alertez quand le taux d'erreurs depasse 1 %, pas quand le CPU atteint 80 %. Le CPU a 80 % peut etre normal sous charge ; un taux d'erreurs de 5 % ne l'est jamais.

Chaque alerte a besoin d'un runbook. Si quelqu'un recoit une alerte a 3 heures du matin, il devrait savoir exactement quoi regarder en premier. Sans runbook, c'est la panique + SSH + "c'est quoi ca".

Classez par severite. Tout n'est pas urgent. Une erreur intermittente sur un endpoint peu utilise peut attendre demain. Une panne du service de paiement, non.

L'observabilite comme culture

L'observabilite n'est pas qu'une question d'outils -- c'est un etat d'esprit d'ingenierie. Les equipes qui l'adoptent des le debut debugguent plus vite, deploient avec plus de confiance et dorment mieux.

Chez Conectia, les ingenieurs senior que nous integrons dans votre equipe construisent des systemes observables par defaut. Pas comme un ajout apres la troisieme panne en production, mais comme partie integrante de l'architecture. Parce que quand votre systeme grandit et que la complexite augmente, la difference entre une equipe qui sait ce qui se passe en production et une qui devine, c'est la difference entre scaler et survivre.

Votre equipe apprend les problemes en production par les utilisateurs ? Parlez a un CTO -- nous integrons des ingenieurs senior qui construisent l'observabilite des le premier deploiement.