адекватных инструментов, умеющих пересчеты почти не существует

адекватных инструментов, умеющих пересчеты почти не существует

Пишем свой?))

Пишем свой?))

это технически сложно )

еще как пишем, но там проблема на проблеме

еще как пишем, но там проблема на проблеме

но я б с нуля не стал ) даже поверх кассандры не стал бы

особенно поверх кассандры

а посмотрел бы на то можно ли до вменяемого состояния довести m3db (если очень много времени)

может быть поигрался бы со скрещиванием чего-нибудь под теги с кликхаусом под данные

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

ну чисто алгоритмически - делаем выборку по времени и смотрим её максимум, дальше смотрим последнее значение(текущее) и берем разницу, если разница больше N - то срабатывает триггер

abs(max_over_time(metric[1h] offset 1h) - metric) > 5

Примерно так

ну чисто алгоритмически - делаем выборку по времени и смотрим её максимум, дальше смотрим последнее значение(текущее) и берем разницу, если разница больше N - то срабатывает триггер

telegraf у influx на такое заточен.

я от идеи докера для прома отказался.

я от идеи докера для прома отказался.

почему?)

да и не нужен он там, если только нет уже готового кубера или swarm

из под докера время опроса моих endpoints вело себя мягко говоря странно см график

Понятно, ну в общем видимо будет одним из тех сервисов что будут жить без докера, думаю еще openvpn из контейнера вытащить, а то надоело честно говоря сеть из за этого перестраивать и где надо и где не надо..( Судя по всему всё в докер не запихнуть :)

из под докера время опроса моих endpoints вело себя мягко говоря странно см график

чем объясняешь ?

чем объясняешь ?

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

график слишком цикличный

график слишком цикличный

алиасинг?

честно незнаю низкоуровневых механизмомв которые могут дать такое

алиасинг?

кого с кем?

пожтому мне кажется тут есть другое объяснение а не докер

частота опроса с частотой чего-то ещё

честно незнаю низкоуровневых механизмомв которые могут дать такое

ограничение чего-то - проца, сети, хзчего ещё

так сказать, hard clipping

пробовал вместо пяти секунд и 1 и 10 результат схожий

ну раз проблема не найдена она воспроизведтся.

только теперь видимо без докера

дай запрос которым смотришь посмотрю у ся

пожтому мне кажется тут есть другое объяснение а не докер

хост тот же, сеть та же, ендпойнты те же, только пром запущен нативно. сейчас время опроса стоит как вкопанное +-1мс

дай запрос которым смотришь посмотрю у ся

это парсинг логов приклада. мы экспортим /metrics нативно для прома. +логируем таймстемпы когда к нам за ними пришли

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

ну и пром там же про себя много рассказывает

http_request_duration_microseconds например

http_request_duration_microseconds например

хм, туда я не смотрел. сейчас метрика ведет себя давольно стабильно без вылетов на 1-2с

ну если есть желание разобраться пром молодец.

Подскажите, пожалуйста, почему в grafana иногда показывается количество документов Nan.Infinity?

А, все, нашел, вместо current надо ставить total)

Народ, как я понял prometheus дергает раз в надцать секунд node_exporter, который уже все данные выдает, так? Но ему самому как добавить дополнительные значения то? Или хотя бы пните в сторону что читать :) Потому как что-то не понимаю как это делается, и гугление тоже видимо как-то не правильно провожу...

Народ, как я понял prometheus дергает раз в надцать секунд node_exporter, который уже все данные выдает, так? Но ему самому как добавить дополнительные значения то? Или хотя бы пните в сторону что читать :) Потому как что-то не понимаю как это делается, и гугление тоже видимо как-то не правильно провожу...

попробуйте модифицировать код node_exporter - https://github.com/prometheus/node_exporter или используйте другие экспортеры, которые могут содержать нужные вам данные: https://prometheus.io/download/ или создайте свой экспортер

Угу... а просто добавить некоторые параметры которые будут высчитывать другие скрипты я не могу?

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

это приложение может быть написано на чем угодно, главное чтобы оно отдавало это в правильном для прометеуса формате

расширить же node_exporter, насколько я знаю, нельзя

