Telegraf

El destino Telegraf envía los puntos de ghchronicle a Telegraf, que puede reenviarlos a cualquiera de las salidas que Telegraf soporta.

sinks:
  telegraf:
    url: http://telegraf:8186/telegraf
    username: ""
    password: ""
    batch: 5000

Line protocol enviado a la entrada http_listener_v2 de Telegraf, como text/plain, con autenticación básica cuando hay un usuario puesto.

Una URL sin ruta recibe /telegraf

El listener responde 404 a / sin decir por qué, así que a una URL con ruta vacía se le pone la ruta por omisión de la entrada en vez de mandarla a un sitio que fallará en silencio.

La entrada correspondiente

[[inputs.http_listener_v2]]
  service_address = ":8186"
  paths = ["/telegraf"]
  data_format = "influx"

Por qué existe como un solo destino

Telegraf tiene una salida para Kafka, Datadog, New Relic, Graphite, Loki, Elasticsearch, Wavefront, Azure Monitor, Google Cloud Monitoring y otras cien. En vez de hacer crecer aquí un destino por cada una, los puntos van a Telegraf como el line protocol que ya habla, y sus propios bloques [[outputs.*]] los encaminan.

Ese es todo el argumento. Es un destino que alcanza todo lo que alcanza Telegraf, y no le cuesta a este proyecto ninguna dependencia nueva ni ningún formato de cable nuevo.

Qué pasa con las fechas

Telegraf conserva las marcas de tiempo tal como se las dan, así que la historia fechada sobrevive hasta donde permita cada salida. Una salida que sella al recibir, o una que rechaza muestras viejas, la pierde, exactamente igual que harían esos backends si esta herramienta les escribiera directamente.

Así que la pregunta no es “¿conserva Telegraf la historia?” sino “¿la conserva la salida que he configurado?”. Kafka e InfluxDB sí. Un remote write de Prometheus no.

Un ejemplo que reparte

[[inputs.http_listener_v2]]
  service_address = ":8186"
  paths = ["/telegraf"]
  data_format = "influx"

[[outputs.influxdb_v2]]
  urls = ["http://influxdb:8181"]
  token = "$INFLUX_TOKEN"
  organization = "default"
  bucket = "github"

[[outputs.kafka]]
  brokers = ["kafka:9092"]
  topic = "github-metrics"

Una pasada, dos destinos, y el colector no sabe de ninguno de los dos.

Qué hace aquí una migración

ghchronicle no ve el almacén que hay detrás de Telegraf, así que lo que una versión dejó allí con otra forma lo decide el registro del fichero de estado de la versión que lo escribió primero. Aplicar el cambio es que -migrate -yes diga qué hacer allí, borrar la medida en ese almacén y después volver a leer las familias que la escriben a través de Telegraf con un relleno histórico de esas familias solas, -backfill -families, y lo registre como aplicado. Un arranque nunca lo aplica por su cuenta, y a Telegraf no se le envía nada: la relectura que sigue a una migración solo escribe en los almacenes que ghchronicle vació por sí mismo, y un Telegraf que escribe en un fichero guardaría cada fila de ella dos veces.

Por dónde seguir

• Elegir almacén compara Telegraf con los demás, y lleva el registro de escrituras que todos comparten.
• Los dashboards dice cuál de los cinco se dibuja contra cada almacén, y en qué se convierte un panel que un almacén no puede responder.