Blog de dada

DevOps, bidouilleur et routard plein de logiciels libres

auto-hébergement

Ajuster le Nextcloud de son Turris Mox

Rédigé par dada / 12 août 2019 / 3 commentaires



Un Turris Mox ?

Pour celles et ceux qui ne sauraient pas ce que c'est, je vous redirige par ici. Je vous balance directement le lien vers la description de sa version cloud parce que c'est celle que j'ai prise. L'objectif ? Arrêter d'héberger mes données sur des serveurs tiers et revenir à un vrai auto-hébergement pour toute ma partie données perso. Ce blog et les autres outils resterons dans les nuages.

Nextcloud

L'intégration de Nextcloud dans le TurrisOS, la variante d'OpenWRT présente dans le Mox, ne vient pas avec toutes les petites configurations qui vont bien. Voici une rapide liste des choses à modifier ou corriger pour que tout se passe au mieux.

Remarque

Notez que le Mox est un petit appareil aux performances modestes. Il comblera sans trop de problème mes besoins perso, en tant qu'utilisateur unique de mon instance, mais n'espérez réussir à gérer convenablement plusieurs utilisateurs actifs en même temps.

Les modifications

  • Variables d'environnement 
vim /etc/php7-fpm.d/www.conf
Vous y trouverez ces variables commentées, enlevez le point-virgule qui traîne devant : 
env[HOSTNAME] = $HOSTNAME
env[PATH] = /usr/local/bin:/usr/bin:/bin
env[TMP] = /tmp
env[TMPDIR] = /tmp
env[TEMP] = /tmp
  • PHP Memory limit
La configuration de PHP-FPM vient avec un memory_limit de 384M quand Nextcloud en réclame 512 pour bien fonctionner. Pour corriger le tire, allez modifier la valeur dans /etc/php.ini pour remplacer 384 par 512 :
memory_limit = 512M
Et redémarrer le PHP-FPM :
/etc/init.d/php7-fpm restart
  • Opcache
Ajoutez la conf Opcache qui va bien dans /etc/php.ini :
opcache.enable=1
opcache.interned_strings_buffer=8
opcache.max_accelerated_files=10000
opcache.memory_consumption=128
opcache.save_comments=1
opcache.revalidate_freq=1
  • Lighttpd
Le serveur web choisi par TurrisOS est Lighttpd. Sachez qu'il est possible d'installer Nginx pour le remplacer mais comme c'est la configuration par défaut, j'ai décidé de le laisser là.

Pour corriger les erreurs de well-known, ajouter les lignes qui manquent dans /etc/lighttpd/conf.d/nextcloud.conf :
alias.url += ( "/nextcloud" => "/srv/www/nextcloud" )

$HTTP["url"] =~ "^/nextcloud/(build|tests|config|lib|3rdparty|templates|data)" {
     url.access-deny = ("")
}

# Redirect Cal/CardDAV requests to Nextcloud endpoint:
url.redirect = (
    "^/.well-known/caldav"  => "/nextcloud/remote.php/dav",
    "^/.well-known/carddav" => "/nextcloud/remote.php/dav",
    "^/.well-known/webfinger" => "/nextcloud/public.php?service=webfinger"

)
Et redémarrez le service :
/etc/init.d/lighttpd restart
  • Memcache
Pour le moment, je n'ai pas trouvé comment faire pour mettre en place un système de cache honorable pour améliorer les performances générales de Nextcloud. Il n'y a pas, dans les dépôts officiels de TurrisOS, de paquet php-redis ou encore php-memcached. Du coup, pas de cache.


Nextcloud, PHP-FPM, Nginx et Kubernetes

Rédigé par dada / 14 janvier 2019 / 7 commentaires




