Dimebag Darrell

Je sais que ce n'est pas du monitoring réseau, mais j'ai vu qu'il était possible de monitorer son onduleur (photovoltaique) en utilisant influxdb et grafana, ça à l'air quand même assez solide à mettre en place https://github.com/michbeck100/pv-monitoring

Bonjour tout le monde, @.Shad. @oracle7 @MilesTEG1 Voila, après plusieurs tests, J'ai trouvé la solution J'ai simplement supprimé la ligne user dans le docker compose et depuis, toutes les informations relatives à mes containers remontent correctement dans grafana. (pourquoi ça ne fonctionnait pas avant ! mystère...) J'espère que ça pourra éclairer quelques uns ici ! Belle journée

@.Shad. Voici ce que me retourne la commande quand je check l'état de docker... sudo systemctl status docker ● docker.service Loaded: not-found (Reason: No such file or directory) Active: inactive (dead)

@.Shad. Pour information, oui, les données remontent bien dans grafana. Mais en effet, les données docker sont vides. Concernant ce problème, une idée d'où ça pourrait venir ? Car il y a deux semaines d'ici, tout fonctionnait de mon coté. C'est depuis mes problèmes de droits que tout est parti en vrille

Bonjour tout le monde, Pour information, je suis reparti de 0 en supprimant Influxdb et telegraf. Ensuite, j'ai suivi le tuto à la lettre. Voici le message que je reçois dans le log pour le container telegraf [inputs.docker] Error in plugin: Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?

@Mic13710 & @oracle7 Merci pour votre retour, Premièrement je vais répondre à @Mic13710, la question est de savoir pourquoi faire un forum où l'on pose des questions techniques, oui je cite les personnes qui me répondent, so what ? Désolé si je n'ai pas les capacités techniques comme certains peuvent l'avoir ici. Si c'était le cas, je pense que je ne serai pas sur ce forum à poser mes questions/remarques, (désolé si je passe pour un newbie, mais ça me permet de progresser!) Il faut croire que ce n'est pas l'objectif des discussions...) @oracle7 Pour ta gouverne, je viens de decouvrir le chmod calculator, donc sorry si je passe encore pour un débutant... Très basiquement, 0 n'est pas égale à 660, si c'est si simple pour toi de comprendre... ça ne l'est pas pour moi ! Pour résumé la situation, ce week-end j'ai créé un user et un group docker, j'ai appliqué ce groupe sur mon dossier docker, depuis, tout par en vrille ! y compris mon monitoring qui tournait nickel avant cela ! J'essaie juste de résoudre mes soucis..., il faut croire que c'est trop en demander ici ! ps: je suis dispo en mp si jamais ! (si certain(e)s sont choqué(e)s par mes propos !

Une question, quelle est la commande pour supprimer le user et la database dans influxdb ?

Concernant le nom de la db, user et password tout est OK. Par contre, je vais certainement supprimer la db existante pour telegraf et la refaire. Après analyse aussi, je remarque que docker n'a que ces droits : srw-rw---- 1 root root 0 Apr 2 22:48 /var/run/docker.sock (j'ai lu, par défaut ça devrait être 660 ! correct ? Concernant ce dernier point, comment puis-je redémarrer docker.sock ?

@MilesTEG1 voici la réponse srw-rw---- 1 root root 0 Apr 2 22:48 /var/run/docker.sock Pour information, j'ai créé un user pour docker, est-ce possible de lui assigner les droits ? Si c'est le cas, n'y -a-t-il pas un risque pour tous mes autres containers qui semblent fonctionner normalement?

