[PYTHON] Commencez avec influxDB + Grafana

Contexte

J'ai toujours utilisé Elasticsearch comme outil de visualisation, mais si vous souhaitez enregistrer des données numériques telles que des données de métriques de serveur, essayez également influxDB.

Vue d'ensemble de influxDB + Grafana

influxDB

influxDB est classé dans un logiciel appelé base de données de séries chronologiques (base de données de séries chronologiques). Comme son nom l'indique, la base de données de séries chronologiques est une base de données qui dispose d'un mécanisme pour stocker des données qui changent avec le temps. [Il existe une page d'article dans la version anglaise de Wikipedia](https://en.wikipedia.org/ wiki / Time_series_database) dit que RRDTool est également une base de données de séries chronologiques.

Compte tenu de la comparaison avec RRDTool, les fonctionnalités d'influxDB sont les suivantes.

• L'enregistrement des données est possible avec json via l'API REST.
• Equipé d'un mécanisme d'authentification par défaut.
• Les requêtes peuvent utiliser une syntaxe basée sur SQL.
• Équipé d'une interface utilisateur Web, vous pouvez vérifier les résultats de la requête de manière interactive avec l'interface graphique.

Grafana

Grafana est un outil de tableau de bord dérivé de Kibana, mais il n'est pas spécialisé pour influxDB et peut être lié à Graphite et CloudWatch. Cela a également un mécanisme d'authentification par défaut.

procédure

Démarrez influxDB et Grafana

Comme c'est rapide, j'ai lancé l'image officielle Docker avec Docker Compose.

** Addendum du 22/12/2016: ** Ajout de la description du volume de données aux paramètres du conteneur de Grafana. Parce qu'il était nécessaire de sauvegarder le répertoire sqlite afin de conserver le tableau de bord de Grafana, les paramètres utilisateur, etc. Il est possible d'enregistrer les paramètres du tableau de bord, etc. dans une base de données externe telle que MySQL, mais par souci de simplification, j'ai décidé d'utiliser sqlite, qui est préparé par défaut cette fois. (Référence: Grafana --Configuration)

docker-compose.yml

version: "2"

services:
  influxdb:
    image: influxdb
    ports:
      - "8083:8083"
      - "8086:8086"
    volumes:
      - /tmp/influxdb:/var/lib/influxdb

  grafana:
    image: grafana/grafana
    ports:
      - "3000:3000"
    volumes:
      - /tmp/grafana:/var/lib/grafana

Parmi les deux ports ouverts dans influxDB, «8083» est l'interface utilisateur Web et «8086» est le point de terminaison de l'API REST. De plus, comme les données sont enregistrées dans / var / lib / influxdb, elles sont synchronisées avec le système d'exploitation hôte en tant que volume de données.

Grafana ouvre simplement un port pour l'interface utilisateur Web. Dans le cas de Kibana, la connexion avec Elasticsearch a été définie dans kibana.yml, mais comme Grafana établit la connexion avec la base de données sur l'interface utilisateur Web, il n'est pas nécessaire de considérer le fichier de configuration, etc. à ce stade.

connexion entre influxDB et Grafana

Accédez à http: // (Docker Host IP): 3000 à partir d'un navigateur Web, sélectionnez" Sources de données "dans l'icône en haut à gauche et sélectionnez` http: // (Docker Host IP): dans" Ajouter une source de données ". Connectez-vous au 8086 ».

Les paramètres initiaux de l'ID utilisateur et du mot de passe d'authentification sont root: root pour influxDB et admin: admin pour Grafana.

Données d'entrée dans influxDB

J'ai utilisé Python cette fois, mais avant cela, je parlerai de la structure d'influxDB.

structure de influxDB

• Base de données: la plus grande unité de données, similaire à la base de données du SGBDR. La base de données doit être créée avant la saisie des données.
• Measurement: La position de la table dans le SGBDR.
• Politique de rétention: Une politique de conservation des données composée de DURATION, qui définit la période de conservation des données, et de REPLICATION, qui définit le nombre de copies de données conservées dans le cluster influxDB. Fondamentalement, il est utilisé sous la forme d'être lié à Database.

Je ne l'ai pas utilisé correctement parce que je l'ai encore essayé, mais ce serait bien d'avoir une politique de rétention. Il est possible de stocker des données illimitées pour éviter le cas de débordement de capacité et pour assurer la disponibilité.

structure de données de influxDB

Avec Elasticsearch, si vous insérez correctement json, vous pouvez déjà l'utiliser, vous pouvez donc utiliser l'opération Zubora comme lancer json obtenu à partir de l'API tel quel, mais dans le cas d'influxDB, la structure de données à inclure dans json est décidée.

• mesure: spécifiez dans quelle mesure importer.
• fields: Spécifiez les soi-disant données elles-mêmes sous la forme d'une valeur clé. La clé est limitée au type chaîne, mais la valeur prend en charge float, integer et boolean en plus de la chaîne. Il est également possible d'inclure plusieurs «champs».
• tags: spécifiez des données facultatives. Par exemple, si vous entrez des données de métriques de serveur, le nom du serveur est «tags». Vous pouvez en inclure plusieurs ici, mais notez que seul le type chaîne est pris en charge.
• timestamp: horodatage des données. La partie essentielle des données chronologiques. S'il n'est pas spécifié, l'heure à laquelle le processus d'entrée a été effectué sera appliquée automatiquement. InfluxDB prend uniquement en charge * UTC. *

Il semble y avoir une utilisation arbitraire des «champs» et des «tags», mais la grande différence est que «fields» n'est pas indexé, mais «tags» est indexé. Ainsi, par exemple, vous pouvez utiliser la clause GROUP BY lors de la requête, mais ici nous utilisons les balises. Les métadonnées utilisées pour la recherche, etc. doivent être des «balises», et les données qui changent au fil du temps doivent être supprimées en tant que «champs». Je ne demande généralement pas de changement de données, par exemple lorsque l'utilisation du processeur est de 80%, il est donc compréhensible que fields ne soit pas indexé.

Traitement des entrées de données

Je vais brièvement montrer la source.

from influxdb import InfluxDBClient

client = InfluxDBClient('127.0.0.1', 8086, 'root', 'root', 'sample')

#Juger de l'existence de la base de données et en créer une nouvelle avant la création
dbs = client.get_list_database()
sample_db = {'name' : 'sample'}
if sample_db not in dbs:
    client.create_database('sample')

#Créer des données JSON à importer
import_array = [
{
  "fields" : {
    "cpu" : 50.0,
    "mem" : 20.0,
  },
  "tags" : {
    "category" : "fuga",
    "machine" : "web02"
  },
  "measurement" : "metrics"
}
]

#Entrée de données
client.write_points(import_array)

c'est simple. «Le mot de passe est écrit directement dans InfluxDB Client», mais le codage en dur doit être arrêté pendant cette opération. En ce qui concerne les données json, comme je l'ai écrit plus tôt, j'essaye de mettre plusieurs «champs» et «balises». Vous pouvez maintenant dessiner un graphique pour chaque machine.

Visualisation avec Grafana

Puisqu'il s'agit d'une opération avec GUI, les détails sont omis, mais ils seront visualisés en organisant des parties appelées Panel sur le tableau de bord comme Kibana. En plus de Graph, Panel a également une statistique unique qui ne peut afficher que la dernière valeur en grand nombre, du texte qui vous permet d'écrire des phrases avec Markdown, etc., et a un haut degré de liberté.

De plus, lors de la spécification des données à afficher dans Graph, etc., elles sont définies avec une instruction SQL.Par conséquent, même si cela est facile à comprendre, il est nécessaire de maintenir enfoncée la manière d'utiliser l'instruction SQL dans influxDB. Cependant, puisque vous pouvez créer du SQL en cliquant sur les candidats sur l'interface graphique et en les combinant, même une compréhension légèrement vague peut être très bonne. C'est très facile.

Convivialité, par rapport à ES + Kibana

Quand j'ai imaginé la convivialité d'Elasticsearch + Kibana, j'étais confus par le fait que la clé json qui doit être définie lors de la saisie était définie, et que l'égoïsme était différent (plutôt, si c'était json, je pourrais chercher n'importe quoi. Le SE qui peut être créé est Dieu), et le sentiment d'utilisation est le même en ce sens qu'il est "facile de visualiser les données" et que c'est facile à voir. Sera-t-il en concurrence avec Elasticsearch dans un premier temps? J'ai pensé, mais maintenant je comprends que ce sont des outils avec des gammes défensives distinctes.

• influxDB: littéralement des données chronologiques, spécialisées dans la visualisation des changements de valeurs qui "changent" au fil du temps. Vous pouvez saisir une chaîne de caractères dans les champs, mais elle ne convient pas à la recherche car elle n'est pas indexée.
• Elasticsearch: j'ai oublié parce que la visualisation et le dessin graphique avec Kibana sont pratiques, mais c'est un "moteur de recherche plein texte". Cliquez ici si vous souhaitez effectuer une recherche à partir d'une grande quantité de données de chaîne de caractères d'entrée.

Par exemple, lorsque vous utilisez MySQL, Elasticsearch convient si vous souhaitez collecter des journaux de requêtes lentes pendant une longue période et les analyser, et Elasticsearch est également possible si vous souhaitez surveiller le volume de trafic, mais en tant que ségrégation, influxDB Il semble que.