Ma première installation de Nextcloud dans Kubernetes était basée sur l'image Docker contenant Apache2. Aucun souci notable au niveau de la synchro des agendas, des fichiers ou encore des contacts. Par contre, la génération des miniatures des photos s'est révélée être un drame : Apache s'emballait et entraînait le nœud sur lequel il tournait avec lui, dans la tombe. Il me fallait une solution, j'ai donc décidé de changer de conteneur et de prendre celui basé sur PHP-FPM.

Un pod avec deux conteneurs

On entend souvent la rumeur racontant qu'un pod ne contient qu'un conteneur. C'est souvent vrai, mais c'est aussi faux. Dans l'exemple qui va suivre, le pod gérant Nextcloud contiendra le conteneur officiel de Nextcloud et un conteneur Nginx.

Contexte

Pour suivre, sachez que mon cluster, celui grâce auquel vous lisez ces quelques lignes, gère son système de fichier avec Rook, dont j'ai déjà parlé ici. Mes nœuds sont chez Hetzner, ce sont des CX21, du cloud public donc, et mes services sont exposés en NodePort derrière un Nginx configuré en LoadBalancer. Maintenant que vous savez ça, on peut y aller.

Le Deployment

On va commencer par balancer le Yaml qui marche : 
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nextcloud-deployment
spec:
  selector:
    matchLabels:
      app: nextcloud
  replicas: 1
  template:
    metadata:
      labels:
        app: nextcloud
    spec:
      containers:
      - name: nginx
        image: nginx:1.15
        ports:
        - containerPort: 80
        volumeMounts:
        - name: nginx-config
          mountPath: /etc/nginx/nginx.conf
          subPath: nginx.conf
        - name: pv-nextcloud
          mountPath: /var/www/html
        lifecycle:
          postStart:
            exec:
             command: ["bin/sh", "-c", "mkdir -p /var/www/html"]
      - name: nextcloud
        image: nextcloud:14.0-fpm
        ports:
        - containerPort: 9000
        volumeMounts:
        - name: pv-nextcloud
          mountPath: /var/www/html
        resources:
          limits:
            cpu: "1"
      volumes:
      - name : nginx-config
        configMap:
           name: nginx-config
      - name: pv-nextcloud
        flexVolume:
          driver: ceph.rook.io/rook
          fsType: ceph
          options:
            fsName: myfs
            clusterNamespace: rook-ceph
            path: /nextcloud2

Il n'y a pas le Service associé pour la simple et bonne raison que chacun fait comme il le veut. Si vous êtes chez DigitalOcean, OVH ou chez un des GAFAM qui propose du k8s, vous aurez un LoadBalancer qui va bien. Si vous êtes comme moi, vous êtes réduit à faire du NodePort.

Ce qu'il faut comprendre

Vous remarquerez qu'il y a deux conteneurs : Nginx et Nextcloud-FPM. Nginx écoute sur le port 80 et va router le trafic à travers vers le port 9000 du conteneur de Nextcloud.

Nginx

      - name: nginx
        image: nginx:1.15
        ports:
        - containerPort: 80
        volumeMounts:
        - name: nginx-config
          mountPath: /etc/nginx/nginx.conf
          subPath: nginx.conf
        - name: pv-nextcloud
          mountPath: /var/www/html
        lifecycle:
          postStart:
            exec:
             command: ["bin/sh", "-c", "mkdir -p /var/www/html"]
On va faire gober à Nginx deux points de montage : sa configuration et les sources de Nextcloud. Sans les sources de l'application, Nginx ne pourra pas avoir accès aux fichiers PHP, et ne servira donc à rien. On va donc prendre le point de montage originalement dédié à Nextcloud pour le monter une deuxième fois dans un deuxième conteneur, celui de Nginx.

Lifecycle

Remarquez la présence de la section lifecycle, elle permet d’exécuter ce que vous voulez au démarrage du conteneur. Quand j'apprenais à me servir de ce couple, je ne comprenais pas pourquoi Nginx ne voulait pas correctement fonctionner. J'ai passé du temps à comprendre que le conteneur Nginx et le conteneur Nextcloud n'avaient pas le même docRoot :
  • Nginx : /srv/html
  • Nextcloud : /var/www/html
