Magical Graphite

Or, « What I’ve learned about Graphite configuration ».

Last week, I worked on configuring Graphite and had to understand how it stores and aggregates data. So here are a few facts.

Graphite Retention

The way our data will be stored is described in /opt/graphite/conf/storage-schemas.conf. As an example:

[default]
 pattern = .*
 retentions = 1s:30m,1m:1d,5m:2y

This worked great when I was looking at data from the last 30 minutes.
If I was trying to display last hour metrics: nothing.
Drawing null as zero was giving me a horizontal line at the bottom of the graph.

The magic of aggregation

This behaviour comes from the file /opt/graphite/conf/storage-aggregation.conf where we find the following lines:

[99_default_avg]
 pattern = .*
 xFilesFactor = 0.5
 aggregationMethod = average

Our problem comes from xFilesFactor. It means that by default, we need at least 50% of the data to be non-null to store an average value. Think about it.

So here, I’m having a metric every second during 30 minutes. If Graphite doesn’t have something for a given second, the value is set to null. Fine, let’s move forward.
For interval higher than 30 minutes (and lower than a day), Graphite will gather data based on the aggregation configured. So it will average data and set the value null if it has less than 50% usable values (not null).

In our case, Graphite tries to average one minute of data (1m:1d) with the precision of 1s from the first retention rule (1s:30m). To understand why nothing is displayed, consider I’m Collectd is sending data to Graphite. On average, metrics are arriving every 3s. On a one minute interval, we gather 20 values but Graphite is considering 60 values, 40 being null. We only have 33% (0.33) metrics usable which is lower than 50% Graphite is waiting for so the averaged value is set to null.

The art of confusion

Now that we updated our configuration, set xFilesFactor to 0 to be sure, restart carbon-cache, everything should work fine…

But that’s not the case; no change.

In fact, previous configuration is still being used in wsp storage files. We can check it with whisper-info.py.

whisper-info.py /opt/graphite/storage/whisper/collectd/test-java01/cpu-0/cpu-user.wsp
 
 maxRetention: 63072000
 xFilesFactor: 0.5
 aggregationMethod: average
 fileSize: 2561812

Archive 0
 retention: 1800
 secondsPerPoint: 1
 points: 1800
 size: 21600
 offset: 52
Archive 1
 retention: 86400
 secondsPerPoint: 60
 points: 1440
 size: 17280
 offset: 21652
Archive 2
 retention: 63072000
 secondsPerPoint: 300
 points: 210240
 size: 2522880
 offset: 38932

See, we still have xFilesFactor: 0.5.
If you don’t care about previous data, a good solution is to delete files so that the new parameters will be used (rm -rf /opt/graphite/storage/whisper/collectd/). Maybe it’s a little bit overkill, (but easy and fast).

The other solution consists in using whisper-resize.py to enforce the new configuration.
whisper-resize.py /opt/graphite/storage/whisper/collectd/test-java01/cpu-0/cpu-user.wsp 3s:30m,1m:1d,5m:2y –xFilesFactor=0.1

The above works fine, but this is the other way to configure how many metrics Graphite can keep. It has the format n:i, which means we store a measure every n seconds and we want i points to be stored (computed with interval / n).

Example: 3s:30m
30m = 1800s
1800 / 3 = 600

3:600

So 3s:30m,1m:1d,5m:2y gives us 3:600 60:1440 300:210380.

« An average Gregorian year is 365.2425 days = 52.1775 weeks = 8765.82 hours = 525949.2 minutes = 31556952 seconds (mean solar, not SI). » Wikipedia

Note

Thing to remember concerning storage-schemas.conf (taken from Graphite doc):

« Changing this file will not affect already-created .wsp files. Use whisper-resize.py to change those. »

Déterminer l’emplacement des sources de Django

Voici comment déterminer l’emplacement des sources de Django :

$ python
>>>import django
>>> django
<module 'django' from '/usr/lib/python2.7/dist-packages/django/__init__.pyc'>

Le chemin vers Django est donc

/usr/lib/python2.7/dist-packages/django/

Autre possibilité plus rapide :

python -c "
import sys
sys.path = sys.path[1:]
import django
print(django.__path__)"

Qui nous donne

['/usr/lib/python2.7/dist-packages/django']

Graphite: Vérifier la réception de données

Une commande bien utile pour vérifier ce qui transite sur une interface réseau pour un port donné. Par exemple, pour vérifier l’envoi de paquet depuis Riemann vers Graphite en local (interface lo et port 2003):