Понятно, значит прометеус просто дерагет вебовскую страничку которую я ему должен дать с данными по правильным форматам? Ну что же... Спасибо, пошел делать :)

телеграф умеет внешние скрипты вызывать

node_exporter умеет читать из внешнего файла

Понятно, значит прометеус просто дерагет вебовскую страничку которую я ему должен дать с данными по правильным форматам? Ну что же... Спасибо, пошел делать :)

да. Есть еще возможность пушить метрики в прометеус. Можете подробнее узнать здесь https://github.com/prometheus/pushgateway

Пошел читать еще и про телеграф тогда :) P.S. несколько экспортеров на одной машине - это нормально или нет?

не надо так.

Понятно, значит либо там должно быть что-то что умеет объединять работу нескольких экспортеров либо я что-то не понимаю... Иначе как объединять тот же вывод mysql_exporter с node_exporter?

не надо так.

почему?

несколько экспортеров на одном хосте - это нормально

подскажите по системе именования метрик в графит исходя из своего опыта На данный момент схема такая <dc>.<host>.<app>.<request|process|и т.д> дальше уже специфичные метрики в графане графики соответcвенно в 90% случаев *.*.<app>.и метрика какая-нибудь иногда конечно нужны метрики по хосту или по dc, но кажеться что такое именование неоптимально с точки зрения нагрузки на чтение т.к. если у нас приложение размазано на 10 инстанов получаем х10 чтения с диска, и в такой схеме сложно навернуть агрегацию по отдельному <app> (непонятно как должна выглядеть агрегированная метрика) буду очень благодарен за совет по правильному именованию и агрегации метрик ?

так а какая разница как ты распилишь метрику? одна метрика один файл. если приложение имеет метрики не завязанные на хост то его и сохранять надо без привязки к хосту, а если тебе нужна привязка то ты опять же получаешь Х10 - круг замкнулся

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

вопрос больше имеет ли какое то преимущество именование <app>.<dc>.<host>.<metrica> в плане постоения графиков и агрегации сверху, ну и возможно узнать как у кого сделано, опыт avito в статье на хабре прочитал, но тема именований метрик и агрегаций также не раскрыта

вопрос больше имеет ли какое то преимущество именование <app>.<dc>.<host>.<metrica> в плане постоения графиков и агрегации сверху, ну и возможно узнать как у кого сделано, опыт avito в статье на хабре прочитал, но тема именований метрик и агрегаций также не раскрыта

У нас многоступенчатые метрики

И схемы зависят от назначения

Есть префикс класса метрик (system, databases, ...)

А формат зависит от префикса

Преимущество простое - нужно людям сокращать путь до их метрик

ERROR: S client not available

То есть первые два-три-четыре уровня информативные но при этом содержат мало наборов данных

То есть может быть miscellaneous.(group).(app).(dc).(aggregation).(host).(metric) например

а кто то крутил kapacitor + graphite ? там вроде оно умеет в graphite input с масочками

Впрочем исторически у нас слишком много разных схем

То есть может быть miscellaneous.(group).(app).(dc).(aggregation).(host).(metric) например

понятно, спасибо!

понятно, спасибо!

Для агрегации...

Тут дело в том что find относительно лёгкий

Так что особой прям разницы не будет, но по той же причине лучше идти от того что матчится сначала и чаще к тому что реже

clickhouse (carbonapi + graphite-clickhouse ) в качестве хранения метрик у меня так и не взлетает, на запись да все ок, а на чтение там где carbonapi + carbonserver сервер требуют 25% CPU и 30Гб памяти суммарно на весь поток, clickhouse уже на 30% трафика CPU в 90% и по памяти быстро улетает в оом, некоторые запросы у меня не помещались по элементам увеличивал параметры <max_query_size>104857600</max_query_size> <max_ast_elements>100000</max_ast_elements> <use_uncompressed_cache>1</use_uncompressed_cache> <max_concurrent_queries>500</max_concurrent_queries> <uncompressed_cache_size>17179869184</uncompressed_cache_size> все бесполезно, куда копать непонятно

есть тут парни на канале кх

их не спрашивл ?

