• Applications

  • [Discussion] [Tuto] NETDATA : Supervisez vos serveurs !

Testé et validé, c'est vrai que c'est beau et en plus, ca ne consomme quasi rien sur le dédié, chapeau :
netdata   6336  0.3  0.5 999776 22892 ?        SNl  16:20   0:05 /usr/sbin/netdata -pidfile /var/run/netdata.pid
netdata   6341  0.1  0.0  13484  3264 ?        SN   16:20   0:02 /bin/bash /usr/libexec/netdata/plugins.d/tc-qos-helper.sh 1
Solinvictus wrote:Les processus mentionnés correspondent à quoi ? 12862 et 12864 ?

Essaie d'y mettre fin et relance les commandes.
C'est ça le plus étrange, c'est que dans l'exemple du dessus ou à l'instant avec des n° de processus différents, ce ne sont pas des processus existants ! Je veux dire j'ai Webmin ouvert avec la liste des process en cours, et aucun ne correspond ! Je comprend vraiment pas pourquoi il débloque à ce point. Le fichier de conf pourrait-il contenir des erreurs ?
Non ce n'est pas le fichier de configuration à moins que tu l'aies mal recopié.

Il faudrait que tu relances la commande qui pose problème, regarde dans tes journaux et ensuite, isole les processus en question :
ps aux | grep "pid"
pid à remplacer par le processus mentionné dans tes journaux.
Regarde si dans le fichier etc/systemd/system/netdata.service tu n'aurais pas de caractères en plus !
Solinvictus wrote:Non ce n'est pas le fichier de configuration à moins que tu l'aies mal recopié.

Il faudrait que tu relances la commande qui pose problème, regarde dans tes journaux et ensuite, isole les processus en question :
ps aux | grep "pid"
pid à remplacer par le processus mentionné dans tes journaux.
root@xxx:~# ps aux | grep 20126
root     22124  0.0  0.0  13224   980 pts/1    S+   22:09   0:00 grep 20126
root@xxx:~# ps aux | grep 20135
root     22918  0.0  0.0  13224   984 pts/1    S+   22:10   0:00 grep 20135
Et mon fichier de conf :
[Unit]
    Description=netdata
    After=network.target httpd.service squid.service nfs-server.service mysqld.$

    [Service]
    Type=forking
    WorkingDirectory=/tmp
    User=root
    Group=root
    PIDFile=/var/run/netdata/netdata.pid
    ExecStart=/usr/sbin/netdata
    ExecStop=/bin/kill -SIGTERM $MAINPID
    TimeoutStopSec=30

    [Install]
    WantedBy=multi-user.target
Il faut que relances la procédure, comme je te le précisais et que tu vérifies les logs à ce moment. Là, ton grep renvoie sa propre occurrence, ce qui tu t'en doutes, n'a aucun intérêt.
Quoi qu'il en soit, après maj récente, cela ne fonctionne plus : que ce soit par via init.d ou systemd.

Il faut que je suive ça dès que j'ai un moment.

En attendant, il suffit de lancer à la main :
cd /usr/sbin
./netdata
Yop,
Bah j'ai le même soucis avec le netdata.service (systemd)
Je pensais avoir trouvé un moyen de MaJ en faisant :
- killall netdata
- git pull
- ./netdata-installer.sh
- killall netdata
- systemctl start netdata.service
Ca fonctionnait depuis quelques commits, mais là, je ne comprends plus trop, je suis obligé de lancer le start 2 ou 3 fois pour qu'il démarre. (si je le lance une seule fois, j'ai le process "inactive", si je bourrine le systemctl start à la chaine, il démarre... 😀)
Solinvictus wrote:Il faut que relances la procédure, comme je te le précisais et que tu vérifies les logs à ce moment. Là, ton grep renvoie sa propre occurrence, ce qui tu t'en doutes, n'a aucun intérêt.
Bah je pensais pourtant l'avoir strictement suivie la fameuse procédure, j'ai relancé toutes les commandes et j'ai eu des PID différents !
Après comme tu dis, le soft évolue tous les jours (j'ai déjà fait 2 ou 3 maj) donc je ne suis pas surpris que tout évolue. En attendant, et comme tu l'a dit, je le lance en manuel via 
cd /usr/sbin
./netdata
Merci bcp pour la découverte de ce petit bijou en tout cas !
Bonjour,

Je viens de tester sur mon Rpi B+.
Cela fonctionne très bien. Même si je ne peux pas le laisser, car les ressources du Rpi sont très limitées. Surtout le CPU : 
# w
load average: 5,97, 4,38, 2,60

Une fois arrêté, le CPU respire à nouveau : 
# w
load average: 0,53, 2,35, 2,43

Ce qui est normal puisqu'il s'agit d'un Processeur ARM1176JZF-S core (ARM11) de 700 MHz, même ci ce dernier est overclocké aux maximum.
Et 512Mo de ram.
Je suis tout de même bluffer de voir ici que Raspbian est capable de beaucoup de chose avec si peu de puissance.

Voici une petite capture :

A savoir que sur le Rpi sont en cour d'utilisation :
- Pyload
- un serveur MAIL
- un serveur LEMP
- un disque dur externe en ntfs (qui consomme pas mal aussi en cpu)

Il reste même un peu de ram ! xD

Bref, c'était mon petit retour d'expérience sur le Rpi. Je vais sûrement l'installer sur mon petit Kimsufi.
Merci, pour la découverte de cet outil.
Bien sympa et bien expliqué et en plus assez pratique.
Merci pour le partage ! C'est top comme outil de monitoring 😛.

Pour ceux qui sont novices comme moi, la procédure pour mettre à jour l'outil est un peu mal expliquée sur le wiki Github. En tout cas, elle ne correspond pas à l'installation décrite dans le tuto.

Voilà ce qui a marché pour moi :
cd /opt/netdata
git pull
./netdata-installer.sh
Bonjour, des personnes auraient-elles réussi à mettre en ssl Netdata avec let's encrypt ?
Oui tout roule niquel.

http 
server {
        listen 80;
        server_name monitoring.domaine.tld;
        return 301 https://$server_name$request_uri;

        location / {
        proxy_pass http://monitoring.domaine.tld:19999;

    }

}
https 
server {
        listen 443; 
        server_name monitoring.domaine.tld; 
        ssl on;
	charset utf-8;

        ssl_certificate /etc/letsencrypt/live/monitoring.domaine.tld/cert.pem; 
        ssl_certificate_key /etc/letsencrypt/live/monitoring.domaine.tld/privkey.pem;
 
	auth_basic "Zone restreinte:";
    	auth_basic_user_file /etc/nginx/.htpasswd;

	location / {
	proxy_pass http://monitoring.domaine.tld:19999;
	proxy_set_header X-Forwarded-Host $host;
        proxy_set_header X-Forwarded-Server $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_http_version 1.1;
        proxy_pass_request_headers on;
        proxy_set_header Connection "keep-alive";
        proxy_store off;
    }

}
Bizzare car j'ai un 404 quand je génère un certificat avec let's encrypt :

Ma conf : 
upstream netdata {
    server 127.0.0.1:19999;
    keepalive 64;
}

server{
    listen 80;
    server_name monitoring.domaine.tld;

    charset utf-8;


    auth_basic "Zone restreinte:";
    auth_basic_user_file /etc/nginx/.htpasswd;

    location ~ /.well-known {
        allow all;
    }

    location / {
        proxy_set_header X-Forwarded-Host $host;
        proxy_set_header X-Forwarded-Server $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_pass http://netdata;
        proxy_http_version 1.1;
        proxy_pass_request_headers on;
        proxy_set_header Connection "keep-alive";
        proxy_store off;
    }
 }
Commande Let's encypt : 
./letsencrypt-auto certonly -d monitoring.domaine.tld  --webroot-path=/usr/share/netdata/web/
10 jours plus tard
Hey les copains, j'ai une tite question :
Vous arrivez à y accéder par URI plutôt que par sous-domaine ?
J'ai aucun soucis par sous-domaine, mais lorsque j'essaye de passer par une URI, j'ai une page blanche avec :

"File '/usr/share/netdata/web/netdata' does not exist, or is not accessible."

Quelqu'un à une idée ? Merciii
11 jours plus tard
Je n'ai pas de fichier /var/www/netdata
Putain mais c'est génial en fait, on a des stats pour chaque conteneur Docker !
Je l'ai installé sur l'host, et je fais un proxy_pass depuis mon conteneur reverse, ça marche.
    @Wonderfall T'as fait comment pour linker l'host dans le container nginx ? stp j'ai pas capté la manip