Comprenez que les requêtes Nginx allaient chercher des fichiers dans /srv/html/blabla.php quand Nextcloud annonçait la présence de ses sources dans /var/www/html/blabla.php. Le bordel.

C'est là que je n'ai trouvé pas idiot l'idée de créer le chemin manquant au démarrage du pod avec un postStart. Du coup, j'avais Nginx et Nextcloud au diapason. Il est sans doute possible de configurer Nginx pour surcharger son docRoot, mais c'était l'occasion de jouer avec des commandes en amont de la création d'un conteneur.

Les deux points de montage

On a donc un point de montage pour les sources de Nextcloud :
        - name: pv-nextcloud
          mountPath: /var/www/html
Et un point de montage pour la configuration de Nginx :
        - name: nginx-config
          mountPath: /etc/nginx/nginx.conf
          subPath: nginx.conf

Là aussi, j'ai perdu un peu de temps avant de comprendre qu'il fallait balancer toute la configuration de Nginx et pas seulement ce que j'ai l'habitude de mettre dans les sites-enabled. C'est du moins à faire quand on écrase le nginx.conf du pod. En y réfléchissant, c'est sans doute plus simple de modifier le point montage pour n'ajouter qu'un fichier dans le fameux sites-enabled.

Pour gérer la configuration de Nginx, je passe par une ConfigMap :
kind: ConfigMap
apiVersion: v1
metadata:
  name: nginx-config
data:
  nginx.conf: |
    worker_processes  1;

    error_log  /var/log/nginx/error.log warn;
    pid        /var/run/nginx.pid;

    events {
        worker_connections  1024;
    }

    http {
        include       /etc/nginx/mime.types;
        default_type  application/octet-stream;

        log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                          '$status $body_bytes_sent "$http_referer" '
                          '"$http_user_agent" "$http_x_forwarded_for"';

        access_log  /var/log/nginx/access.log  main;

        sendfile        on;
        #tcp_nopush     on;

        keepalive_timeout  65;

        #gzip  on;

        server {
            listen 80;

            add_header X-Content-Type-Options nosniff;
            add_header X-XSS-Protection "1; mode=block";
            add_header X-Robots-Tag none;
            add_header X-Download-Options noopen;
            add_header X-Permitted-Cross-Domain-Policies none;
            add_header Referrer-Policy no-referrer;

            root /var/www/html;

            location = /robots.txt {
                allow all;
                log_not_found off;
                access_log off;
            }

            location = /.well-known/carddav {
                return 301 $scheme://$host/remote.php/dav;
            }
            location = /.well-known/caldav {
                return 301 $scheme://$host/remote.php/dav;
            }

            # set max upload size
            client_max_body_size 10G;
            fastcgi_buffers 64 4K;

            # Enable gzip but do not remove ETag headers
            gzip on;
            gzip_vary on;
            gzip_comp_level 4;
            gzip_min_length 256;
            gzip_proxied expired no-cache no-store private no_last_modified no_etag auth;
            gzip_types application/atom+xml application/javascript application/json application/ld+json application/manifest+json application/rss+xml application/vnd.geo+json application/vnd.ms-fontobject application/x-font-ttf application/x-web-app-manifest+json application/xhtml+xml application/xml font/opentype image/bmp image/svg+xml image/x-icon text/cache-manifest text/css text/plain text/vcard text/vnd.rim.location.xloc text/vtt text/x-component text/x-cross-domain-policy;

            location / {
                rewrite ^ /index.php$request_uri;
            }

            location ~ ^/(?:build|tests|config|lib|3rdparty|templates|data)/ {
                deny all;
            }
            location ~ ^/(?:\.|autotest|occ|issue|indie|db_|console) {
                deny all;
            }

            location ~ ^/(?:index|remote|public|cron|core/ajax/update|status|ocs/v[12]|updater/.+|ocs-provider/.+)\.php(?:$|/) {
                fastcgi_split_path_info ^(.+\.php)(/.*)$;
                include fastcgi_params;
                fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
                fastcgi_param PATH_INFO $fastcgi_path_info;
                # fastcgi_param HTTPS on;
                #Avoid sending the security headers twice
                fastcgi_param modHeadersAvailable true;
                fastcgi_param front_controller_active true;
                fastcgi_pass 127.0.0.1:9000;
                fastcgi_intercept_errors on;
                fastcgi_request_buffering off;
            }

            location ~ ^/(?:updater|ocs-provider)(?:$|/) {
                try_files $uri/ =404;
                index index.php;
            }

            # Adding the cache control header for js and css files
            # Make sure it is BELOW the PHP block
            location ~ \.(?:css|js|woff|svg|gif)$ {
                try_files $uri /index.php$request_uri;
                add_header Cache-Control "public, max-age=15778463";
                add_header X-Content-Type-Options nosniff;
                add_header X-XSS-Protection "1; mode=block";
                add_header X-Robots-Tag none;
                add_header X-Download-Options noopen;
                add_header X-Permitted-Cross-Domain-Policies none;
                add_header Referrer-Policy no-referrer;

                # Optional: Don't log access to assets
                access_log off;
            }

            location ~ \.(?:png|html|ttf|ico|jpg|jpeg)$ {
                try_files $uri /index.php$request_uri;
                # Optional: Don't log access to other assets
                access_log off;
            }
        }

    }
