Использование InfluxDB для мониторинга систем хранения данных

[korsetlr473]

как они перешли на v2 языка - это просто ужас , оконная агрегация на SQL v1 теперь пишется в 40 строк сложного v2 синтаксиса ..... это ужас.

[oCeHb]

Как они писали "у нас очень простой функциональный стиль написания запросов", как-то после этого не захотелось что-то с ними продолжать. Я в итоге использую clickhouse, куда всё загружается питоновским скриптом. Держит большую нагрузку и не требует много ресурсов.

[valyala]

Советую попробовать VictoriaMetrics. Она потребляет до 10 раз меньше памяти по сравнению с InfluxDB при работе с большим количеством активных рядов - см. соответствующий бенчмарк. Она поддерживает намного более вменяемый язык запросов для временных рядов по сравнению с InfluxQL и Flux - он называется MetricsQL, и является обратно-совместимым с PromQL - языком запросов в Prometheus. Также VictoriaMetrics не использует экстраполяцию при подсчете increase() и rate(), в отличие от Prometheus. Это значит, что результаты вычислений будут всегда точными. См. соответствующую статью.

[chemtech]

Вот пост на хабре про Гнев, торг и депрессия при работе с InfluxDB

Вот бенчмарки сравнения с VictoriaMetrics:

• When size matters — benchmarking VictoriaMetrics vs Timescale and InfluxDB

• High-cardinality TSDB benchmarks: VictoriaMetrics vs TimescaleDB vs InfluxDB

• Insert benchmarks with inch: InfluxDB vs VictoriaMetrics

• First look at performance comparison between InfluxDB IOx and VictoriaMetrics

Неполный список проблем InfluxDB на момент версии 1.7:

• Хороший доклад со списком косяков и решений для них от августа 2020 -> https://youtu.be/-3dDD4KmCAM

• Стабильность. Периодически падает и теряет данные или ломает данные на диске. В последнем случае не может подняться или не может сделать компакшен, от чего количество открытых файлов улетает в космос. Лечится полной остановкой DB и выполнением команд в надежде, что хоть одна поможет.

• Скорость. Заявленное в маркетинговых бумажках касается не постоянного рейта, а спайков.

• Не работают внутренние лимиты на запросы вида SHOW TAG KEYS FROM ALL или SHOW EXACT SERIES CARDINALITY и на средней базе может положить все.

• Потребление ресурсов. Сожрать 256ГБ RAM, закусить 320GB свопа и все равно упасть по OOMу -- легко (в момент 6-ти часового запуска, который обусловлен тем, что при старте он читает с диска все индексы в память(InMem)).

• Платная кластеризация (была представлена как часть OSS в версии 0.9 (December 8, 2014) и исчезла в 1.0 (September 26, 2014), став привилегией Enterprise версии).

• Частые breaking changes. За 3 года сменили 5+ движков (закончили это делать на версии 0.9 (December 8, 2014)). Следующий Breaking Changes - это Influx 2.0, где они ушли от База Данных\Ретеншн полиси в сторону Buckets, поменяли язык запросов на Flux.

• Периодически выкатывают фичи непонятно зачем сделанные, например сделали ifql (Flux) или Continuous Queries (последние выпилили в пользу task, по факту те же яйца только с Flux-ом) или Chronograf(буква C в TICK), при живой то графане.

• Безалаберность при подготовке релизов.

• Не самосогласованные утилиты экспорта и импорта из базы - если вы что-то экспортировали через cli, то импортировать обратно файлик не прокатит. restore из backup полностью заменяет всю метаинформацию о базах. Селективности и merge не завезли.

• Телеграф как часть платформы TICK(буква T), например, они ломали поддержку Прометея в телеграфе 1.3.2 (замена символов не попадающих под [a-z]). Или, например, невозможность оверрайдить Retention Policy в (input,output).kafka, т.е. организовать полноценную связку metrics -> telegraf -> kafka -> telegraf -> influx у вас не получится.

• Капаситор(бука K в TICK), очень неадекватно себя ведет, подстать InfluxDB. Выжирает RAM как не в себя, может говорить, что всё "ок", когда данных нет. Требует нежного обращения и ухода.