bruno78

Bonjour , j'utilise un petit script (github) pour alimenter influxdb sans passer par telegraf quand nécessaire ou plus facile. Je vous en ferais part dès le retour de congés 🙂 début janvier 2021. Joyeuses fêtes à tous Bruno78

Le paramètre 6MOIS dans la requête correspond à la retention policy sur influxdb (que j'ai personnalisée ) .Ainsi je garde les données 6 mois maximum. De mémoire la default policy de base est illimitée ' ce qui est un peu excessif. Il faudra, début janvier , que je regarde les travaux d'oracle7 sur le sujet

Pas de soucis. Je vois que tu as obtenu les résultats escomptés avec .Shad.. Donc au final tout va bien. Bruno78 Envoyé de mon STF-L09 en utilisant Tapatalk

Bonsoir, https://www.synology.com/fr-fr/support/download/DS918+#utilities

Je rajouterai ceci : de même que des nouveaux disques se préparent avant d'être mis en service Pour la RAM, une fois mise en place, il faut la tester avec l'utilitaire Synology Assistant. Bruno78

Bonjour @Baron_noir, la RAM ou le cache MVNE .... les rôles sont complètement différents. Pour faire du docker, c'est bien de la RAM qu'il te faut. Perso j'ai sacrifié la barrette de 4Go d'origine, pour y mettre 2*8Go et être tranquille. Cela permet également d'avoir un seul type de barrettes et donc d'éviter des incompatibilités entre elles. j'y ai mis des barrettes Crucial CT2K8G3S186DM : Memory Device Array Handle: 0x0023 Error Information Handle: No Error Total Width: 8 bits Data Width: 8 bits Size: 8192 MB Form Factor: SODIMM Set: None Locator: ChannelA-DIMM0 Bank Locator: BANK 0 Type: DDR3 Type Detail: Synchronous Speed: 1866 MT/s Manufacturer: 0515 Serial Number: Asset Tag: Part Number: CT2K8G3S186DM Rank: Unknown Configured Memory Speed: 1866 MT/s Minimum Voltage: Unknown Maximum Voltage: Unknown Configured Voltage: Unknown Handle 0x0025, DMI type 17, 40 bytes Memory Device Array Handle: 0x0023 Error Information Handle: No Error Total Width: 8 bits Data Width: 8 bits Size: 8192 MB Form Factor: SODIMM Set: None Locator: ChannelB-DIMM0 Bank Locator: BANK 1 Type: DDR3 Type Detail: Synchronous Speed: 1866 MT/s Manufacturer: 0515 Serial Number: Asset Tag: Part Number: CT2K8G3S186DM Rank: Unknown Configured Memory Speed: 1866 MT/s Minimum Voltage: Unknown Maximum Voltage: Unknown Configured Voltage: Unknown Jamais eu aucun problème, parfaitement reconnues par ls DS918 Bruno78

Bonjour @wiwi95 pour le sysup time : Pour la memoire, j'ai ceci mais là il peut y avoir confusion entre tous les différents types de memoire (libre, used, cache, ...) Bruno78 Joyeuses Fêtes à tous

Bonjour @Einsteinium, si on suit la doc, oui il faut les doubles quotes ("). Maitenant, je m'y suis peut-être mal pris, mais avec ou sans le double quote, je n'arrive pas à faire l'export des variables dans le container via docker exec -it .... Bruno78 Bonnes Fêtes à toutes et à tous ... et restez prudents.

Bonjour @Philippe D, ce n'est pas un problème de pare-feu. Peux-tu donner la liste et les caractéristiques des réseaux configurés, ainsi que les caractéristiques de celui que tu es en train de créer ? Bruno78

Bonjour @Jeff777, tu as fais l’opération sur une DSM6 ou une DSM7 ? et as-tu remplacer un certificat existant ? ou ajouter un nouveau certificat (même si avec le même nom) ? Par ailleurs, lorsque j'ai fait l'importation du certificat, c'était avec les fichiers suivants issus directement du docker acme : eut'il fallu les transformer en .pem ???? je relis le post d'origine du tuto, .... et là je me dis que j'ai raté une marche ???? juste pas fait la transformation en .pem ???? j'ai un gros gros doute ....

@MilesTEG1 @oracle7, dsl j'ai suivi de (très) loin, mais ces 2 dernières lignes en erreur, elles continuent ? ou c'est fini ? parce que si telegraf n'arrive pas à se connecter, à un moment donné il va manquer des données ! Là c'est "nas_telegraf" qui n'arrive pas à écrire vers influxdb ....

@Einsteinium merci pour cet update qui simplifiera la vie de certains. De mon côté, j'avais mis en place un lancement via docker-compose pour une machine non DSM, ... ça revient au même. Je reviens au renouvellement automatique de mes domaines. Comme indiqué plus haut, le 3eme domaine a bien été renouvelé en auto cette nuit après avoir fait le ménage dans ma zone DNS (suppression des enregistrements TXT _acme-challenge.ndd.tld). /!\ Par contre là où je me suis planté, c'est sur l'importation de ce certificat dans DSM7. Il s’agissait du domaine par défaut de mon DSM. pour le prendre en compte, dans DSM7, j'ai fait "ajouter > remplacer un certificat existant" et donné les 3 fichiers demandés. Resultat : config Webserver complétement plantée re-installation complète de Webserver et recréation des virtuals hosts (le fichier /etc/nginx/sites-enable/server.webstation-vhost.conf avait disparu !) Peut-être aurai-t’il fallu faire "ajouter un nouveau certificat" et migrer petit à petit les services sur ce nouveau certificat ? En tout cas c'est ce que je ferais pour la prochaine, dans 2 mois. bruno78 PS : c'est d'ailleurs surement plutôt un problème DSM7 à mon avis

@.Shad. merci pour ta réponse, je n'ai pas joué sur le cache, mais sur les tailles et nombre de buffer, .... sans aucun succès. Par ailleurs, ces fichiers temporaires sont immédiatement libérés. Pour le moment j'ai mis la poussière sous le tapis, et changé le niveau d'erreur rapporté dans error.log de façon à ne plus avoir les warning. Mais ce n'est qu'une rustine le temps de trouver une solution perenne.

Rebonjour, je réponds suite à essais complémentaires : c'est bien les records TXT _acme-challenge. XXX de la zone DNS qui bloquaient le processus. Une fois la zone nettoyée, ça roule ! (vieux records qui venaient sans doute d'essais préalables sans que le nettoyage ai été fait). Donc j'ai renouvelé le deuxième domaine en lançant à la main le cron du docker acme. Et pour le troisième j'ai simplement fait le menage dans la zone DNS et je vais laisser passer le cron de façon automatique cette nuit. Et vérifier demain matin si tout est ok.

Bonjour @.Shad., j'ai mis en place ta solution pour l'accès à influxdb, c'est drôlement plus léger et moins contraignant. Donc top ! D'autant que le VPN OpenVPN refuse de se reconnecter lors de la déconnection "normale" après 24h (je ne sais pas pourquoi, il faut que je regarde ce point). Par contre, sur la machine cible (VPS OVH) j'ai le log nginx error.log pollué par les messages suivants : 2020/12/20 09:39:56 [warn] 12743#12743: *23692 a client request body is buffered to a temporary file /var/cache/nginx/client_temp/0000008526, client: 82.64.xxx.yyy, server: influxdb.ndd.tld, request: "POST /write?consistency=any&db=pi_telegraf HTTP/2.0", host: "influxdb.ndd.tld:443" 2020/12/20 09:40:20 [warn] 12743#12743: *23712 a client request body is buffered to a temporary file /var/cache/nginx/client_temp/0000008527, client: 82.64.xxx.yyy, server: influxdb.ndd.tld, request: "POST /write?consistency=any&db=fbx_telegraf_v8 HTTP/2.0", host: "influxdb.ndd.tld:443" Est-ce un problème (à part le log error.log qui deborde !) ? j'ai essayé quelques modifications dans la conf nginx sur les buffers, mais sans succès ... Constates-tu le même phénomène ? Comment fixer les bonnes valeurs de buffers nginx ? merci, bruno78

@Einsteinium bonjour, cette nuit, renouvellement attendu de 3 domaines indépendants via acme.sh en docker, mis en place il y a 2 mois et dont la date de renouvellement était donc cette nuit Sur les 3, 1 OK et 2 KO pour les 2 KO je précise tout de suite : pas de problème de clé chez OVH. après analyse des logs entre le OK et les 2 KO, je constate que pour les 2 KO le log me dit qu'il trouve un subdomain "_acme-challenge.ndd.tld" , ce qui n'est pas le cas pour le domaine pour lequel le renouvellement est OK. [Sun Dec 20 00:44:16 UTC 2020] _sub_domain='_acme-challenge' [Sun Dec 20 00:44:16 UTC 2020] _domain='_acme-challenge.ndd.tld' [Sun Dec 20 00:44:16 UTC 2020] Adding record [Sun Dec 20 00:44:16 UTC 2020] domain/zone/_acme-challenge.ndd.tld/record [Sun Dec 20 00:44:16 UTC 2020] GET [Sun Dec 20 00:44:16 UTC 2020] url='https://eu.api.ovh.com/1.0/auth/time' [Sun Dec 20 00:44:16 UTC 2020] timeout=30 [Sun Dec 20 00:44:16 UTC 2020] _CURL='curl --silent --dump-header /acme.sh/http.header -L -g --connect-timeout 30' [Sun Dec 20 00:44:16 UTC 2020] ret='0' [Sun Dec 20 00:44:16 UTC 2020] _ovh_p='[hidden](please add '--output-insecure' to see this value)' [Sun Dec 20 00:44:16 UTC 2020] data='{"fieldType":"TXT","subDomain":"_acme-challenge","target":"JKfeSWG7F4c5P7tqB7zbwHgktMBL_8za59AZROJ6NEE","ttl":60}' [Sun Dec 20 00:44:16 UTC 2020] POST [Sun Dec 20 00:44:16 UTC 2020] _post_url='https://eu.api.ovh.com/1.0/domain/zone/_acme-challenge.ndd.tld/record' [Sun Dec 20 00:44:16 UTC 2020] _CURL='curl --silent --dump-header /acme.sh/http.header -L -g ' [Sun Dec 20 00:44:16 UTC 2020] _ret='0' [Sun Dec 20 00:44:16 UTC 2020] Add txt record error. [Sun Dec 20 00:44:16 UTC 2020] Error add txt for domain:_acme-challenge.ndd.tld si maintenant je vais voir les zones DNS chez OVH, je m'aperçois que pour le domaine renouvellement OK il n'y a qu'un seul enregistrement TXT "_acme-challenge.ndd.tld", alors que pour les 2 domaines pour lesquels le renouvellement est KO, j'ai 4 enregistrements TXT "_acme-challenge.ndd.tld" avec 4 valeurs de clés différentes. n'y en t'il pas 3 de trop ? Est-ce pour cela qu'il pense détecter un sous-domaine _acme-challenge.ndd.tld ? faut'il les supprimer toutes les 4 ? ou juste 3 mais lesquelles ? Si tu as quelques lumières sur le sujet , merci d'avance Bruno78

Hypothèse : changement de version du paquet Docker dans le DSM7 ???? sinon je ne sais pas pourquoi .....

juste pour illustrer la mise à jour éventuelle de la requete, à vérifier :

ce que je veux dire c'est que sur NAS1, les données manquantes, sont celles qui relèvent de la section [[snmp.inputs]] de ton docker telegraf ?

Je ne me trompes pas : ce sont uniquement les données snmp qui ne passent pas, on est d'accord ? Peux-tu stp refaire le test avec les adresses passerelles, mais après il faut vérifier les requetes dans le dashboard. Si par exemple tu as des conditions du genre "where agent_host=NAS_IP" il faudra mettre également l'adresse de la passerelle au lieu de l'adresse du NAS.

@.Shad. evidemment c'est plus simple. Si je galère avec le VPN, je ferai ainsi. J'ai les telegrafs sur le NAS (nas_telegraf et fbx_telegraf), mais également un télégraf sur le RPi, qui passe par le VPN du NAS, .... moyennant là aussi l'ajout d'une route adequate ! Donc oui, c'est definitivement plus lourd et impactant que ta solution. Pourquoi n'y ai-je pas pensé avant ! (en tout cas l'exercice n'était pas ininteressant). @MilesTEG1 beaucoup de raisons en fait : instances docker pas mises en place au meme moment garder une certaine indépendance entre les instances (ne pas casser le monitoring Fbx sous pretexte de "bricoler" le nas telegraf) et puis et surtout pour la Fbx on a le problème de l'installation du Python, qui n'a pas été un long fleuve tranquile et s'est montré dependant à la version du docker telegraf. Donc séparation des variables 🙂 @Jeff777, pour l'url snmp.output : c'est aussi ce que j'avais en DSM6 (l'adresse locale). Et en passant en DSM7 ca ne marchait plus et j'ai été obligé de mettre l'adresse du reseau docker. Mais je reste en local sur la meme machine. Je n'ai pas d'exemple avec 2 machines.

@Jeff777, ok, alors vérifie ce que tu as du côté de l'agent snmp : ## ## Synology ## [[inputs.snmp]] # List of agents to poll agents = [ "172.20.0.1" ] 172.20.0.1 étant ma passerelle du réseau bridge utlisé par tes dockers de monitoring (data_export pour toi) @.Shad. pour mon info, le principe de la liaison TLS, c'est ce que tu expliques dans ton TUTO sur la centralisation des instance Docker avec Portainer ? Effectivement c'est peut-être plus simple à mettre en oeuvre qu'OpenVPN ...

@Jeff777 , oui j'ai eu des soucis en passant à DSM7 (si tu remontes plus haut, en page 12, il y a un certain nombre d'echanges avec @.Shad.) comment est configuré l'accès à influxdb dans ton telegraf.conf ? docker en mode bridge ou host ? je suis revenu en mode bridge, avec la configuration ci-dessous: ############################################################################### # OUTPUT PLUGINS # ############################################################################### # Configuration for sending metrics to InfluxDB [[outputs.influxdb]] ## The full HTTP or UDP URL for your InfluxDB instance. ## ## Multiple URLs can be specified for a single cluster, only ONE of the ## urls will be written to each interval. # urls = ["unix:///var/run/influxdb.sock"] # urls = ["udp://127.0.0.1:8089"] # urls influxdb NAS local : urls = ["http://influxdb:8086"] @.Shad., oui c'est lourd, je ne sais pas si je vais garder cette conf vers un VPS/OVH. Compte tenu de la consommation mémoire d'influx entre autre, mon RPi 3 est un peu juste, c'est pour cela que j'ai tenté cette solution. Si trop lourd, je passerai sur un RPi4 en local. Et oui, je me suis servi de ton tuto OpenVPS sur VPS, donc normal que tu le reconnaisses ! Le VPN OpenVPS est directement monté sur le NAS (interface VPN client) vers le serveur OpenVPN sur le VPS. Le containeur Telegraf du NAS vise l'addresse IP privée (en 172.X.X.X) sur le VPS, ayant ajouté une route statique sur le NAS pour emprunter le VPN pour atteindre le VPS. Ouais, .... c'est lourd ! C'est un essai (d'autant qu'hier le VPN est tombé mais n'est pas remoté tout seul .... Pour info, enlever influx et grafan du NAS fait quasiment "économiser" 10% d'activité disque permenente .... sans compter l'économie de mémoire. Bruno78

@Jeff777, @.Shad., quel est le problème exactement ? je ne suis pas sûr d'avoir compris le détail de la configuration. De mon côté j'ai fait (pas terminé) quelques changements: la vDSM7 ne me sert que pour des tests ponctuels. Je ne la supervise pas, par contre il m'arrive de faire des tests de supervision à partir de cette vDSM7. considérant que ce n'est pas le job premier du NAS de faire du monitoring (même si il est capable de le faire on est d'accord), je "déporte" Grafana, Influxdb et Loki sur une VPS chez OVH, et je garde évidemment les process d'alimentation des données (telegraf, promtail, scripts perso) sur les entités concernées (NAS, RPi, VPS ). Le tout via un VPN OpenVPN entre le NAS et le VPS OVH. Dans cette supervision du NAS (docker telegraf sur le NAS), il y a bien sûr le monitoring de l'ensemble des dockers tournants sur le NAS. Bref, @Jeff777, comment puis-je t'aider ? Cdt Bruno78

@.Shad. : je te confirme (je viens de le refaire), que stopper la package Docker a pour conséquence de supprimer le link macvlan-swag, et donc tout ce qui suit ....