Eh oui, il y a tout dedans. Ça déforme l'affichage de ce billet, m'enfin. C'est une configuration Nginx classique.

On peut quand même s'arrêter sur la configuration du fastcgi_pass : il tape sur le 127.0.0.1 et le port 9000 du conteneur Nextcloud. Je n'ai pas encore gratté pour comprendre le pourquoi du comment mais je suppose que les deux conteneurs tournant dans le réseau du pod, ils se comportent comme deux services dans une seule et même machine. À confirmer.

On apply tout ça

Attention ! Avant de balancer le Deployment, balancez le yaml de la ConfigMap. Sans ça, Nginx ne chargera pas votre configuration !
dada@k8smaster1:~$ kubectl apply -f configmap.yaml
dada@k8smaster1:~$ kubectl apply -f nextcloud.yaml
Si tout se passe bien, vous devriez pouvoir voir ça :
dada@k8smaster1:~$ kubectl get pods
nextcloud-deployment-d6cbb8446-87ckf   2/2     Running   0          15h
Remarquez que Kubernetes vous montre bien qu'il y a deux conteneurs dans ce pod : 2/2.

Pour aller plus loin

Je ne parle pas des vérifications de l'état des conteneurs. Il faudrait placer des sondes liveness et readness pour parfaitement vérifier l'état des conteneurs. Sans ça, si l'un des services tombe, Kubernetes ne sera pas forcément en mesure de le détecter et de relancer le pod.
Il est aussi possible, pour respecter le concept de micro-service, de ne pas concaténer deux conteneurs dans un seul pod mais de faire un pod par conteneur et des services associés. Ça demande plus de travail pour un résultat qui, dans mon cas, n'apporte pas grand chose.

Installer Grafana, Prometheus et Node Exporter

Rédigé par dada / 31 janvier 2018 / 25 commentaires




Le monitoring, j'aime à dire que c'est ce que l'administrateur a de plus pervers : surveiller, voir et savoir tout ce qui se passe sur ses machines, sans limite, et de la façon qui lui est la plus agréable possible. Un admin, c'est un stalker, en fait.

De mon côté, après avoir testé Facette, Monitorix, Netdata et Munin, je joue en ce moment avec Grafana, Prometheus et les exporters qui vont avec. C'est l'objet de ce billet, ça tombe bien, alors voyons comment faire pour installer tout ça en quelques minutes.

