Creando un sistema de visualización de series temporales IV: Conceptos básicos de InfluxDB

Conceptos básicos de InfluxDB

Par ver los diferentes conceptos relacionados con InfluxDB, vamos a partir de una posible tabla con los datos de consumo de cpu y memoria de dos servidores ESXi.

Esta tabla está en una base de datos de nombre “vmware” y le asignamos el nombre de “host_performance”

time cpu_usage mem_usage host cluster
2016-10-23T00:00:00Z 10 60 esxi01.localdomain.local cluster01
2016-10-23T00:00:00Z 30 70 esxi02.localdomain.local cluster01
2016-10-23T00:00:00Z 50 85 esxi03.localdomain.local cluster02
2016-10-23T00:00:00Z 40 80 esxi04.localdomain.local cluster02
2016-10-23T01:00:00Z 20 75 esxi01.localdomain.local cluster01
2016-10-23T01:00:00Z 35 65 esxi02.localdomain.local cluster01
2016-10-23T01:00:00Z 55 70 esxi03.localdomain.local cluster02
2016-10-23T01:00:00Z 40 80 esxi04.localdomain.local cluster02
2016-10-23T02:00:00Z 35 80 esxi01.localdomain.local cluster01
2016-10-23T02:00:00Z 45 60 esxi02.localdomain.local cluster01
2016-10-23T02:00:00Z 55 75 esxi03.localdomain.local cluster02
2016-10-23T02:00:00Z 30 80 esxi04.localdomain.local cluster02

Conceptos

Vamos a ver los conceptos y elementos clave asociados a los datos anteriores:

  • Database: es el contenedor lógico que contiene series temporales, usuarios, políticas de retención…
  • Measurement: es la estructura en la que se almacenan los datos. En el ejemplo anterior sería la tabla “host_performance”
  • Timestamp: todo dato almacenado en InfluxDB tiene asociado la fecha y hora. InfluxDB almacena la fecha en formato UTC siguiendo el RFC3339. En el ejemplo anterior, el timestamp se indica en la columna “time”
  • Field: es el par clave-valor que almacena los valores de datos en InfluxDB y siempre están asociados a un timestamp. Son campos no indexados, y que pueden tener datos de tipo strings, floats, integers o booleans. Es obligatorio contar con Fields en nuestra infraestructura de datos. En el ejemplo anterior, “cpu_usage” y “mem_usage” son fields. Tenemos Field-keys (cpu_usage y mem_usage) y Field-values (10, 30, 50, 40 …)
  • Tags: es el par-clave-valor que almacena valores de metadatos.. Son campos indexados y almacenados como strings. Son opcionales en la infraestructura de datos. En el ejemplo anterior,  “host” y “cluster” son Tags. Tenemos Tags-keys (host y cluster) y Tags-values (esxi01.localdomain.local, esxi02.localdomain.local, cluster01…)
  • Point: es el conjunto de valores de fields y tags asociados a un timestamp. Podríamos asociarlo a un registro de la tabla.
  • Retention policy: describe durante cuanto tiempo mantiene InfluxDB los datos en su infraestructura, cuantas copias de los datos se guardan (en el caso de tener un cluster de InfluxDB) y el tiempo asociado a los shard groups. De forma automática, cuando se crea una base de datos, se crea la política “autogen” cuyos datos se guardan por tiempo infinito y con un factor de réplica de 1 y con 7 dias como duración de los shard group.
  • Shard: contiene los datos comprimidos y codificados que se guardan en un archivo del disco del servidor. Cada shard pertenece a un solo group shard. Cada shard contiene un grupo específico de series y todos los datos de una serie se almacenan en el mismo shard (archivo) según la duración establecida en la “retention policy”

visualizacionseriestemporales-05

Características de InfluxDB

Algunas de las características que definen InfluxDB son las siguientes:

  • Se asume que si se envía el mismo dato varias veces, es el mismo dato por lo que se aplica la política de resolución de conflictos (de forma resumida, si son exactamente los mismos datos de tags set, field set, timestamp, se sobreesciben los valores en field set con los datos del último Point) por lo que en ciertos casos, se pueden perder datos.
  • El borrado de datos es una situación extraña. Normalmente se borran datos antiguos. Se limita la funcionalidad de borrado para incrementar las de escritura y lectura
  • La actualización de datos también es una situación poco común, por lo que su funcionalidad está restringida.
  • La mayoría de los datos tienen timestamps recientes y se guardan en orden ascendente para mejorar el rendimiento.
  • La base de datos puede gestionar un gran volumen de lecturas y escrituras, priorizandolas sobre la vista de los datos.
  • No está soportado el uso de joins entre tablas

 

Line Protocol

Line Protocol es el formato de texto que utiliza InfluxDB para almacenar Points en la base de datos.

La sintaxis es la siguiente:

Siguiendo con el ejemplo de la tabla inicial vamos a ver el ejemplo para

Measurement

Indica el nombre del measurement donde se van a guardar los datos.

En el ejemplo anterior es

Tag set

Es un elemento opcional y representa los tags asociados a los datos. Los tags son separados por comas sin espacios y se indican en el formato

En el ejemplo anterior tenemos dos tags:

Por rendimiento, se recomienda indicar los tags ordenados.

Espacio en blanco I

Separa los campos measurement (y Tag set si existen) con Field set.

Field set

Los datos se indican en el formato:

En el ejemplo anterior:

Espacio en blanco II

Separa los campos Field set y timestamp.

Timestamp

Es un campo opcional, si no se especifica, InfluxDB utiliza el timestamp del servidor . Por defecto se utilzia timestamps con una precisión de nanosegundos, pero se puede utilizar microsegundos, milisegundos o segundos. Se recomienda utilizar la mayor medida que se ajuste a los datos.

En el ejemplo anterior

corresponde con la fecha 23/10/2016 0:00:00 en precisión de nanosegundos.

Nota: como ayuda para convertir timestamps en diferentes formatos podemos utilizar esta página: http://www.epochconverter.com

 

Una respuesta a “Creando un sistema de visualización de series temporales IV: Conceptos básicos de InfluxDB”

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.