Продолжая копать можно снимать с него метрики и смотреть на наполненность этого всего и как он себя ведёт.

https://github.com/influxdata/telegraf/tree/master/plugins/inputs/internal

Тож бывает полезно знать что приключается на тачках и почему метрики задерживаются

о! это хорошее дело.
@EKbfh

metric_batch_size = 1000
metric_buffer_limit = 10000

Это прям хорошо

но эта проблема есть и на хостах где почти нет метрик

типо только стандартные чтобы знать что хост в целом жив

только на одном хосте требовалось увеличение буферов, но там много докеров и всякого разного

попробуй запустить

telegraf -config /etc/telegraf/telegraf.com -config-directory /etc/telegraf/telegraf.d  --test

и посмотреть как быстро он инпуты опросит.

Или у тебя input.socket_listener какой нить и это не поможет?

10к - не хватило на 10с

Даа, включи логирование посмотри на что он ругается. Он может не успевать отправлять например и тут можно включить сжатие(gzip) на отправку, если доступно и увеличить батчсайз.

Метрики будут передаваться большЕй пачкой, и сжиматься лучше, так же это уменьшит общение по сети.

Остальное хз, надо смотреть что собирается, как собирается, сетевую доступность и так далее.

ну или вглубь лезть как Алексей предложил, ппроф и сборка тестового стенда
https://github.com/influxdata/telegraf/blob/master/docs/PROFILING.md

А в конфиге кликхауса в graphite-rollup не 10 сек минимальный precision?

Он хранит как положишь если не делать optimize

но при чтении из него (если через graphite-clickhouse) он будет стараться зароллапить, а то у графита иначе будет очень веселый график

Не сталкивался с проблемой неотправки метрик из Telegraf, но сталкивался с тем, что Graphite Listener (TCP) из InfluxDB при большом пакете входящих метрик не разбирает их.

Он не успевает уложиться, может ещё что-то. И метрики теряются. Диагностировать сложно, так как в отличии от InfluxDB http для gatling Graphite tcp нельзя включить логирование входящих запросов.

Решил для себя проблему уменьшением и упрощением правил разбора входящих метрик
[[graphite]]
templates=[...]

И стал меньше присылать метрик с большим количеством точек (тегов). Это положительно повлияло на скорость и стабильность разбора. Теперь 0% потерь

Зависимости от интервала отправки не наблюдал

Может эта информация пригодится @nshumshurova

Ну от инфлюкса сложно иное ожидать :)

Это хороший инструмент. Он мне помогает. Приносит пользу

Я бы в ситуации Натальи уменьшил пакет и упростил его структуру

У меня была такая структура пакетов. На уровне группировки 2 и выше (5 тегов и одно поле) терял до 10 % метрик при частоте отправки 1 в сек. При частоте 1 в 10 сек тоже терял, меньше уже. Совсем перестал терять отказавшись от "длинных" метрик

И может поможет - отказ от округления времени отправки до 30 сек.

[agent]
round_interval = false
flush_jitter = "10s"

Это разгрузит принимающий сервер от потока пакетов каждые 30 сек. Будет разброс.

🙏 спасибо