Comprendre l'installation en quelques lignes

Vos serveurs vont avoir un exporter simple : le Node Exporter, qui va permettre à Prometheus de récupérer les différentes métriques qu'il partage. La bonne pratique consiste à installer Prometheus sur une serveur qui sera dédié à la collecte des informations. Si vous installez tout sur une seul et même machine, vous pourrez mettre du localhost dans presque tout ce qui suit. Grafana, quant à lui, va afficher ses données avec des jolies couleurs et dans des jolis graphiques.

Installer Prometheus

Pas de piège pour une Debian Stretch :
apt install prometheus
C'est un peu plus compliqué pour une Jessie :
apt -t jessie-backports install prometheus
Notez qu'essayer de lancer le service sous Jessie via systemd est foireux : il faut utiliser la bonne vieille méthode :
/etc/init.d/prometheus start
Si vous ne faites pas ça et que vous avez des soucis, genre un service qui écoute déjà sur le 9090, vous ne verrez rien dans les logs.

A partir de là, vous devriez pouvoir accéder à Prometheus en tapant sur le port 9090 de votre serveur.



Quoi ? Jamais j'ai écrit que Prometheus était sexy ;-)

Installer Node Exporter

Prometheus ne sait pas collecter d'informations tout seul. Il lui faut des exporters. Le plus simple et le plus complet pour avoir une vision global de la situation d'une machine (CPU, RAM, Load, traffic, etc) est le bien nommé Prometheus Node Exporter. Pour l'installer : 
apt install prometheus-node-exporter

Configurer le Node Exporter dans Prometheus

Maintenant que les deux premiers outils sont installés, il va falloir les faire bosser ensemble. On va simplement déclarer dans la configuration de Prometheus qu'il doit se mettre d'accord avec l'exporter :
vim /etc/prometheus/prometheus.yml
scrape_configs:
  - job_name: 'prometheus'

    scrape_interval: 5s
    scrape_timeout: 5s

    static_configs:
      - targets: ['localhost:9090']

  - job_name: 'node'
    static_configs:
      - targets: ['monserveur:9100','monserveurdeux:9100']

L'exemple de configuration ci-dessus est quasiment celle de base. Il faut noter que le job_name 'prometheus' est là pour expliquer que Prometheus est en local. Quant au job_name 'node',  il fait comprendre à Prometheus que le Node Exporter est présent sur les hosts cités entre crochets.

On sauvegarde tout ça et on recharge la configuration de Prometheus avec le curl qui va bien :
curl -X POST http://localhost:9090/-/reload
Si vous n'avez pas d'erreur, on va enfin s'attaquer à la partie artistique de l'opération : les graphiques !

Installer Grafana

L'installation est, là aussi, triviale :
apt-get install grafana
C'est 'achement difficile, tout ça, hein ?

Configurer Nginx

Pour ne pas avoir à toujours taper le port de Grafana, voici un bout de conf pour Nginx :
server {
    listen 80;

        root /var/www/html/;

        server_name grafana.monserveur.tld;

        location / {
                proxy_set_header X-Real-IP $remote_addr;
                proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
                proxy_set_header Host $http_host;
                proxy_redirect off;
                proxy_pass http://127.0.0.1:3000;
        }
}

Configurer Grafana

- Ajouter une data source

Grafana, ça marche tout seul. Une fois installé, il vit sa vie. Par contre, il va falloir le brancher à Prometheus, tout de même.
Comme blablater, c'est chiant, voici une capture d'écran de ce que vous devez faire :



En commentaire : cliquez sur le menu en haut à gauche de Grafana pour ajouter une nouvelle data source et récupérer les informations que vous voyez dans la capture.
Vous remarquerez que le port mis en place est bien celui de Prometheus et pas celui du Node Exporter : Grafana ne communique pas avec Node Exporter (sur le port 9100), mais uniquement avec Prometheus.

