Un dashboard vide produit une réaction presque automatique : redémarrer le service, relancer les agents, réinitialiser la configuration ou modifier les permissions.
C’est souvent le mauvais premier geste.
Un écran sans données ne signifie pas nécessairement que les données ont disparu. Il peut signaler un problème d’URL, une interface frontend qui ne charge pas ses ressources, une session utilisateur incomplète, une règle de visibilité trop restrictive ou une chaîne de collecte partiellement rompue.
Dans un environnement auto-hébergé, ces couches se ressemblent suffisamment pour provoquer de faux diagnostics. Un service peut répondre correctement alors que son interface affiche une erreur. Une API peut être saine alors que le navigateur pointe vers une adresse obsolète. Les agents peuvent continuer à collecter des métriques alors qu’un compte n’a plus le droit de les voir.
La bonne approche consiste à traiter le dashboard comme un symptôme, puis à remonter la chaîne sans modifier la production tant que les faits ne sont pas établis.
Le modèle mental : séparer les couches
Pour éviter les conclusions hâtives, je découpe le problème en couches indépendantes :
- Le service : le processus répond-il et son port est-il accessible ?
- L’URL et le proxy : le navigateur atteint-il le bon point d’entrée ?
- L’API : les endpoints renvoient-ils des réponses cohérentes ?
- Les agents : la collecte continue-t-elle réellement ?
- La base ou le stockage : les données existent-elles encore ?
- La session : le navigateur utilise-t-il une session valide ?
- Les permissions : le compte courant a-t-il le droit de consulter ces données ?
- Le frontend : l’interface affiche-t-elle correctement une réponse pourtant valide ?
Cette liste est volontairement prosaïque. Elle empêche de confondre un symptôme visible avec sa cause.
1. Commencer par une observation en lecture seule
La première question n’est pas « qu’est-ce que je peux redémarrer ? », mais :
Quelle partie de la chaîne est réellement cassée ?
Je commence par relever le symptôme exact : écran vide, erreur JavaScript, réponse HTTP inattendue, absence d’un seul hôte, historique tronqué ou données visibles pour un compte mais pas pour un autre.
Je note aussi ce qui fonctionne encore. Un service accessible depuis une autre page, une métrique récente dans une autre vue ou une réponse API correcte sont des points d’ancrage précieux.
Cette discipline paraît lente, mais elle réduit le risque de transformer un problème d’affichage en incident de production.
2. Vérifier le service avant de toucher à la configuration
Un contrôle de santé minimal permet de répondre à quelques questions factuelles :
- le processus est-il actif ?
- le port écoute-t-il ?
- une requête locale obtient-elle une réponse ?
- les logs récents montrent-ils une erreur de démarrage ou seulement une erreur de requête ?
Il faut distinguer « le service est arrêté » de « le service répond mais l’interface ne l’exploite pas ». Dans le premier cas, l’investigation porte sur le runtime et le déploiement. Dans le second, redémarrer ne fera que masquer temporairement le problème.
À ce stade, je privilégie les vérifications non destructives : état du processus, statut du conteneur, test HTTP, lecture des logs et inspection de la configuration existante.
3. Vérifier l’URL réellement utilisée par le navigateur
Les applications de monitoring sont souvent composées de plusieurs adresses : URL publique, endpoint d’API, adresse interne entre conteneurs et URL annoncée aux agents.
Une interface peut donc se charger depuis la bonne adresse tout en essayant ensuite d’appeler une API qui n’est plus valide. Le résultat côté utilisateur ressemble à un dashboard cassé, alors que le backend est parfaitement vivant.
Il faut vérifier :
- l’URL de base configurée dans l’application ;
- les chemins d’API demandés par le frontend ;
- les redirections du proxy inverse ;
- les erreurs de type CORS, 404, 401 ou 403 dans le navigateur ;
- les différences entre accès direct et accès via le proxy.
Le code HTTP est déjà un indice. Une erreur 401 oriente vers la session ou l’authentification. Une 403 suggère plutôt une permission. Une 404 peut révéler une mauvaise base d’URL. Une réponse 200 avec un contenu vide déplace l’attention vers les filtres, les données ou le frontend.
4. Tester l’API indépendamment du frontend
Le frontend ajoute une couche de complexité inutile pour le diagnostic. Je teste donc les endpoints directement, avec la même session si nécessaire.
L’objectif est de déterminer si l’API renvoie :
- les données attendues ;
- une liste vide mais valide ;
- une erreur d’authentification ;
- une erreur de permission ;
- une réponse lente ou interrompue ;
- un schéma différent de celui attendu par l’interface.
Cette étape permet de séparer deux classes de problèmes souvent confondues : « aucune donnée n’existe » et « l’interface ne sait pas afficher la donnée reçue ».
Un dashboard qui ne montre rien n’est donc pas une preuve d’absence. C’est une preuve qu’il faut regarder la réponse qui se trouve derrière.
5. Vérifier les agents sans les relancer
Quand des métriques manquent, la tentation est de redémarrer tous les agents. Avant cela, je vérifie leur dernier contact, leur état et les erreurs de collecte.
Quelques questions utiles :
- les agents envoient-ils encore des données ?
- leur horodatage évolue-t-il ?
- le problème concerne-t-il tous les agents ou un sous-ensemble ?
- la collecte échoue-t-elle côté agent, côté réseau ou côté serveur ?
- les données sont-elles présentes mais filtrées dans l’interface ?
Cette distinction est importante. Un agent silencieux n’a pas le même diagnostic qu’un agent actif dont les métriques sont masquées. Dans le premier cas, il faut chercher un problème de connectivité, de configuration ou de runtime. Dans le second, relancer l’agent est une opération inutile et potentiellement perturbatrice.
6. Confirmer l’état de la base et du stockage
Si l’API répond mais que les séries sont vides, je vérifie ensuite la couche de persistance.
La question n’est pas seulement « la base est-elle démarrée ? », mais aussi :
- contient-elle encore les enregistrements attendus ?
- les écritures récentes arrivent-elles ?
- une migration ou un changement de schéma a-t-il modifié la lecture ?
- l’application consulte-t-elle le bon volume ou la bonne base ?
- les permissions du processus permettent-elles la lecture ?
Là encore, il faut éviter les remèdes irréversibles. Ne pas supprimer un volume, recréer une base ou réinitialiser un utilisateur avant d’avoir démontré que les données sont absentes et restaurables.
Dans un incident de monitoring, la préservation des preuves vaut souvent plus qu’une restauration précipitée.
7. Examiner la session et le compte courant
Une session périmée peut produire un écran trompeur. Le navigateur conserve parfois une interface partiellement chargée, tandis que les requêtes suivantes sont refusées ou exécutées avec un utilisateur différent de celui imaginé.
Je vérifie donc :
- l’identité effectivement associée à la session ;
- l’expiration des cookies ou jetons ;
- la présence d’une redirection vers la connexion ;
- le comportement en navigation privée ;
- la différence entre deux comptes disposant de rôles distincts.
Ce test est particulièrement utile quand un autre utilisateur voit les données ou quand l’API fonctionne avec une authentification explicite mais pas depuis le navigateur.
Un problème de session n’appelle pas nécessairement une modification de la configuration du service. Il peut se résoudre par une reconnexion contrôlée, après avoir confirmé que les données et les permissions sont intactes.
8. Contrôler les règles de visibilité
Les systèmes modernes séparent souvent l’existence d’une donnée et le droit de l’afficher. Les filtres peuvent venir du rôle utilisateur, d’un périmètre d’équipe, d’un dossier, d’un tag, d’un tenant ou d’une règle d’accès héritée.
Je compare, si c’est possible, une même requête avec deux profils autorisés à des périmètres différents. Cette comparaison est plus informative qu’une modification immédiate des permissions.
Il faut aussi rechercher les filtres silencieux : période sélectionnée, environnement, hôte, statut, étiquette ou dossier. Un filtre conservé dans l’URL ou dans le stockage local peut donner l’impression que toutes les données ont disparu.
9. Lire le frontend comme un système distribué
Le navigateur n’est pas une simple fenêtre sur le serveur. C’est un composant qui possède son cache, sa session, ses appels réseau, ses erreurs d’exécution et sa logique de rendu.
Les outils de développement donnent des indices concrets :
- console : exceptions JavaScript et erreurs de parsing ;
- réseau : endpoints appelés, codes HTTP, temps de réponse et réponses ;
- stockage : cookies, local storage et préférences persistées ;
- ressources : fichiers JavaScript ou CSS manquants ;
- comparaison : navigation privée, autre navigateur ou autre compte.
Une erreur frontend peut apparaître après un changement de version alors que l’API n’a pas changé. À l’inverse, une API modifiée peut laisser l’interface se charger avant d’échouer au moment du rendu.
Le symptôme « page blanche » doit donc être traité comme un incident distribué, pas comme une preuve contre le service de données.
Une séquence de diagnostic réutilisable
Voici la séquence que je retiens pour ce type d’incident :
- Capturer le symptôme exact et ce qui fonctionne encore.
- Vérifier le processus, le port et une réponse locale.
- Vérifier l’URL publique, le proxy et les redirections.
- Tester l’API directement.
- Vérifier l’activité des agents sans les relancer.
- Confirmer la présence et l’accessibilité des données persistées.
- Contrôler la session et l’identité effective.
- Comparer les permissions et les filtres de visibilité.
- Lire les erreurs frontend et le trafic réseau.
- Corriger uniquement la couche dont la cause est démontrée.
- Rejouer les vérifications initiales et documenter le résultat.
Cette séquence n’est pas un dogme. Elle a une propriété utile : elle progresse du plus observable au plus contextuel, tout en limitant les changements qui pourraient brouiller l’enquête.
La correction minimale est souvent la meilleure
Une fois la cause identifiée, la correction doit rester proportionnée. Cela peut être une URL corrigée, une reconnexion, une permission ajustée, un filtre supprimé ou une incompatibilité frontend résolue.
Il n’est pas nécessaire de reconstruire le service, de réinitialiser la base ou de réinstaller les agents si la chaîne de données est intacte.
La qualité d’une intervention opérationnelle ne se mesure pas au nombre de commandes exécutées. Elle se mesure à la précision du diagnostic, à la conservation des données et à la capacité de revenir à un état vérifiable.
Ce que je retiens
Un monitoring qui semble cassé peut être un problème d’observabilité de l’observabilité. Le dashboard ne montre qu’une représentation finale d’une chaîne composée de services, d’URL, d’API, d’agents, de stockage, de sessions, de permissions et de code frontend.
La méthode fiable consiste à décomposer cette chaîne, vérifier chaque couche en lecture seule, conserver les preuves et ne modifier que ce qui est nécessaire.
Ce réflexe est transférable bien au-delà du monitoring. Il s’applique à presque toute interface auto-hébergée qui transforme un symptôme visuel en diagnostic technique.
Si un écran vide vous donne envie de tout redémarrer, commencez par une question plus utile : quelle couche ai-je réellement prouvée défaillante ?
Cet article est volontairement anonymisé. Les noms de services, hôtes, adresses, comptes et détails d’infrastructure ont été retirés ou généralisés.
