La cardinalidad es la combinación del número de medidas (Measurements), tags, sets, campos (Fields) y valores (Values) y cuando hablamos en especifico de una base de datos de tiempo temporal como puede ser InfluxDB, Prometheus, TimeScale, etc, tener una alta cardinalidad puede ser todo un desafío.
Hay casos, que debido a la naturaleza del negocio, se debe guardar toda la información y no hay nada que hacer al respecto, pero hay otros escenarios, sobre todo cuando hablamos de monitoreo de nuestra infraestructura en donde podríamos implementar ciertas acciones que nos permitan contar con la información que necesitamos y de esta manera contribuir a mantener bajo control la cardinalidad.
Con esto no estoy diciendo que debemos mandar la menor información posible sino, solo la que usaremos, consultaremos y visualizaremos en los dashboards u otros sistemas.
Déjenme contarles como, en mi caso, Telegraf me ayuda a filtrar y recolectar información sobre tres servidores que corro en DigitalOcean y que son los que mantienen este blog y otros servicios más sin necesidad de saturar a la base de datos con datos que no voy a consultar nunca.
Intervalo de recolección de datos.
Una de las cosas que hago para mantener baja la cardinalidad es aumentar el intervalo de recolección, por defecto, Telegraf recolecta cada 10 segundos, yo lo hago cada 120.
Y es que si lo piensan por un momento, al hacerlo, como viene por defecto, estaríamos duplicando nuestra cardinalidad cada 10 segundos y si bien InfluxDB u otras bases de datos de serie temporal, a esta altura, son escalables, lo recomendable es definir un intervalo de recolección realista en base a nuestras necesidades.
Por supuesto, va a ver casos en donde los SLA son los que mandan y cada segundo cuenta, pero en la mayoría de los casos y en base a mi experiencia trabajando con entornos productivos, recolectando cada 60 segundos es más que suficiente.
Dejénme compartirles mi configuración de Telegraf para que le demos una mirada a como yo uso esta funcionalidad.
Acá abajo pueden ver cómo la recolección y él flush hacia InfluxDB se hace cada 120 segundos.
[agent]
interval = "120s"
round_interval = true
metric_batch_size = 1000
metric_buffer_limit = 10000
collection_jitter = "0s"
flush_interval = "120s"
flush_jitter = "0s"
precision = ""
debug = false
quiet = false
logfile = ""
hostname = ""
omit_hostname = falseAjustando la recolección y el flush con los tiempos que necesitamos, es una manera de reducir o de mantener la cardinalidad baja en InfluxDB, pero no es la única, veamos la siguiente que es la más interesante.
Filtrando métricas
Filtrar métricas puede ser una excelente opción para mantener bajo control la cardinalidad y esto lo digo, pensando en el hecho de que hay determinados Inputs plugins de Telegraf que recolectan más de lo que eventualmente y dependiendo de cada caso, necesitamos.
Les quiero dar un ejemplo. Veamos los fields que trae el Input Plugin que recolecta información sobre la memoria del sistema:
active (integer, Darwin, FreeBSD, Linux, OpenBSD)
available (integer)
available_percent (float)
buffered (integer, FreeBSD, Linux)
cached (integer, FreeBSD, Linux, OpenBSD)
commit_limit (integer, Linux)
committed_as (integer, Linux)
dirty (integer, Linux)
free (integer, Darwin, FreeBSD, Linux, OpenBSD)
high_free (integer, Linux)
high_total (integer, Linux)
huge_pages_free (integer, Linux)
huge_page_size (integer, Linux)
huge_pages_total (integer, Linux)
inactive (integer, Darwin, FreeBSD, Linux, OpenBSD)
laundry (integer, FreeBSD)
low_free (integer, Linux)
low_total (integer, Linux)
mapped (integer, Linux)
page_tables (integer, Linux)
shared (integer, Linux)
slab (integer, Linux)
sreclaimable (integer, Linux)
sunreclaim (integer, Linux)
swap_cached (integer, Linux)
swap_free (integer, Linux)
swap_total (integer, Linux)
total (integer)
used (integer)
used_percent (float)
vmalloc_chunk (integer, Linux)
vmalloc_total (integer, Linux)
vmalloc_used (integer, Linux)
wired (integer, Darwin, FreeBSD, OpenBSD)
write_back (integer, Linux)
write_back_tmp (integer, Linux)Ahora bien, yo particularmente no necesito todas estás métricas, me interesa saber el porcentaje de uso de la memoria. En mi caso, solo agarro está.
used_percent (float)Por supuesto, de nuevo, mi caso de uso no es critico, es casi "amateur", pero de todos modos, creo, te puedo dar una idea de cómo recolectando las métricas que me interesan, usando filtrado, mantengo la cardinalidad bajo control.
Ahora, ¿cómo hago este filtrado?, bueno, muy sencillo, le paso un parámetro llamado "fieldpass" a cada input para, que de esta manera, solo mando a InfluxDB las métricas que considero necesarias para mi caso de uso:
[[inputs.cpu]]
percpu = true
totalcpu = true
collect_cpu_time = false
report_active = false
fieldpass = ["usage_guest", "usage_system", "usage_idle"]
[[inputs.disk]]
ignore_fs = ["tmpfs", "devtmpfs", "devfs", "overlay", "aufs", "squashfs"]
fieldpass = ["used, "free"]
[[inputs.diskio]]
fieldpass = ["read_bytes", "write_bytes", "read_time", "read_write", "read", "writes"]
[[inputs.mem]]
fieldpass = ["used_percent"]
[[inputs.net]]
fieldpass = ["bytes_sent", "bytes_recv", "err_in", "err_out", "drop_in", "drop_out"]
[[inputs.processes]]
fieldpass = ["running", "zombie", "sleeping", "total"]
[[inputs.swap]]
fieldpass = ["total", "used", "free"]
[[inputs.system]]
fieldpass = ["load1", "load15", "load5", "uptime"]Si no me falló la cuenta, son 29 campos que traigo, si lo dejará todo por defecto, ese número sería 109, esto es poco más de 73%. Un número mas que importante.
Definiendo Politicas de Retención
Si bien, esto no es propio de Telegraf, la política de retención juega un papel importante.
Lo que hace esta política es decirle a la base de datos cuánto tiempo debe guardar la información, en mi caso particular, no necesito tener los datos más de 14 días, así que ajusto la RP de mis buckets/base de datos a ese tiempo.
Por supuesto, hay casos que por políticas de la organización o gubernamental la información se debe guardar durante más tiempo, así que ahí es cuestión de ajustarlo de acuerdo a tus necesidades, pero acá lo que te aconsejo es que se defina una política de retención real y no caer en el hecho de guardar por siempre información que nunca más vamos a consultar por el solo hecho de poder hacerlo.
Para ir cerrando
Como ves, con algunos simples ajustes en nuestro collector, en este caso, Telegraf, podemos mantener controlada la cardinalidad en nuestra base de datos. La base de datos te lo va a agradecer y vos mismo lo harás cuando veas lo rápidas que serán tus queries para visualizar información sobre tu parque de servidores y servicios.
Si tienes alguna duda o consulta sobre este tópico, no dudes en dejar un comentario aquí abajo.
