можно KeepLastValue() использовать если у вас время обновления даша быстрее чем метрики пишутся

ну и если это Null и дропов нет то можно с дисплей опциями поиграца, не рисовать null как 0 например

Кажется он прямо щас так рисуется

Мне не нужна ещё одна система мониторинга, задача достаточно маленькая из потока statsd метрик некоторые считать с интервалом минута, а другие за 5 секунд к примеру. Сейчас уже стоит Brubeck который считает за минуту и он не имеет такой логики, поэтому самое простое поставить перед ним udp-replicator и поднять на другом порту с настройкой агрегации за 5 секунд.

У нас в репе есть udp-dublicator, тоже на Rust. Но лучше заведи issue и мы попробуем в bioyino добавить возможность по разным паттернам, в разных интервалах метрики агрегировать

Хотя я бы прям из приложений в нужные порты писал, думаю что дублировать одно и тоже но с разной гранулярностью особо не имеет смысла.

Хотя я бы прям из приложений в нужные порты писал, думаю что дублировать одно и тоже но с разной гранулярностью особо не имеет смысла.

эта доп логика в приложении ихмо совсем лишняя, у нас кейс это например часть потока метрик смотреть с минимально возможным временем обновления (в идеале реал-тайм - но я таких дашбородов не видел для графаны) ну и хранить их тоже желательно отдельно, в carbon-ch это норм решается разными таблицами

эта доп логика в приложении ихмо совсем лишняя, у нас кейс это например часть потока метрик смотреть с минимально возможным временем обновления (в идеале реал-тайм - но я таких дашбородов не видел для графаны) ну и хранить их тоже желательно отдельно, в carbon-ch это норм решается разными таблицами

Ну так ведь тебе в любом случае эти метрики как-то в statsd отправлять то придётся, и адрес и порт агрегатора для этого приложения указывать надо. Там и укажи порт statsd с наименьшим интервалом. Потом те которые нужно с большей частотой просматривать обернётся в графите в summarize

эта доп логика в приложении ихмо совсем лишняя, у нас кейс это например часть потока метрик смотреть с минимально возможным временем обновления (в идеале реал-тайм - но я таких дашбородов не видел для графаны) ну и хранить их тоже желательно отдельно, в carbon-ch это норм решается разными таблицами

кул идея, мы такое хотим реализовать (однажды)

Ну так ведь тебе в любом случае эти метрики как-то в statsd отправлять то придётся, и адрес и порт агрегатора для этого приложения указывать надо. Там и укажи порт statsd с наименьшим интервалом. Потом те которые нужно с большей частотой просматривать обернётся в графите в summarize

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

Так я и говорю что не надо несколько, отправляй с наименьшим. В графите потом схлопнешь

тут возникает другая проблема что - нужно будет поправить n-е количество дашбордов + выктить релиз приложения

меньше контроля

Хоть посекундные агрегаты отправляй, если у тебя иветнов генерирующих эти метрики миллионы

тут возникает другая проблема что - нужно будет поправить n-е количество дашбордов + выктить релиз приложения

О каком объеме метрик мы сейчас говорим?

И как долго с такой детализацией ты планируешь хранить эти данные

Есть вариант все метрики из statsd писать сразу с наименьшим интервалом, и через сутки роллапить их в долгосрочное.

детализация в несколько секунд нужна по факту за несколько часов всего

У КХ по-моему минимальный срок жизни партиции это сутки.

Поэтому пару часов врятли прокатит

раньше вроде месяц был, пофиксили уже?

раньше вроде месяц был, пофиксили уже?

Теперь сутки

есть уже дневные партиции - да мы пользуемся

отлично

есть уже дневные партиции - да мы пользуемся

Так какой объем метрик на входе/выходе?

прямо сейчас поток метрик 10К в секунду , занимает около 300Гб в clickhouse на 4 серверах, время хранения почти год

в основном все минутные

Хм, а надо?

а надо где то на на 1% от всех метрик иметь очень частый интервал обновления и чтобы он не зависел от приложения )

10к это достаточно не много. Я бы сделал для всего statsd 5-10сек и складывал в графит, и через сутки роллапил в минуту