https://t.me/clickhouse_ru

clickhouse (carbonapi + graphite-clickhouse ) в качестве хранения метрик у меня так и не взлетает, на запись да все ок, а на чтение там где carbonapi + carbonserver сервер требуют 25% CPU и 30Гб памяти суммарно на весь поток, clickhouse уже на 30% трафика CPU в 90% и по памяти быстро улетает в оом, некоторые запросы у меня не помещались по элементам увеличивал параметры <max_query_size>104857600</max_query_size> <max_ast_elements>100000</max_ast_elements> <use_uncompressed_cache>1</use_uncompressed_cache> <max_concurrent_queries>500</max_concurrent_queries> <uncompressed_cache_size>17179869184</uncompressed_cache_size> все бесполезно, куда копать непонятно

В карбонапи включен sendglobsasis?

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

И количество глобов в запросе в 0 (бесконечно)

ну я вижу что есть. но с такими вот лучше туда

В карбонапи включен sendglobsasis?

да конечно + maxBatchSize: 100000

ну я вижу что есть. но с такими вот лучше туда

ок попробую спросить в соседнем

clickhouse (carbonapi + graphite-clickhouse ) в качестве хранения метрик у меня так и не взлетает, на запись да все ок, а на чтение там где carbonapi + carbonserver сервер требуют 25% CPU и 30Гб памяти суммарно на весь поток, clickhouse уже на 30% трафика CPU в 90% и по памяти быстро улетает в оом, некоторые запросы у меня не помещались по элементам увеличивал параметры <max_query_size>104857600</max_query_size> <max_ast_elements>100000</max_ast_elements> <use_uncompressed_cache>1</use_uncompressed_cache> <max_concurrent_queries>500</max_concurrent_queries> <uncompressed_cache_size>17179869184</uncompressed_cache_size> все бесполезно, куда копать непонятно

А версия КХ какая? Я уже несколько раз наступал на плохие версии - помогал откат/обновление

А версия КХ какая? Я уже несколько раз наступал на плохие версии - помогал откат/обновление

1.1.54245 последняя stable насколько понимаю

1.1.54245 последняя stable насколько понимаю

ничего не могу сказать за эту версии. знаю что в 253 (или раньше) что-то сломали и она работает плохо, а 236 работает хорошо (у нас в проде).

ничего не могу сказать за эту версии. знаю что в 253 (или раньше) что-то сломали и она работает плохо, а 236 работает хорошо (у нас в проде).

Спасибо попробую её

Может кто пояснить что я сделал не так если не сложно? (Python Exporter) https://gist.github.com/anonymous/3a89b036b5aac9a99b7e245bc6626302 Интересует собственно Gauge, остальные два вроде срабатывают, правда зачем это делать так - мне до сих пор не ясно... сами значения там тоже те что первые под руку попались, конкретно их я так понимаю лучше самому пушить вроде? Нужно то немного - что бы скрипт выполнялся только по запросу. Всё! А в этом случае я так понимаю оно выполняется каждую секунду...

ничего не могу сказать за эту версии. знаю что в 253 (или раньше) что-то сломали и она работает плохо, а 236 работает хорошо (у нас в проде).

откатился на 1.1.54236, все также по нагрузке как и на 1.1.54245, эх

@ihard а по времени ответа оно как? И что в логах у carbonapi и clickhouse'а в моменты запросов? Просто поведение очень похоже на раскрытие глобов в запросах все же

@ihard а по времени ответа оно как? И что в логах у carbonapi и clickhouse'а в моменты запросов? Просто поведение очень похоже на раскрытие глобов в запросах все же

Я смотрел запросы они не одиночные точно, некоторые ~ 100кб вида path in (куча метрик)

А что в плане фоновых мержей в кх?

да конечно + maxBatchSize: 100000

Возможно лучше 1-2 ляма

КХ не очень любит маленькие куски и выборку по ним

либо делать бутерброд из Buffer поверх GraphiteMergeTree

и селектить из буфера

А что в плане фоновых мержей в кх?

На запись никаких проблем, при заливке он держал 700к в сек обычный поток 3к, ошибок в логе нет