ngrep port 2003 -d lo

Qui nous donne le résultat suivant:

interface: lo (127.0.0.0/255.0.0.0)
filter: (ip or ip6) and ( port 2003 )
#
T 127.0.0.1:33936 -> 127.0.0.1:2003 [AP]
 test 1.4 1401805746. 
##
T 127.0.0.1:33935 -> 127.0.0.1:2003 [AP]
 test 1.0 1401805747.

Les messages arrivent jusqu’à Graphite et utilisent le bon format, donc pas de problème du côté de l’envoi.

[POC] Puppet master-agent avec Docker

Petit Proof of Concept réalisé la semaine dernière autour des technologies Puppet et Docker. L’idée consiste à utiliser Docker pour pouvoir facilement déployer un environnement master-slave Puppet et avoir ainsi la possibilité de tester ses scripts de déploiement ou plus généralement, d’étudier et de comprendre le fonctionnement de Puppet avant de passer à une utilisation en production.

Le projet permet donc la création de deux containers Docker, l’un contenant le master et l’autre l’agent. Après création du container master, on peut créer l’agent et lier les deux containers à l’aide du paramètre -link de Docker. On permet ainsi aux deux containers de communiquer entre eux sans avoir à essayer de déterminer leur IP respective à la main. Par la suite, après signature du certificat de l’agent par le master, la configuration décrite dans le fichier site.pp sous le nœud agent pourra être mise en place sur celui-ci.

node  'agent' {
  class { 'apache': }
}

Par exemple, on installe ici apache dans le container de l’agent.

Mes différents tests m’ont également permis d’identifier certains limitations au niveau de Docker:

  • Impossible de modifier le fichier /etc/hosts au sein d’un container.
  • Impossible de modifier les paramètres ulimit dans un container.

Le code est bien sûr disponible disponible sous licence libre sur Github: vvision/docker-puppet-master-agent.

C4ptch@

De temps à autre, il m’arrive de regarder un peu sous le capot des sites web que je visite, de plonger dans le code pour m’intéresser à l’un ou l’autre composant du site. Dernièrement, j’ai donc été attiré par la partie captcha de l’un d’eux.

captchaDès le premier coup d’œil, je pressens une faille. Quelques actualisations de page plus tard, ma première impression se confirme, le nom donné aux images représentant les différents chiffres du captcha ne changent pas. Il suffit donc d’établir la correspondance entre nom d’image et chiffre et nous devenons capable de déterminer le captcha automatiquement.

En regardant d’un peu plus près l’identifiant de chaque image, je m’aperçois également que celui-ci fait 32 caractères de long. Résumons: 32 caractères, lettres minuscules de a à z et chiffres de 0 à 9. Qui a dit md5? Un petit test pour s’en convaincre. L’image correspondant au 0 a pour identifiant cfcd208495d565ef66e7dff9f98764da, ce qui correspond bien au hash md5 de 0.

Cette constatation m’a donc fait réfléchir à la question suivante: si il est possible de casser un captcha en apprenant la règle spécifique à un programme, ce mécanisme de captcha est-il toujours valable, au sens où il a fallu une intervention humaine pour écrire la règle?

Revenons donc sur la définition d’un captcha par Wikipédia: « A CAPTCHA (an acronym for « Completely Automated Public Turing test to tell Computers and Humans Apart ») is a type of challenge-response test used in computing to determine whether or not the user is human. ». On y apprend qu’un captcha doit permettre de déterminer si un utilisateur est humain ou non. Donc, le mécanisme de captcha étudié n’est pas valable, puisqu’un programme relativement simple est capable de résoudre le défi. Bien entendu, il aura fallu qu’un humain écrive la façon de résoudre ce captcha en particulier (,mais après tout, il y a un humain derrière chaque ligne de code). De plus, on peut très bien écrire un programme capable de reconnaître lorsqu’un site utilise ce type de captcha et ainsi s’affranchir d’une intervention humaine pour chaque site utilisant ce mécanisme de captcha.

Pour terminer, j’ai continué mes recherches et avec les bons mot-clés, j’ai donc constaté que ce type de captcha utilisant un hash md5 comme identifiant d’image se retrouve sur quelques sites mais ne semble pas être trop répandu. On peut néanmoins déplorer que la page sur laquelle j’ai découvert ce captcha soit celle de contact d’une commune française de taille moyenne.