On arrive à la fin. Maintenant que l'exporter balance des informations, que Prometheus en est conscient et que Grafana arrive à échanger avec Prometheus, on va pouvoir mettre en place un dashboard pour profiter des graphiques !

- Installer le dashboard Node Exporter Full

Ici, c'est aussi simple (mais pourquoi est-ce que je m'emmerde à écrire ce billet si c'est si simple ?!), pour installer un dashboard, allez dans le Menu de Grafana, puis Dashboard et enfin Import. Je dis bien Import, pas New. Enfin, ajoutez le nombre 1860 dans la premier champ pour faire apparaître la fenêtre suivante :



Bon, j'ai aussi cliqué n'importe-où sur la fenêtre pour que Grafana prenne en compte la nouvelle information et, finalement, affiche la capture ci-dessus.

On a fait le tour. Tout est bon. Vous pouvez aller sur la page d'accueil de Grafana, cliquer sur le nom de votre nouveau dashboard et profiter du spectacle !



Streamer sa musique librement

Rédigé par dada / 05 décembre 2017 / 14 commentaires


Il existe des tonnes de façon d'apprécier sa musique sans pour autant la traîner sur des CD ou sur la carte mémoire de son téléphone. Les plus simples consistent à prendre un abonnement chez Deezer ou chez Spotify mais, manque de chance, c'est plein de DRM et ça ne fonctionne pas partout sur la planète. Oui, je reste un grand traumatisé de Spotify : je n'ai jamais réussi à écouter mes playlists alors que je vadrouillais en Syrie (avant !).

Du coup, voici ma solution. Ce n'est peut-être pas la plus simple mais elle me permet de combiner Nextcloud, Sonerezh et Power Ampache. Avec tout ça, j'écoute ma musique via une interface web et via une application mobile partout où je veux et je contrôle tout. Le seul souci, c'est que ça me coûte cher en musique.

Nextcloud ?

Pour n'avoir qu'à copier/coller mes dernières trouvailles dans un répertoire de mon PC. Il va être parcouru par le client de synchronisation : son contenu va donc directement être envoyé sur le serveur de streaming. C'est simple, facile et pour les feignants. En plus, ça fait déjà un backup.

Music ?

C'est l'application qui permet de lire ses fichiers audios dans NC. Ça fait du bon boulot, mais c'est moche et assez lent. Je préfère carrément Sonerezh. Ceci-dit, elle supporte l'API d'Ampache, et ça, c'est cool. Vous le voyez arriver, le lien avec Power Ampache ?

Power Ampache ?

Là, c'est le Graal. Votre NC est configuré, Music fournit l'API d'Ampache : Power Ampache va tout récupérer. Vous avez maintenant du streaming audio de qualité sur votre Smartphone. Bah oui, ça supporte le FLAC, tout ça !
Ah, et pensez à cocher "Offline Songs" si ça vous embête de pomper votre forfait 3/4G.

Sonerezh ?

Quand votre NC récupère vos fichiers audios, vous y avez accès via Music et Power Ampache, mais pas via une belle et rapide interface web. C'est là que Sonerezh débarque.
Pour que ça marche, il faut lui dire d'aller récupérer le contenu de votre répertoire Musique qui est dans Nextcloud, tout simplement.
Perso, je suis passé par le principe du stockage externe de Nextcloud pour que tous les partis puissent se parler, et que je puisse faire du gros copier/coller depuis mon PC sans avoir jamais à me connecter au serveur.

Qu'est-ce que ça donne ?

Sonerezh :



Power Ampache :


Tout cela n'est pas parfait, mais c'est de la bonne bidouille ! Du logiciel libre et un peu d'idées pour ne plus jamais se prendre le choux à gérer sa musique entre le local et le distant. Y'a sans doute plus simple, mais bon, une fois que ce système est en place, on n'a plus qu'à vérifier les tags avec EasyTAG et à faire un copier/coller. Cool.

Des jolis graphes à Facette 0.4.0 et RRD

