Ir al contenido

Telegraf

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.

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

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.

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.

[[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.

  • Elegir almacén compara Telegraf con los otros nueve, 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.