2023-04-05T11:46:37Z W! [outputs.influxdb] When writing to [http://monitoring_influxdb:8086]: database "monitoring_telegraf" creation failed: Post "http://monitoring_influxdb:8086/query": dial tcp 172.18.0.2:8086: connect: connection refused 15 2023-04-05T11:46:45Z W! [inputs.ping] Collection took longer than expected; not complete after interval of 5s 16 2023-04-05T11:46:47Z E! [outputs.influxdb] When writing to [http://monitoring_influxdb:8086]: failed doing req: Post "http://monitoring_influxdb:8086/write?db=monitoring_telegraf": dial tcp 172.18.0.2:8086: connect: connection refused 17 2023-04-05T11:46:47Z E! [agent] Error writing to outputs.influxdb: could not write any address 18 2023-04-05T11:46:55Z W! [inputs.ping] Collection took longer than expected; not complete after interval of 5s 19 2023-04-05T11:47:00Z E! [inputs.docker] Error in plugin: permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock: Get "http://%2Fvar%2Frun%2Fdocker.sock/v1.24/info": dial unix /var/run/docker.sock: connect: permission denied @.Shad. correction faite, mais ça ne change rien @oracle7 comment faire pour voir les droits dont tu parles ? Version influxdb : INFLUXDB_VERSION 1.8.10

Je viens de repartir de 0 avec un nouveau fichier telegraf Mais rien à faire, j'ai toujours les mêmes erreurs 2023-04-05T09:58:37Z E! [outputs.influxdb] When writing to [https://monitoring_influxdb:8086]: failed doing req: Post "https://influxdb:8086/write?db=telegraf": http: server gave HTTP response to HTTPS client [inputs.docker] Error in plugin: permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock: Get "http://%2Fvar%2Frun%2Fdocker.sock/v1.24/containers/json?filters=%7B%22status%22%3A%7B%22running%22%3Atrue%7D%7D": dial unix /var/run/docker.sock: connect: permission denied J'ai l'impression que j'ai un problème de droit, mais je ne sais pas/plus ce que je dois faire... !

Salut, Quand je change les données dans le docker-compose users userID:groupID, le comportement change, mais j'ai toujours des erreurs d'accès aux données. j'ai essayé avec mon user admin, mais ça ne semble pas régler le problème. J'ai créé un user et un groupe specifique (user docker et groupe docker), comme expliqué dans le tuto, mais en vain !

Merci pour l'info, @.Shad. Au final, comment as tu résolu le problème pour portainer ? (tu y es allé à la brutal, c'est à dire, tout supprimer et repartir d'une install toute fraîche ?)

Re, Voila, après m'être mechament creusé la tête, j'y suis parvenu, Pour ceux qui ça interesserait, j'ai ajouté la création automatique du macvlan dans mon docker-compose Par contre, j'ai ceci comme erreur dans diagnosis ignoring nameserver 192.168.1.101 - local interface @.Shad., si tu veux y jeter un oeil !!!! version: '2.1' services: pi-hole: image: pihole/pihole:latest container_name: Synology_pi-hole hostname: pi-hole networks: pihole_network: ipv4_address: 192.168.1.x #adresse IP de l'instance pi-hole environment: # General - ADMIN_EMAIL=monadressemail@mail.xyz - TZ=Europe/Paris - PIHOLE_DNS_=80.67.169.12;9.9.9.9 # IP des serveurs DNS FdN et Quad9 - DNSSEC=false - DNS_BOGUS_PRIV=true - DNS_FQDN_REQUIRED=true - DNSMASQ_LISTENING=local - INTERFACE=ovs_bond0 # j'ai mis le bond de mon aggrégation réseaux (sinon, par défaut - ovs_eth0) - FTLCONF_LOCAL_IPV4=192.168.1.x # IP du conteneur Pi-hole - VIRTUAL_HOST=pi-hole.localhost # Si on souhaite acceder a Pi-hole par un nom de domaine (proxy inverse par exemple) - WEBPASSWORD=passwordpihole # Mapping utilisateurs et groupes - PIHOLE_UID=1038 # pihole UID - PIHOLE_GID=65539 # pihole GID # pihole-www GID # Conditional forwarding - REV_SERVER=true # Permet de recuperer les hostnames des peripheriques du reseau - REV_SERVER_TARGET=192.168.1.x # Voir paragraphe CONDITIONAL FORWARDING (adresse de l'instance pihole) - REV_SERVER_CIDR=192.168.1.0/24 # Votre sous-reseau local - REV_SERVER_DOMAIN=localhost # Domaine local # Personnalisation interface - TEMPERATUREUNIT=C - WEBTHEME=default-darker - WEBUIBOXEDLAYOUT=boxed volumes: - /volume1/docker/pihole/pihole:/etc/pihole/ - /volume1/docker/pihole/dnsmasq.d:/etc/dnsmasq.d/ dns: - 127.0.0.1 - 80.67.169.12 restart: unless-stopped networks: pihole_network: driver: macvlan driver_opts: parent: ovs_bond0 #par défaut - ovs_eth0 ipam: config: - subnet: 192.168.1.0/24 # <-- Update gateway: 192.168.1.3 # <-- Update ip_range: 192.168.1.192/24 # <-- Update

Bonsoir tout le monde, Suite à un restore de mes paramètres systeme sur mon syno (erreurs lors de la gestions de mes droits et authorisations des users) Maintenant sur pihole, j'ai ce type de message qui apparait Même si j'essaie de réinstaller "from scratch" un nouveau container pihole !... 023-04-02T22:49:26.626971549Z 2023-04-02T22:49:26.627168655Z [✗] Unable to copy data from /etc/pihole/gravity.db to /etc/pihole/gravity.db_temp 2023-04-02T22:49:26.627784587Z 2023-04-02T22:49:26.627852463Z [✗] Unable to create gravity database. Please try again later. If the problem persists, please contact support. 2023-04-02T22:49:28.522851309Z Stopping pihole-FTL 2023-04-02T22:49:28.524815448Z pihole-FTL: no process found 2023-04-02T22:49:30.457269902Z Stopping pihole-FTL 2023-04-02T22:49:30.459401694Z pihole-FTL: no process found 2023-04-02T22:49:32.689037662Z Stopping pihole-FTL 2023-04-02T22:49:32.690976351Z pihole-FTL: no process found 2023-04-02T22:49:34.371869996Z Stopping pihole-FTL 2023-04-02T22:49:34.373830460Z pihole-FTL: no process found 2023-04-02T22:49:35.296503843Z Stopping pihole-FTL 2023-04-02T22:49:35.298273160Z pihole-FTL: no process found

Bonjour tout le monde, Lors d'un restore, je remarque maintenant que j'ai une stack que je ne peux plus supprimer (via portainer), comme si celle-ci était toujours attribuée et gérée par une autre intance, malgré que celle-ci ne fonctionne plus. Il m'est impossible de la supprimer, est-il possible de le faire manuellement ?

je n'avais pas remarqué ! Il faut en supprimer un des deux, mais les valeurs indiquées, sont-elles correctes ? Ne manque-t-il pas des valeurs ?

############################################################################### # OUTPUT PLUGINS # ############################################################################### # Configuration for sending metrics to InfluxDB [[outputs.influxdb]] # 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 = ["http://127.0.0.1:8086"] urls = ["http://monitoring_influxdb:8086"]

Donc en reformulant : Est-ce qu'InfluxDB et Telegraf sont en mode bridge ? oui Si oui, est-ce que les deux conteneurs dans le même réseau bridge

@.Shad. user admin ---- ----- admin true user_telegraf false J'essaie de reconstituer l'idée, que signifie alors "false" pour user_telegraf ? D'où viendrait le problème alors ? la solution, repartir de 0 et refaire complètement le container et ses DBs ?

@.Shad. Dans ma réponse, je montre que les données arrivent toujours bien vers influxdb --> grafana. les données sont à jours. Par contre, lorsque je regarde les droits des user dans influxDB, je vois ceci ser admin ---- ----- admin true user_telegraf false J'ai essayé de faire un GRANT ALL ON monitoring_telegraf (nom de la db) TO user_telegraf. Le user reste tjs en false... ! (donc aucun droit admin)

telegraph, correspond aux info venant des traps snmp du syno. par exemple CPU load sur mon syno, sachant que j'ai détecté le problème hier soir... néanmoins, comment je peux corriger cette erreur ? J'ai essayé en faisant un GRANT ALL on.... TO... sur le user de la db, mais je n'ai pas vu les droits changer

Bonjour tout le monde, Je reviens vers vous car j'ai remarqué ce type d'erreur dans mes logs sur telegraf. (container) 2023-03-31T11:56:03Z E! [outputs.influxdb] When writing to [http://localhost:8086]: failed doing req: Post "http://localhost:8086/write?db=telegraf": dial tcp 127.0.0.1:8086: connect: connection refused Après avoir checker les droits users dans influxdb Je vois ceci : user admin ---- ----- admin true user_telegraf false Mais malgré tout, mon monitoring fonctionne, et les données ont l'air d'être bien poussées (car dispo dans grafana) Une idée ?

Merci @.Shad. Je dois dès lors le remplacer par et je vire la ligne SSL? Exact ?

Salut @.Shad. Voila, après quelques recherches j'ai trouvé (voici ma config), j'ai changé le true en false pour le trustServer. Tout fonctionne parfaitement maintenant globalSettings__mail__replyToEmail=email@gmail.com globalSettings__mail__smtp__host=smtp.gmail.com globalSettings__mail__smtp__port=587 globalSettings__mail__smtp__ssl=true globalSettings__mail__smtp__username=email@gmail.com globalSettings__mail__smtp__password=abcdefghijklmno Enfait, gmail a désactivé la fonction par défaut pour l'utilisation du smtp pour les applications tièrces. Il faut aller dans "mots de passe des applications" qui se trouve dans la partie validation en deux étapes. Ensuite, selectionner l'application qui doit être "trusté" par Autre Il va dès lors générer un mot de passe spécifique qui devra être utilisé par l'application utilisant le protocol SMTP On copie-colle le mot de passe dans l'application ou dans un code yml par exemple pour le mot de passe SMTP (ceci est un exemple de mot de passe !!!)