Rédigé par dada / 15 août 2017 / 9 commentaires


En 2015, j'étais tombé sur Facette, un outil plutôt bien foutu pour afficher l'état de mon serveur sans avoir à m'y connecter. En 2015, après quelques mésaventures, j'avais passé mon système de monitoring sous Monitorix. Eh bien, en 2017, avec la sortie de Facette 0.4rc1 (puis rc2 le temps de rédiger le billet), je retourne à mon premier amour !

Pourquoi ? Parce que cette version 0.4 est totalement retravaillée de l'intérieur, que ses jolis graphiques me manquent et que Monitorix, aussi simple soit-il, n'est pas vraiment une solution flexible. Je vous propose ici de quoi bien commencer, vu que la doc m'a filé mal au crâne.

Installer Facette

Pour les utilisateurs de Debian Jessie en amd64, voici le wget qui va bien. Pour les autres, faites un tour par ici.
wget https://github.com/facette/facette/releases/download/0.4.0rc2/facette_0.4.0rc2_jessie-amd64.deb
Pour installer le paquet :
dpkg -i facette_0.4.0rc2_jessie-amd64.deb

Installer les dépendances RRD

Il est possible de remplir Facette avec Graphite, Influxdb, Kairosdb, ou encore Facette lui-même. J'ai choisi RDD, parce que. 
apt-get install rrdtool rrdcached collectd

Configurer Nginx

Facette a besoin d'un ReverseProxy pour fonctionner : en voici un exemple.

Configurer RRD

Installer les dépendances de RRD ne suffit pas, voici les quelques étapes supplémentaires pour faire fonctionner le bousin :

Créez les répertoires rrdcached :
mkdir /var/run/rrdcached/
On donne les bons droits à l'utilisateur facette :
chown facette: /var/run/rrdcached
Ajoutez ces lignes dans /etc/default/rrdcached : 
OPTS="-s facette"
OPTS="$OPTS -l unix:/var/run/rrdcached/rrdcached.sock"
OPTS="$OPTS -j /var/lib/rrdcached/journal/ -F"
OPTS="$OPTS -w 1800 -z 1800 -f 3600 -t 4"
Cela permet, en gros, à Facette d'utiliser RRD.

Relancez RRDcached.
/etc/init.d/rrdcached restart
Avec un ps, on vérifie que tout est comme on veut :
root@serveur:~# ps faux | grep rrd
root     14476  0.0  0.0  12736  2204 pts/0    S+   20:33   0:00                      \_ grep rrd
root     14465  0.0  0.0 138288  2632 ?        Ssl  20:33   0:00 /usr/bin/rrdcached -s facette -l unix:/var/run/rrdcached/rrdcached.sock -j /var/lib/rrdcached/journal/ -F -w 1800 -z 1800 -f 3600 -t 4 -p /var/run/rrdcached.pid

Configurer RRD comme fournisseur / provider

Allez dans le panneau d'administration de Facette et configurez RRD avec les informations que vous venez de mettre en place :

- Dossier de base
/var/lib/collectd/rrd

- Socket du démon rrdcached
/var/run/rrdcached/rrdcached.sock

- Motif de correspondance
(?P<source>[^/]+)/(?P<metric>.+).rrd

Voilà ! Vous devriez maintenant pouvoir commencer à faire vos propres graphiques :


Vous arriverez sans doutes à mettre en place vos graphiques comme des grands et à les afficher dans des collections, pas besoin d'expliquer comment faire.

Je reviens rapidement sur les fournisseurs de données. J'ai dit que Facette pouvait être de la partie, en plus de RRD et des autres. Cela veut dire que plusieurs instances bien configurées peuvent être agrégées sur un même serveur. C'était déjà une option bien chouette à l'époque, ça l'est toujours aujourd'hui : avoir une unique page pour, par exemple, surveiller tout le trafic réseau ! 

Fil RSS des articles de ce mot clé