ну да, но иногда может бы было интересно глянуть, у нас тут просто недавно было любопытное, клиент на OpenVZ виртуалки делал LA за 100 влёгкую, почти не дёргая диск и сеть один

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

> в collectd есть какой то схоже называемый плагин, но по нему ни доки, да и в инфлюкс с графаной он что то вроде не то шлёт, ну или это там надо как то хитро считать. Это какой плагин? Там collectd надо рассказать что куда слать

Но ввобще не все ли равно? Ну упираешься ты не в сам процессор, а в скорость памяти?

в 99% случаев однохренственно. Но с точки зрения перформанс инженера конечно разные вещи

а, нашел, intel_rdt плагин. Должен слать, если железо / ядро отдает

> в collectd есть какой то схоже называемый плагин, но по нему ни доки, да и в инфлюкс с графаной он что то вроде не то шлёт, ну или это там надо как то хитро считать. Это какой плагин? Там collectd надо рассказать что куда слать

ну по названию похоже на LoadPlugin ipc

не, intel_rdt

эх, чего то в чуть не свежую бубунту они его не завезли наверное ещё

да, titptop этот тоже требует libpapi, который только в трасти и выше.

ну tiptop пщказывает, а коллектд из ихних апстриам реп что то не хочет заводится с этим плагином, ладно попозже гляну

Мне кажется, кейс для IPC - это оптимизация приложения. Это больше для разработчиков, чем для общего мониторинга.

Соглашусь в целом. Если софт пишется не самими то IPC можно мониторить наравне с температурой на поверхности Марса. На базах данных зачастую можно видеть очень низкий IPC (но что с этим поделать это задача БД ждать данных из памяти).

Если нагрузка самописная то IPCями можно тыкать в разработчиков. Это как минимум кейс для возможной оптимизации приложения.

Господа, а тут есть еще страдальцы с influxdb ? Давайте подумаем как подбирать оптимальный размер шарда ?

ты уточни требования, а то напридумывают всякого, а поди хайлоад какой :) вот у меня в него срёт три калеки и никаких страданий вроде

требования 40м кардиналити 75к метрик в секунду

дефолтный размер шарда у них неделя.

тоесть полный компакт будет раз в неделю.

я сейчас ставлю дневной шард. компакт фулл раз в сутки.. длится примерно 6 часов.

чот я думаю надо бы его еще уменьшить

не понимаю как это скажется на производительности

на опыте эластика должно быть хорошо.

А вынести куда нибудь на SSD не вариант, нынче модно и много где спасает вроде

но это как бы совсем разные базы

А вынести куда нибудь на SSD не вариант, нынче модно и много где спасает вроде

а у меня и так all flash система под ним

быстрее только в память писать

или блочный девайс по имени /dev/null

но это как бы совсем разные базы

А может делать экспорт архивных данных в другую БД (тоже influxdb)?

стока iops не бывает. кстати места тоже

впрочем я так делаю. :)

но не совсем.

у меня две базы. одна короткая для запросов оперативных. вторая долгая. для типа аналитики

понятно, да простые костыли уже сделаны :)

да вот я и пошел смотретьварианты которые еще н етыкал.

а не тыкал я как раз размер шарда

https://www.usenix.org/conference/fast16/technical-sessions/presentation/andersen Кто нибудь пробовал/смотрел на такого зверя? Описано красиво, для простых числовых метрик вроде как самое то. Решение не коробочное, конечно, но что-то в этом есть... Интересно бы это с КХ сравнить и графану прикрутить.

а не тыкал я как раз размер шарда

для меня пока что это вообще тёмный пока что

https://docs.influxdata.com/influxdb/v1.2/concepts/storage_engine/

Что-то influx стала доставать своей непредсказуемостью и их непонятной логикой развития. До какого-то момента было приемлемо (по ~20М серий), а потом бац! И приехали. В какой мере КХ можно как альтернативу рассматривать? Что приобрету/потеряю? Текущий основой объём данных - netflow c несколькими схемами агрегации. Задач две - оператиные картинки за последние часы-сутки и аналитика/тренды за год-два. Ну и с разных legacy RRD хочется слезть в перспективе для других данных.

grafana/grafana: v4.3.0 was tagged

grafana/grafana: v4.3.0 was tagged

Это уже не бета?

Кликхауз мы будем втыкать вместо influx (тоже достал своими приколами) и не в варианте graphouse, а в полноценном виде "а ля influx". ETA пока не спрашивайте, рано )) По последним нашим тестам кликхауз рвет инфлюкс раза в 4, про стабильность вообще молчу

https://github.com/influxdata/influxdb/blob/master/CHANGELOG.md последний релиз 1,2,2. но уже есть 1,2,4

Кликхауз мы будем втыкать вместо influx (тоже достал своими приколами) и не в варианте graphouse, а в полноценном виде "а ля influx". ETA пока не спрашивайте, рано )) По последним нашим тестам кликхауз рвет инфлюкс раза в 4, про стабильность вообще молчу

в 4 ?

Кликхауз мы будем втыкать вместо influx (тоже достал своими приколами) и не в варианте graphouse, а в полноценном виде "а ля influx". ETA пока не спрашивайте, рано )) По последним нашим тестам кликхауз рвет инфлюкс раза в 4, про стабильность вообще молчу

а вы это кто ? :)

Кликхауз мы будем втыкать вместо influx (тоже достал своими приколами) и не в варианте graphouse, а в полноценном виде "а ля influx". ETA пока не спрашивайте, рано )) По последним нашим тестам кликхауз рвет инфлюкс раза в 4, про стабильность вообще молчу