И объем сильно не взлетит и детализацию апнешь, и единая точка входа для всех приложений

И писал бы это все в отдельную реверсивную таблицу, тем самым подняв скорость обработки запросов раз в 5

10к это достаточно не много. Я бы сделал для всего statsd 5-10сек и складывал в графит, и через сутки роллапил в минуту

думал так сделать - но есть подводные камни в виде того что не все метрки однозначно правильно можно роллапить , нужно провести некоторый анализ

И писал бы это все в отдельную реверсивную таблицу, тем самым подняв скорость обработки запросов раз в 5

реверсивная изначально с романом отлаживали одни из первых )

думал так сделать - но есть подводные камни в виде того что не все метрки однозначно правильно можно роллапить , нужно провести некоторый анализ

Правила роллапа для разных типов надо будет подогнать, но это мелочи

у нас есть любопытный пример реалтайм статистики. демон принимает пакетики и аггрегирует в памяти в минутные аггрегаты, хранит минут 30 но при этом текущую минуту он считает как сумму за последние 60 секунд (чтобы не было всяких резких падений в начале очередной минуты) отдает это по старому доброму carbonlink-у в graphite-clickhouse

у нас есть любопытный пример реалтайм статистики. демон принимает пакетики и аггрегирует в памяти в минутные аггрегаты, хранит минут 30 но при этом текущую минуту он считает как сумму за последние 60 секунд (чтобы не было всяких резких падений в начале очередной минуты) отдает это по старому доброму carbonlink-у в graphite-clickhouse

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

никак. оно заточено под наши нужны и принимает наши собственные события (к графиту сами события отношения не имеют) я рассказал просто как пример реализации реалтайм графиков

думал так сделать - но есть подводные камни в виде того что не все метрки однозначно правильно можно роллапить , нужно провести некоторый анализ

а flink для вычислений на потоках метрик никто не использовал?

У нас статсд делает почти тоже самое

Только сумма это малая часть того что он на отдаёт

не знаком хорошо с statsd, не использую его. flink может делать скользящие окна, масштабируется горизонтально и т.д. Я его как-то прикрутил для пробы суммирования и алертинга метрик с ошибками в реалтайме, но эксперимент был коротким и никакого вывода сделать я не смог.

Мы очень активно используем statsd. У нас практически все сервисы пишут через него метрики в графит. На вход 2млн метрик в сек, на выходе 1млн в 30сек. Мы пробовали увеличивать детализацию до 10секунд, но пользователи в 99.9% случаев их потом на графиках отображают либо в минутных интервалах либо в 30сек. Поэтому мы решили что 30сек вполне достаточно

Всем привет. Поставил prometheus в kubernetes. Такая проблема есть одно приложение (deployment) которое отдает метрику на кастомном порту, которого нет в expose. Можно как-то прометеусу сказать что вот к таким-то подам за метриками ходить по отдельному порту ?

Мы очень активно используем statsd. У нас практически все сервисы пишут через него метрики в графит. На вход 2млн метрик в сек, на выходе 1млн в 30сек. Мы пробовали увеличивать детализацию до 10секунд, но пользователи в 99.9% случаев их потом на графиках отображают либо в минутных интервалах либо в 30сек. Поэтому мы решили что 30сек вполне достаточно

Мне кажется надо различать измерения и метрики

Всем привет. Поставил prometheus в kubernetes. Такая проблема есть одно приложение (deployment) которое отдает метрику на кастомном порту, которого нет в expose. Можно как-то прометеусу сказать что вот к таким-то подам за метриками ходить по отдельному порту ?

Expose всё равно нужен

А если будет expose, можно будет прометеусу сказать на какой порт ходить ? Или он на все стучаться будет ?

а как у тебя прометеус вообще таргеты находит?

Мне не нужна ещё одна система мониторинга, задача достаточно маленькая из потока statsd метрик некоторые считать с интервалом минута, а другие за 5 секунд к примеру. Сейчас уже стоит Brubeck который считает за минуту и он не имеет такой логики, поэтому самое простое поставить перед ним udp-replicator и поднять на другом порту с настройкой агрегации за 5 секунд.

