MilesTEG1 Posté(e) le 7 octobre 2021 Posté(e) le 7 octobre 2021 (modifié) Petit récap pour changer la politique de rétention des données dans InfluxDB : Se connecter au NAS en SSH, puis en root, lancer : docker exec -it influxdb influx -username admin -password admin Ensuite, les commandes : SHOW DATABASES : Pour afficher la liste des bases de données CREATE RETENTION POLICY "Retention" ON "NOM_BDD" DURATION 90d REPLICATION 1 DEFAULT : Pour créer la politique de rétention, il faut lancer la commande autant de fois qu'on a de base de données. Pour supprimer les anciennes entrées : USE "NOM_BDD" : pour sélectionner la base de données (ça peut mouliner un moment XD) DELETE WHERE time < '2021-09-01' : pour supprimer les données datant d'avant le 1er Sept. 2021 de la base de donnée NOM_BDD. Par contre, pour les paramètres REPLICATION et SHARD DURATION je n'ai pas trop compris... j'ai mis 1 pour le premier et je n'ai pas mis l'autre... Dernière chose, ça n'a pas modifié la taille sur le disque de mes bases de données... Comment faire pour réduire cette taille ? Ça va se faire tout seul ? Modifié le 7 octobre 2021 par MilesTEG1 Ajout des commandes de suppression des anciennes données 0 Citer
.Shad. Posté(e) le 7 octobre 2021 Auteur Posté(e) le 7 octobre 2021 (modifié) Regarde dans le lien, c'est marqué 1.8 Ça ne va rien réduire du tout, il te faut supprimer ces données manuellement. Tu peux drop les series (voir l'aide de Grafana). En revanche les prochaines données se supprimeront au bout de la police de rétention spécifiée. Modifié le 7 octobre 2021 par .Shad. 1 Citer
MilesTEG1 Posté(e) le 7 octobre 2021 Posté(e) le 7 octobre 2021 à l’instant, .Shad. a dit : Regarde dans le lien, c'est marqué 1.8 J'ai vu après coup en effet 😉 J'ai posté en même temps que toi une réponse, qui a été mise juste avant la tienne 😉 0 Citer
.Shad. Posté(e) le 7 octobre 2021 Auteur Posté(e) le 7 octobre 2021 Et j'ai édité la mienne. 😄 1 Citer
MilesTEG1 Posté(e) le 7 octobre 2021 Posté(e) le 7 octobre 2021 il y a 7 minutes, .Shad. a dit : Ça ne va rien réduire du tout, il te faut supprimer ces données manuellement. Tu peux drop les series (voir l'aide de Grafana). C'est dans grafana que je peux le faire ? Faut que je vois ça... Ils ne sont pas intuitifs ces outils... Bon j'ai trouvé comment faire, mais via InfluxDB directement, car pas trouvé comment faire avec Grafana... j'ai éditer mon message plus haut avec les commandes. 0 Citer
MilesTEG1 Posté(e) le 7 octobre 2021 Posté(e) le 7 octobre 2021 Ça fait 10 min que ça mouline, et il me reste encore 7,8 Go de données sur les 12,6 Go 😛 Ce n'est pas rapide ^^ 0 Citer
olme17 Posté(e) le 13 octobre 2021 Posté(e) le 13 octobre 2021 @.Shad. Bonjour Super le tuto. J'ai suivi le mod op, tout fonctionne sauf que je n'ai aucune donnée dans Grafana. Dans les logs telegraf j'ai ça 2021-10-13T17:18:00Z W! [inputs.snmp] Collection took longer than expected; not complete after interval of 1m0s stderr 17:18:08 2021-10-13T17:18:08Z D! [outputs.influxdb] Wrote batch of 38 metrics in 98.660831ms stderr 17:18:08 2021-10-13T17:18:08Z D! [outputs.influxdb] Buffer fullness: 0 / 10000 metrics stderr 17:18:17 2021-10-13T17:18:17Z D! [outputs.influxdb] Buffer fullness: 0 / 10000 metrics stderr 17:18:21 2021-10-13T17:18:21Z E! [inputs.snmp] Error in plugin: agent 172.18.0.1: performing get on field sysName: request timeout (after 3 retries) stderr Une idée pour résoudre le problème PS : Je n'ai pas trouvé dans le tuto de problèmes similaires Cdt 0 Citer
.Shad. Posté(e) le 13 octobre 2021 Auteur Posté(e) le 13 octobre 2021 Est-ce que le nom de la communauté SNMP correspond à ce que tu as renseigné dans DSM ? Est-ce que ton pare-feu autorise les connexions entrantes pour les IP 172.16.0.0/255.240.0.0 ? 0 Citer
olme17 Posté(e) le 13 octobre 2021 Posté(e) le 13 octobre 2021 @.Shad. En effet j'avais changé la communauté, maintenant je reçois des données. J'aurai du rester simple. Par contre je ne comprends l'autorisation d'une plage d'adresse aussi importante. En tout cas merci 0 Citer
.Shad. Posté(e) le 13 octobre 2021 Auteur Posté(e) le 13 octobre 2021 Cette plage correspond aux IP utilisées par Docker. Tu peux très bien restreindre à ta sauce, mais ça multipliera les règles. Tout dépend en fait d'où tu places le curseur de confiance et de sécurité. 0 Citer
Jeff777 Posté(e) le 16 octobre 2021 Posté(e) le 16 octobre 2021 (modifié) Bonjour à tous 🙂 Ce matin j'ai la surprise de voir une case rouge dans le monitoring de mon DS218+ c'est la première fois que cela m'arrive et je ne sais pas interpréter cette mise en garde. J'ai un fichier excel qui résume toutes les tâches régulières de mes nas. Le samedi à 0h il y a une sauvegarde par hyperbackup de ce nas mais celle-ci c'est déroulée normalement. Je ne trouve rien d'anormal sur le NAS excepté dans le journal: et dans le gestionnaire de stockage j'ai la réponse: Donc un nettoyage des données du groupe de stockage est planifié tous les 6 mois il est en cours et se déroule normalement. Je ne me souviens pas d'avoir planifier cette tâche, peut-être l'est-elle par défaut. Edit : cette fonction semble être une spécificité de DSM7 Ma question : est-ce que l'un de vous sait interpréter les codes envoyés par le monitoring du raid ? Edit : Dans la programmation du nettoyage j'ai restreins la période d'activation de de 0 à 6h ce qui a eu pour effet de reporter sa progression. Le statut raid est repassé vert. Modifié le 16 octobre 2021 par Jeff777 Compléments d'info 0 Citer
MilesTEG1 Posté(e) le 16 octobre 2021 Posté(e) le 16 octobre 2021 Le code 13 est étrange... Moi j'ai ces valeurs en mappage : Mais pas de 13 dedans... 0 Citer
Jeff777 Posté(e) le 16 octobre 2021 Posté(e) le 16 octobre 2021 Tu n'es pas en DSM7 ? Comment fais-tu pour trouver ces valeurs ? 0 Citer
MilesTEG1 Posté(e) le 16 octobre 2021 Posté(e) le 16 octobre 2021 il y a 4 minutes, Jeff777 a dit : Tu n'es pas en DSM7 ? Comment fais-tu pour trouver ces valeurs ? Si je suis ne DSM7. Et pour les valeurs, je ne me rappelle plus exactement, mais j'ai du les prendre dans un PDF de synology sur les MIB... 0 Citer
Jeff777 Posté(e) le 16 octobre 2021 Posté(e) le 16 octobre 2021 Merci je vais regarder cela quand j'aurai un moment, ça a certainement changé avec DSM7. 0 Citer
.Shad. Posté(e) le 16 octobre 2021 Auteur Posté(e) le 16 octobre 2021 13 c'est DataScrubbing, c'est effectivement la vérification des données. 1 Citer
Jeff777 Posté(e) le 16 octobre 2021 Posté(e) le 16 octobre 2021 (modifié) Oui j'ai trouvé ça : https://global.download.synology.com/download/Document/Software/DeveloperGuide/Firmware/DSM/All/enu/Synology_DiskStation_MIB_Guide.pdf Modifié le 16 octobre 2021 par Jeff777 0 Citer
Sky007FR Posté(e) le 29 octobre 2021 Posté(e) le 29 octobre 2021 Bonjour, Une info pour ceux qui pourraient avoir le même souci. Watchtower m'a automatiquement mis à jour telegraf depuis la 1.20.2 en 1.20.3 à 4h du matin. Depuis le récupération des infos docker ne fonctionnait plus : message d'erreur dans le journal "permission denied" sur "/var/run/docker.sock". N'ayant pas trouvé de solution, je suis repassé en 1.20.2, j'ai désactivé watchtower et c'est reparti : Dans les releases notes de telegraf 1.20.3, il y a une mention concernant docker : https://docs.influxdata.com/telegraf/v1.20/about_the_project/release-notes-changelog/ Citation Update github.com/docker/docker module from 20.10.7+incompatible to 20.10.9+incompatible. 0 Citer
oracle7 Posté(e) le 29 octobre 2021 Posté(e) le 29 octobre 2021 @Sky007FR Bonjour, C'est étonnant ton affaire, car le package docker sur les NAS (DSM6 et DSM7) est en version 20.10.3-0554 ou 20.10.3-1239 selon, donc assez en retard sur le docker "standard" actuel 20.10.10 du 25/10/2021. As-tu vérifier les droits sur "/var/run/docker.sock" ? moi j'ai "rw- rw- ---" propriétaire root. Je vais surveiller la prochaine mise à jour de telegraf en 1.20.3 et verrais si cela plante ou pas. Merci quand même de ton retour. Cordialement oracle7😉 0 Citer
Sky007FR Posté(e) le 29 octobre 2021 Posté(e) le 29 octobre 2021 Voici les droits sur mon NAS : 0 Citer
MilesTEG1 Posté(e) le 31 octobre 2021 Posté(e) le 31 octobre 2021 Salut, Je constate une chose similaire... mais que pour les stats Docker. Je ne suis pas allé sur Grafana depuis quelques temps, mais en lisant vos messages je suis allé vérifier... Et j'ai ceci : (ne pas tenir compte du No Data sur le 214play, il est éteint, donc aucune donnée, c'est normal). Mais pour Docker Memory, ou pour les autres infos comme la liste des conteneurs : Je n'ai plus rien... edit : Cela dit j'ai aussi ces lignes dans les logs de Telegraf : 2021-10-31T07:36:20Z E! [inputs.docker] Error in plugin: Got permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock: Get "http://%2Fvar%2Frun%2Fdocker.sock/v1.21/info": dial unix /var/run/docker.sock: connect: permission denied, 2021-10-31T07:36:20Z E! [inputs.docker] Error in plugin: Got permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock: Get "http://%2Fvar%2Frun%2Fdocker.sock/v1.21/containers/json?filters=%7B%22status%22%3A%5B%22running%22%5D%7D&limit=0": dial unix /var/run/docker.sock: connect: permission denied Ma version de Docker est : Docker version 20.10.3, build b455053 0 Citer
oracle7 Posté(e) le 31 octobre 2021 Posté(e) le 31 octobre 2021 (modifié) @MilesTEG1 Bonjour, Bon bah force est de constater que je rejoins le club, je n'ai moi aussi plus aucun affichage des informations pour le suivi de docker, mais tout aussi grave cela aussi impact le suivi de la LiveBox qui est entièrement vide. Effectivement cela est apparu avec le mise à jour du 30/10/2021 de telegraf en v1.20.3. Sous Linux (et ici), il semblerait qu'il faille ajouter l'utilisateur courant au group "docker" qui aurait les droits d'écriture sur le fichier " /var/run/docker.sock ". Mais comment faire cela sur Synology ? That's the question ! Sinon : J'ai arrêté le conteneur telegraf du monitoring, J'ai modifié les droits du fichier " /var/run/docker.sock " avec un : chmod 0666 /var/run/docker.sock J'ai redémarré le conteneur telegraf du monitoring, BINGO 🤗 j'ai retrouvé la surveillance de docker mais jusque quand ? Car à la prochaine MàJ système Synology cette modification ne devrait pas survivre. Je suis bien conscient aussi que c'est pas terrible au niveau sécurité. J'attends avec impatience l'avis de notre expert préféré sur ce point @.Shad.. EDIT : Sur la community.synology j'ai trouvé cela : Add user to docker group: # synogroup --add docker <your_username> Change ownership of docker socket to the docker group: # chown root:docker /var/run/docker.sock Mais j'hésite à faire sachant que pour <your_username> je serais tenté de mettre a priori mon user avec droits d'admin. Votre avis ? Cordialement oracle7😉 Modifié le 31 octobre 2021 par oracle7 0 Citer
MilesTEG1 Posté(e) le 31 octobre 2021 Posté(e) le 31 octobre 2021 Hmmm, perso je toucherais pas les users, et encore moins les permissions sur le docker.socks... Ça me semble trop risqué... 0 Citer
.Shad. Posté(e) le 31 octobre 2021 Auteur Posté(e) le 31 octobre 2021 Je rentre de congé mardi je ne pourrai pas y regarder avant. 1 Citer
Messages recommandés
Rejoindre la conversation
Vous pouvez publier maintenant et vous inscrire plus tard. Si vous avez un compte, connectez-vous maintenant pour publier avec votre compte.