4 - это в каких попугаях? Память? Объём на диске? IOPS? CPU?

4 - это в каких попугаях? Память? Объём на диске? IOPS? CPU?

а там можно в любых.

просто 4 слишком мало. даже для "в".

https://www.usenix.org/conference/fast16/technical-sessions/presentation/andersen Кто нибудь пробовал/смотрел на такого зверя? Описано красиво, для простых числовых метрик вроде как самое то. Решение не коробочное, конечно, но что-то в этом есть... Интересно бы это с КХ сравнить и графану прикрутить.

Туда можно писать только batch-ами, иначе все будет очень плохо. Там нет тегов и даже иерархии как в графите, есть id-шники метрик и все. В принципе, (shameless plug) в Akumuli (https://github.com/akumuli/Akumuli) хранилище очень похожим образом работает, но не имеет перечисленных недостатков.

В 4 по памяти, инфлюкс любит ее очень, проц чуток поменьше, iops та вообще на порядок вроде

Мы - маленькая команда, которая пилит свой уютненьний мониторинг на основе grafana + clickhouse + telegraf ))

Мы - маленькая команда, которая пилит свой уютненьний мониторинг на основе grafana + clickhouse + telegraf ))

ок. велкам ту чёрч.

Мы - маленькая команда, которая пилит свой уютненьний мониторинг на основе grafana + clickhouse + telegraf ))

Хм... телеграф, а почему? там поговаривают многое вообще внешними компонентами дёргается это не бяка?

Хм... телеграф, а почему? там поговаривают многое вообще внешними компонентами дёргается это не бяка?

телеграф ок.

То что у него внешнее - да, бяка, то что свое плагинами - весьма ок

телеграф сука бажная пиздец

телеграф сука бажная пиздец

есть чо почитать ?

кроме трекера

https://github.com/influxdata/telegraf/issues

у нас ребята девелоперы в него закопались

фиксят что-то

давать ссылку на трекер моветон.

А кто-то копал в сторону КХ в качестве сторейджа для прома?

А кто-то копал в сторону КХ в качестве сторейджа для прома?

плюсую вопрос :)

ERROR: S client not available

Мы - маленькая команда, которая пилит свой уютненьний мониторинг на основе grafana + clickhouse + telegraf ))

Какие-то оценки по юзабилити и аппаратным требованиям связки grafana-clickhouse для числа серий (в терминах influx) ~50-100M существуют? Телеграф неоднозначное впечатление оставляет, концепт вроде норм (и kapacitor - тоже), а некоторые куски под травкой, наверное, делались ? snmp plugin - вообще шедевр ?.

@yuyugame 50-100М кардиналити ?

то что они зовут numSeries ?

Ну да. 50-100 - это "на вырост", пока ~30M/. "Готовить" легко - навешиваются теги на routerID/srcAS/dstAS/in/outInterface/etc - и готово. ? Хотелось бы и больше навесить, но инвалид и это с трудом переваривает.

какое железо под это дело?

kapacitor на первый взгляд выглядит как riemann

Это уже не бета?

Вроде да

Кликхауз мы будем втыкать вместо influx (тоже достал своими приколами) и не в варианте graphouse, а в полноценном виде "а ля influx". ETA пока не спрашивайте, рано )) По последним нашим тестам кликхауз рвет инфлюкс раза в 4, про стабильность вообще молчу

Если будете делать в опенсорсе и не на джаве то можно даже попытаться объединить усилия

4.3.0-stable (2017-05-23)

Если будете делать в опенсорсе и не на джаве то можно даже попытаться объединить усилия

В опенсорсе, на go ))

вопрос , если node_exporter ставить на target хосты, надо на этих хостах ограничивать доступ к /metrics через nginx, кто как делает?

4.3.0-stable (2017-05-23)

SQL datasource там можно уже юзать? Или сыро?

вопрос , если node_exporter ставить на target хосты, надо на этих хостах ограничивать доступ к /metrics через nginx, кто как делает?

почему iptables/nft не хватает?

есть чо почитать ?

бажная бажная пытался прикрутить к ней сборку по процессам метрички, с бриджем в пром, умирает в рандомное время в течении 8 часов

нам пришлось ставить рестарт в крон

как-то можно жить

нам пришлось ставить рестарт в крон

у меня так сейчас, кхе кхе, jmx-exporter работает^W не работает

мы его не пробовали

у нас мало жавы

а чо, он "ниочень"?

а чо, он "ниочень"?

ну как сказать, если ты решил "подебажить", "потрейсить" приложение и хочешь данные по всему вообще, то jmx-exporter наверное плохое решение

память течет, долгий, проц жрёт как не в себя

но, я его не как агент, а как java -jar запускаю

как агент работает нормально, но я не дебажу, а собираю данные по GC и использованию cpu

если начать собирать больше ~200 метрик, начинает жрать проц и течь по памяти, да

если начать собирать больше ~200 метрик, начинает жрать проц и течь по памяти, да

собственно что я и нашёл :)

ну, я из-за этого фильтрую не нужные метрики, а то на 1к метрик, он тек по ~600mb в день

хоть джаву учи, для устранения меморилика

хоть джаву учи, для устранения меморилика

тебе нужно что-то выдернуть по JMX из работающего приложения?

Можно питоном и JPyPe (http://jpype.sourceforge.net/) Полученные значения уже обрабатываются на раз и в графит/куда-нить ещё отправляются

да, как вариант написать свой экспортер на питоне

спасибо, я подумаю