ну ты как бы уже придумал решение? вполне себе нормальное тебе умный UDP репликатор нужен ? ну наверное проще на golang написать такое или существующему statsd добавить функционал который ты хочешь https://github.com/atlassian/gostatsd

а как у тебя прометеус вообще таргеты находит?

Сервис дисковери настроен

ну ты как бы уже придумал решение? вполне себе нормальное тебе умный UDP репликатор нужен ? ну наверное проще на golang написать такое или существующему statsd добавить функционал который ты хочешь https://github.com/atlassian/gostatsd

Интересно, не видел раньше этого демона, вчера уже запилил у себя решение. На входе поставил udp-mirror за ним пару brubeck с разными интервалами агрегации + ещё carbon-c-relay к метрикам которые с маленьким интервалом считаются добавляет поле .ten_second. чтобы они попадали на отдельный rollup в clickhouse.

Хм https://github.com/atlassian/gostatsd ещё и теги поддерживает

Хм https://github.com/atlassian/gostatsd ещё и теги поддерживает

Омг, это замена привычному statsd?

неужели атлассиан что то сделал годное для опенсорса

Того и гляди жиру на го перепилят

ахаха тоесть мяу.

Омг, это замена привычному statsd?

Ага

И как? Юзает кто в проде? Gostatsd

и вообще как то странно. атлассиан на гитхабе видеть...

А celery не напилили еще на go?)

они в курсе то у них там есть бб

Омг, это замена привычному statsd?

Дрянь на ноде, жрущая память не в себя - это привычно? O_o

они в курсе то у них там есть бб

Ггг

Дрянь на ноде, жрущая память не в себя - это привычно? O_o

Так и я том же... Видеть не хочется

ERROR: S client not available

господа, может подскажете как лучше реализовать запись netflow в influx? Планируется примерно следующая схема: хост пушит netflow данные на другой, где стоит коллектор (nfcapd), который каждую минуту через костыль (nfdump + самописный скрипт) пушит в influx. Находил вариант с pmacct + подобный костыль. Может встречал кто менее костыльный вариант?

Коллеги, подскажите пожалуйста как можно в графане на графике рядом с каждой точкой показывать ее значение?

Только по наведению курсора

Менее костыльным вариантом будет что угодно кроме influxdb. Интересуюсь иногда темой netflow. Вот пара ссылок за сегодня. https://fastnetmon.com/traffic-metrics-in-clickhouse/

https://github.com/robcowart/elastiflow

Так уж исторически сложилось что надо в influx :(

подскажите пожалуйста есть парсер, шлю в пушгейтвей прометеуса кол-во итемов которое распарсились хочу алерт если типа сумма метрики за последние 4 часа больше или меньше в 2 раза чем средняя сумма за это же время за последнюю неделю из-за того что метрика лежит в гейтвее постоянно, получается кисло пытался костылить через прокладку чтоб метрика удалялась после того как прометеус ее забрал, но чето дичь может я вообще что-то не то делаю?)

вы прометеус как-то странно готовите

у меня есть пхп скрипты которые крутятся из них я отправляю метрики на пушгейтвей

прометеус это тпушгейтвей скрапит

я впервые это все трогаю вообще

в идеале лучше иметь сумму всех событий и ловить изменения тупо через increase()

но я с пушгейтвеем не работал, сейчас доку посмотрю

ммм а я хотел типа каждый результат прогона скрипта фиксировать

ну вот у пушгейтвея есть апи метод для удаления метрик

начальник уже говорит свой пушгейтвей с базой пилить

но мне чет не охота

суть в том что не нужно удалять

я понимаю

но как тогда разделять

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

чтоб такой алерт как просят сделать: мне надо как sum_over_time

брать

но типа если прометеус скрапит раз 15сек а скрипт выполняется там долго - sum_over_time даст ваще не то

сделайте counter и просто increase([inteval]) на него

по сути я хочу точки

Использование прома с пушгейтвеем это такое

а что посоветуете?

Основной вей - он ходит собирать в эндпойнты