Bonjour
Pour plus de clarté nous allons dissocier ton fil de discussion du mien! Je t'invite donc à poursuivre par ici.
Pour ton info, je ne suis pas expert Docker simplement un ‘utilisateur enthousiaste’ je me considère aussi ‘newbie’ j’en apprends tous les jours… il ya tellement de choses à assimiler! Je prend simplement le temps de comprendre le ‘Pourquoi et le Comment’ Pourquoi cela fonctionne chez moi et pas chez toi? Nous avons pourtant les mêmes machines… mais nos montages sont différents! Je n'écris pas c'est bien ou c'est pas bien!
Tu verras je suis pointilleux, soucieux du détail, du grain de sable qui peut bloquer la machine! Je veux bien aider mais faut que ‘l’autre’ que je respecte fasse des efforts de compréhension et d’un minimum d'investissement pour administrer sa bécane… et je sens que c'est le cas!
Cela me coûte en temps mais je prends du plaisir à aider comme cela à pu coûter aux autres qui m'ont aidé depuis le printemps dernier!
Yes je suis un newbie!
Hihihi mais je ne veux pas seulement apprendre mais comprendre ce que je fais.
La est la nuance! Bon nous allons tenter de régler ton problème?
Analyse du journal de l'agent Scrutiny
-ligne35 : ici InfluxDB écoute sur le port 8086
-ligne38 à 41 : Scrutiny démarre aussi, on voit le logo ASCII
-ligne44 à 50 : les migrations SQLite réussies sont confirmées aux lignes 45,48, et 50
-ligne37 : Scrutiny démarre sans fichier de configuration (scrutiny.yaml)? Mais où est ton fichier?
… Ensuite ça coince en ligne :
-ligne52 : Erreur critique : bucket metrics introuvable!!!
-ligne53 : conséquence directe l’agent Scrutiny renvoie une erreur Retour HTTP 500 sur /api/summaty
Explication : l’erreur critique formée par les deux lignes clés de ton journal: c'est écrit en clair en ligne 52, l’agent Scrutiny tente de récupérer le résumé des périphériques, mais échoue car le bucket metrics est introuvable dans InfluxDB. En ligne 53, le serveur renvoie une erreur HTTP 500 à ton navigateur sur l’API /api/summary, conséquence directe du problème de bucket manquant.
Donc Scrutiny fonctionne bien, InfluxDB est joignable, mais l’absence du bucket metrics bloque l’affichage des données SMART.
Tu dois corriger 2 points essentiels dans ton installation Docker :
1/Fournir un fichier de config. scrutiny.yaml
Actuellement, Scrutiny démarre sans fichier de config. (ligne 37 du journal). Ce fichier est indispensable pour indiquer à Scrutiny :L’URL d’InfluxDB (http://influxdb:8086 par exemple), le token d’accès généré dans InfluxDB, l’organisation InfluxDB, le bucket metrics où stocker les données SMART.
2/mettre en place le 'collector'
Le collector est le composant qui lit les données SMART des disques et les envoie vers InfluxDB. C’est lui qui crée le bucket metrics si besoin.
Conclusion/Chez toi, le problème est que l'agent Scrutiny démarre sans fichier scrutiny.yaml!!! Le bucket metrics n’est pas créé car le collector n’a pas tourné.
Ce que tu dois modifier :Ajoute et monte un nouveau fichier scrutiny.yaml dans son conteneur Docker, puis lance le collector Scrutiny pour créer et alimenter le bucket metrics
Quesaquo?
Scrutiny sous Docker est un outil open‑source qui sert de tableau de bord pour surveiller la santé des disques durs via les données S.M.A.R.T.
Tu trouveras les fils de discussion autour de Scrutiny sur les forums NAS, chez Docker Hub et auprès de la communautés LinuxServer.io..
Des passionnés de Linux, de serveurs personnels et de conteneurs Docker ont un compte GitHub officiel où le code source, les Dockerfiles et la documentation sont disponibles par ici: LinuxServer.io · GitHub
-?bucket metrics est un espace de stockage dans InfluxDB où Scrutiny enregistre les données SMART (température, erreurs, cycles d’écriture/lecture, etc.) de tes disques. Sans ce bucket, Scrutiny n’a aucun endroit où lire les mesures, donc l’interface web ne peut rien afficher
InfluxData Documentation cest ici:
https://docs.influxdata.com/
https://docs.influxdata.com/influxdb/v2/admin/buckets/*
-?collector : un petit service qui s’exécute sur la machine où se trouvent les disques. Il interroge régulièrement les disques via smartctl (outil S.M.A.R.T). Il collecte les données (température, erreurs, cycles, etc.) et les envoie à l’API Scrutiny.Web UI / API : l’interface graphique qui reçoit les données du collector et les affiche dans un tableau de bord. Le collector est donc indispensable pour surveiller les disques.
Tu pourras ici poursuivre ton lexique… tout mémoriser c'est pas possible!
Autre point!!!
Nous avons le même NAS à savoir le DXP2800 avec des montages différents:
1/Mon montage
-RAID1 logiciel avec 2xNVMe (VOL1) c'est ici que sont installées mes apps, mon docker, j'ai une redondance… si un SSD tombe en panne, l’autre continue à fonctionner. Lors de la dernière MAJ j’ai justement eu une ‘panne’ sur NVMe1 puis le RAID s'est reconstruit Ouf !!!Heureusement que j’ai écouté les conseils des anciens du forum.
-2HDDs en Basic (VOL2&VOL3) indépendants ‘chacun vit sa vie’, chacun est utilisé séparément, pas de redondance, j’ai plus de flexibilité pour le stockage
Je combine donc performance (via les SSD en RAID1) + capacité (les 2HDDs en Basic).
2/Ton montage
-1 HDD en Basic (VOL1), stockage classique, sans redondance
-1 SSD en Basic (VOL2), Docker est installé dessus, donc tu bénéficie de la rapidité du SSD sans plus! Pas de RAID! chaque disque est indépendant, donc s’il y a une panne, il n’y a pas de copie automatique, Conséquence: Faut recommencer depuis le début! En as-tu conscience?
Comparaison:
Chez moi/plus sécurisé pour la partie système/SSD grâce au RAID1
Chez toi/plus simple, mais moins tolérant aux pannes. Si ton SSD (Volume2) lâche, Docker et ses conteneurs sont perdus. Si tu perds ton HDD, les données sans sauvegarde automatique. Tout est perdu!
Performance : OUI, tu profites quand même de la vitesse du SSD pour Docker, donc ça reste fluide.
Ce n’est pas “grave” de rouler avec 1SEUL NVMe mais c’est plus risqué. Sans RAID, tu dois absolument prévoir des sauvegardes régulières pour éviter de tout perdre.
Pour finir: Mon montage est bon grâce au RAID1 sur les NVMe, le tien est fonctionnel mais vulnérable : pas de RAID donc pas de tolérance aux pannes!
La question de la sécurité des données est PRIORITAIRE pour moi!!!
Techniquement ton montage est risqué si 1 disque tombe en panne? C'est arrivé à 2 newbies... il n'y a pas si longtemps!!! La solution est de mettre en place des sauvegardes régulières ou envisager... dès que possible te conseilles vivement un RAID1 sur les 2NVMe! Tu l'as peut être prévu?
Bye
Pour ton info, je ne suis pas expert Docker simplement un ‘utilisateur enthousiaste’ je me considère aussi ‘newbie’ j’en apprends tous les jours… il ya tellement de choses à assimiler! Je prend simplement le temps de comprendre le ‘Pourquoi et le Comment’ Pourquoi cela fonctionne chez moi et pas chez toi? Nous avons pourtant les mêmes machines… mais nos montages sont différents! Je n'écris pas c'est bien ou c'est pas bien!
Tu verras je suis pointilleux, soucieux du détail, du grain de sable qui peut bloquer la machine! Je veux bien aider mais faut que ‘l’autre’ que je respecte fasse des efforts de compréhension et d’un minimum d'investissement pour administrer sa bécane… et je sens que c'est le cas!
Cela me coûte en temps mais je prends du plaisir à aider comme cela à pu coûter aux autres qui m'ont aidé depuis le printemps dernier!
Yes je suis un newbie!
Analyse du journal de l'agent Scrutiny
-ligne35 : ici InfluxDB écoute sur le port 8086
-ligne38 à 41 : Scrutiny démarre aussi, on voit le logo ASCII
-ligne44 à 50 : les migrations SQLite réussies sont confirmées aux lignes 45,48, et 50
-ligne37 : Scrutiny démarre sans fichier de configuration (scrutiny.yaml)? Mais où est ton fichier?
… Ensuite ça coince en ligne :
-ligne52 : Erreur critique : bucket metrics introuvable!!!
-ligne53 : conséquence directe l’agent Scrutiny renvoie une erreur Retour HTTP 500 sur /api/summaty
Explication : l’erreur critique formée par les deux lignes clés de ton journal: c'est écrit en clair en ligne 52, l’agent Scrutiny tente de récupérer le résumé des périphériques, mais échoue car le bucket metrics est introuvable dans InfluxDB. En ligne 53, le serveur renvoie une erreur HTTP 500 à ton navigateur sur l’API /api/summary, conséquence directe du problème de bucket manquant.
Donc Scrutiny fonctionne bien, InfluxDB est joignable, mais l’absence du bucket metrics bloque l’affichage des données SMART.
Tu dois corriger 2 points essentiels dans ton installation Docker :
1/Fournir un fichier de config. scrutiny.yaml
Actuellement, Scrutiny démarre sans fichier de config. (ligne 37 du journal). Ce fichier est indispensable pour indiquer à Scrutiny :L’URL d’InfluxDB (http://influxdb:8086 par exemple), le token d’accès généré dans InfluxDB, l’organisation InfluxDB, le bucket metrics où stocker les données SMART.
2/mettre en place le 'collector'
Le collector est le composant qui lit les données SMART des disques et les envoie vers InfluxDB. C’est lui qui crée le bucket metrics si besoin.
Conclusion/Chez toi, le problème est que l'agent Scrutiny démarre sans fichier scrutiny.yaml!!! Le bucket metrics n’est pas créé car le collector n’a pas tourné.
Ce que tu dois modifier :Ajoute et monte un nouveau fichier scrutiny.yaml dans son conteneur Docker, puis lance le collector Scrutiny pour créer et alimenter le bucket metrics
Quesaquo?
Scrutiny sous Docker est un outil open‑source qui sert de tableau de bord pour surveiller la santé des disques durs via les données S.M.A.R.T.
Tu trouveras les fils de discussion autour de Scrutiny sur les forums NAS, chez Docker Hub et auprès de la communautés LinuxServer.io..
Des passionnés de Linux, de serveurs personnels et de conteneurs Docker ont un compte GitHub officiel où le code source, les Dockerfiles et la documentation sont disponibles par ici: LinuxServer.io · GitHub
-?bucket metrics est un espace de stockage dans InfluxDB où Scrutiny enregistre les données SMART (température, erreurs, cycles d’écriture/lecture, etc.) de tes disques. Sans ce bucket, Scrutiny n’a aucun endroit où lire les mesures, donc l’interface web ne peut rien afficher
InfluxData Documentation cest ici:
https://docs.influxdata.com/
https://docs.influxdata.com/influxdb/v2/admin/buckets/*
-?collector : un petit service qui s’exécute sur la machine où se trouvent les disques. Il interroge régulièrement les disques via smartctl (outil S.M.A.R.T). Il collecte les données (température, erreurs, cycles, etc.) et les envoie à l’API Scrutiny.Web UI / API : l’interface graphique qui reçoit les données du collector et les affiche dans un tableau de bord. Le collector est donc indispensable pour surveiller les disques.
Tu pourras ici poursuivre ton lexique… tout mémoriser c'est pas possible!
Autre point!!!
Nous avons le même NAS à savoir le DXP2800 avec des montages différents:
1/Mon montage
-RAID1 logiciel avec 2xNVMe (VOL1) c'est ici que sont installées mes apps, mon docker, j'ai une redondance… si un SSD tombe en panne, l’autre continue à fonctionner. Lors de la dernière MAJ j’ai justement eu une ‘panne’ sur NVMe1 puis le RAID s'est reconstruit Ouf !!!Heureusement que j’ai écouté les conseils des anciens du forum.
-2HDDs en Basic (VOL2&VOL3) indépendants ‘chacun vit sa vie’, chacun est utilisé séparément, pas de redondance, j’ai plus de flexibilité pour le stockage
Je combine donc performance (via les SSD en RAID1) + capacité (les 2HDDs en Basic).
2/Ton montage
-1 HDD en Basic (VOL1), stockage classique, sans redondance
-1 SSD en Basic (VOL2), Docker est installé dessus, donc tu bénéficie de la rapidité du SSD sans plus! Pas de RAID! chaque disque est indépendant, donc s’il y a une panne, il n’y a pas de copie automatique, Conséquence: Faut recommencer depuis le début! En as-tu conscience?
Comparaison:
Chez moi/plus sécurisé pour la partie système/SSD grâce au RAID1
Chez toi/plus simple, mais moins tolérant aux pannes. Si ton SSD (Volume2) lâche, Docker et ses conteneurs sont perdus. Si tu perds ton HDD, les données sans sauvegarde automatique. Tout est perdu!
Performance : OUI, tu profites quand même de la vitesse du SSD pour Docker, donc ça reste fluide.
Ce n’est pas “grave” de rouler avec 1SEUL NVMe mais c’est plus risqué. Sans RAID, tu dois absolument prévoir des sauvegardes régulières pour éviter de tout perdre.
Pour finir: Mon montage est bon grâce au RAID1 sur les NVMe, le tien est fonctionnel mais vulnérable : pas de RAID donc pas de tolérance aux pannes!
La question de la sécurité des données est PRIORITAIRE pour moi!!!
Techniquement ton montage est risqué si 1 disque tombe en panne? C'est arrivé à 2 newbies... il n'y a pas si longtemps!!! La solution est de mettre en place des sauvegardes régulières ou envisager... dès que possible te conseilles vivement un RAID1 sur les 2NVMe! Tu l'as peut être prévu?
Bye
Dernière édition:




