хей пипл. есть тут те кто юзает Datadog?

хочу алерты накрутить

чет туплю

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

Метрика, Трешхолд, кого алертить

ага есть там такое

спс

Ребят, а как подсчитать количество метрик(определенной метрики) и вывести это дело, в графане

Ребят, а как подсчитать количество метрик(определенной метрики) и вывести это дело, в графане

В графите есть по-моему countseries

Ага, спасибо, гляну.

Здравствуйте у меня есть пара вопросов по метрикам и не совсем, но близким. По метрикам: есть продукт в нём посылается запрос, который обрабатывается в n других executabla-х, пока расположенных локально, но в ближайшем будущем, которые будут разнесены; каждый запрос характеризуется n параметрами, типа юзера, и нескольких id. При обработке добавляются новые, типа размера графа при обработке, кучи таймингов обработки. Вопрос, куда читать, как правильно и эффективно собирать данные по таким запросам, так чтобы потом метрики можно было собрать в одном месте и сделать отчеты. При этом часть "тегов"/метрик могут собираться в разных executable. Этот вопрос в основном про то, куда читать, как это делать правильно, т.к. вопрос сейчас нечеткий? И второй, близкий: у нас есть тесты, unit и интеграционные, с них собираются метрики (те же что выше) плюс результаты микробенчмарков. Если с метриками все ясно, то, что делать микробенчмарками т.к. хотелось бы собирать raw data от всех запусков и уже далее вычислять интересные вещи такие как линейную регрессию по данным, персентили и т.п. Сейчас используется elastic search stack + kibana для выводов, но это как-то печально, т.к. непонтяно как считать все интересные вещи. В общем тут вопрос, правильный ли вообще путь и на какие технологии стоит смотреть?

Здравствуйте у меня есть пара вопросов по метрикам и не совсем, но близким. По метрикам: есть продукт в нём посылается запрос, который обрабатывается в n других executabla-х, пока расположенных локально, но в ближайшем будущем, которые будут разнесены; каждый запрос характеризуется n параметрами, типа юзера, и нескольких id. При обработке добавляются новые, типа размера графа при обработке, кучи таймингов обработки. Вопрос, куда читать, как правильно и эффективно собирать данные по таким запросам, так чтобы потом метрики можно было собрать в одном месте и сделать отчеты. При этом часть "тегов"/метрик могут собираться в разных executable. Этот вопрос в основном про то, куда читать, как это делать правильно, т.к. вопрос сейчас нечеткий? И второй, близкий: у нас есть тесты, unit и интеграционные, с них собираются метрики (те же что выше) плюс результаты микробенчмарков. Если с метриками все ясно, то, что делать микробенчмарками т.к. хотелось бы собирать raw data от всех запусков и уже далее вычислять интересные вещи такие как линейную регрессию по данным, персентили и т.п. Сейчас используется elastic search stack + kibana для выводов, но это как-то печально, т.к. непонтяно как считать все интересные вещи. В общем тут вопрос, правильный ли вообще путь и на какие технологии стоит смотреть?

1. Звучит как хорошая сфера применения opentracing

В любой из реализаций

@qnikst кстати привет, не ожидал тебя в ТГ увидеть

но возвращаясь к теме - http://opentracing.io/ я про это, в одной из его реализаций - кажется что вы уже его частично переизобрели. Но плюс конкретно этой штуки - что есть уже базы и дашборды под него

как раз реализующие все это удобно

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

угу, прикольно, читаю спеку сейчас, т.к. либу для языка писать придётся

угу, прикольно, читаю спеку сейчас, т.к. либу для языка писать придётся

у вас какой-то свой язык?

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

haskell =)

O_o

можно байндинги к плюсам писать, конечно

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

@qnikst про первое - для разовых отчетов и не очень долгого хранения сойдет в общем даже Elasticsearch и отчеты в кибане )

просто работать будет медленно

а какой-нибудь зипкин будет намного веселее.

первое - для live метрик и слежения за системой

первое - для live метрик и слежения за системой

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

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

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

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

в идеале мы заинтересованы, чтобы не изобретать своё : ]

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

Здравствуйте у меня есть пара вопросов по метрикам и не совсем, но близким. По метрикам: есть продукт в нём посылается запрос, который обрабатывается в n других executabla-х, пока расположенных локально, но в ближайшем будущем, которые будут разнесены; каждый запрос характеризуется n параметрами, типа юзера, и нескольких id. При обработке добавляются новые, типа размера графа при обработке, кучи таймингов обработки. Вопрос, куда читать, как правильно и эффективно собирать данные по таким запросам, так чтобы потом метрики можно было собрать в одном месте и сделать отчеты. При этом часть "тегов"/метрик могут собираться в разных executable. Этот вопрос в основном про то, куда читать, как это делать правильно, т.к. вопрос сейчас нечеткий? И второй, близкий: у нас есть тесты, unit и интеграционные, с них собираются метрики (те же что выше) плюс результаты микробенчмарков. Если с метриками все ясно, то, что делать микробенчмарками т.к. хотелось бы собирать raw data от всех запусков и уже далее вычислять интересные вещи такие как линейную регрессию по данным, персентили и т.п. Сейчас используется elastic search stack + kibana для выводов, но это как-то печально, т.к. непонтяно как считать все интересные вещи. В общем тут вопрос, правильный ли вообще путь и на какие технологии стоит смотреть?

о ты наконец добрался сюда )

я тут давно, но в режиме R/O был

что кроме эластика ещё для кибаны годится?

менее прожорливое

что кроме эластика ещё для кибаны годится?

нет

@erzentd сюрприз, но кибану пилят те же чуваки что и эластик и по их же словам кибана в ядре завязана на ES чуть более чем полностью

Я щас как раз ковыряюсь в opentracing и что-то не едет.

Я щас как раз ковыряюсь в opentracing и что-то не едет.

А интересно, что не едет?

Да там столько всего много наплодили... :)

Ехал трейсер через трейсер. Вот с ходу непонятно. Чем собсно писать из Python в Zipkin. Тьма примеров и все через какое-то lightstep трейсер. Нет, я конечно рад за собирающийся зарабатывать стартап, но чем в итоге то кормить локальный zipkin :)

опентрейсер?

посмотрел приезенташки, все равно ничерта не ясно)

опентрейсер?

Попытка сделать единый стандарт на трейсинг запросов

на базе gRPC'шнего трейса

Ехал трейсер через трейсер. Вот с ходу непонятно. Чем собсно писать из Python в Zipkin. Тьма примеров и все через какое-то lightstep трейсер. Нет, я конечно рад за собирающийся зарабатывать стартап, но чем в итоге то кормить локальный zipkin :)

у меня Гошечка, там вроде клиентов море разных под разные сервера для него, так что у меня таких проблем нет (

опентрейсер?

http://opentracing.io/documentation/pages/quick-start.html лучше с этого начинать смотреть кмк

я пока толком не игрался, знаю что у нас народ под java юзает

кстати, недавно запретили церковь свидетелей иеговы

я бы аккуратнее был с названием чатика теперь %)

метрики изымут в пользу государства?

(запрещенная в РФ группа Телеграм)

и вот это заставят приписывать же

@erzentd сюрприз, но кибану пилят те же чуваки что и эластик и по их же словам кибана в ядре завязана на ES чуть более чем полностью

печаль

у меня Гошечка, там вроде клиентов море разных под разные сервера для него, так что у меня таких проблем нет (

это очень блять важная информация ))

это очень блять важная информация ))

но ваще для питона тоже ищутся трейсеры

https://github.com/opentracing/opentracing-python это вот разве не оно?

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

то есть нужно делать обертки над обработкой запросов и пр.

и начать передавать где-то контекст из трейсера

https://github.com/opentracing/opentracing-python это вот разве не оно?

я умею гуглить, но да - это не оно :)) там прямо сверху написано: Future versions will include a reference implementation utilizing an abstract Recorder interface, as well as a Zipkin-compatible Tracer. То есть именно Tracer у них и нет. Почти во всех примерах или ... # can be any valid OpenTracing tracer implementation tracer = whatever ... или import lightstep.tracer tracer = lightstep.tracer.init_tracer(group_name="fuck", access_token="{lightstep_token}") ну как бы я писал выше, рад за lightstep, но мне бы в Zipkin :D

В общем, там есть что поковырять, конечно. В конце концов, как выше написано, "сначала прочитать спеку и запилить самим" :)) Но пока - не едет.

ERROR: S client not available

https://www.influxdata.com/prometheus-influxdb-thoughts/

я умею гуглить, но да - это не оно :)) там прямо сверху написано: Future versions will include a reference implementation utilizing an abstract Recorder interface, as well as a Zipkin-compatible Tracer. То есть именно Tracer у них и нет. Почти во всех примерах или ... # can be any valid OpenTracing tracer implementation tracer = whatever ... или import lightstep.tracer tracer = lightstep.tracer.init_tracer(group_name="fuck", access_token="{lightstep_token}") ну как бы я писал выше, рад за lightstep, но мне бы в Zipkin :D

ок, жаль, да. Но там есть и другие реализации OpenTracing'а вроде, может что-то можно придумать

ок, жаль, да. Но там есть и другие реализации OpenTracing'а вроде, может что-то можно придумать

ну вот и придумываю, подбираю наименьшее общее кратное :)

@Civiloid а для сборки всяких результатов бенчмарков и т.п. сразу своё пилить, или что готовое-полуготовое брать. У меня там примерно такая ситуация, есть например бенчмарк, он запускается N раз, каждый раз с увеличивающимся числом итераций, в итоге есть пачка [(n, time)]. Которые нужно куда-нить положить, уметь показывать графиком, посчитать регрессию и вывести её как в summary. И отдельно строить график обработанных величин. Сейчас это делается в кибане по упрощенной модели, там просто n раз пускается тест при фиксированном количестве итераций, поэтому все суммы и персентили легко считаются, но как в новую модель затащить неясно. Плюс не удобно, что там все на timeline причепленно, поэтому неудобно смотреть.

@Civiloid а для сборки всяких результатов бенчмарков и т.п. сразу своё пилить, или что готовое-полуготовое брать. У меня там примерно такая ситуация, есть например бенчмарк, он запускается N раз, каждый раз с увеличивающимся числом итераций, в итоге есть пачка [(n, time)]. Которые нужно куда-нить положить, уметь показывать графиком, посчитать регрессию и вывести её как в summary. И отдельно строить график обработанных величин. Сейчас это делается в кибане по упрощенной модели, там просто n раз пускается тест при фиксированном количестве итераций, поэтому все суммы и персентили легко считаются, но как в новую модель затащить неясно. Плюс не удобно, что там все на timeline причепленно, поэтому неудобно смотреть.

ну кажется что столбцовая база и redash позволят сделать больше. Но может я и не совсем понимаю что вы хотите

может быть redash + grafana

а кто-нибудь сопрягал alerta и alertmanager? что-то не выходит каменый цветок

webhook настроил как тут примерно (у меня /api префикс): https://github.com/alerta/prometheus-config/blob/master/alertmanager.yml в логах Apr 24 15:07:08 ip-172-31-18-127 alertmanager[15020]: time="2017-04-24T15:07:08Z" level=error msg="Notify for 3 alerts failed: Cancelling notify retry due to unrecoverable error: unexpected status code 404" source="dispatch.go:246"

курл из консоли с -X POST работает

А как бы заббикс без костылей научить понимать JSON в ответе от REST API?

А как бы заббикс без костылей научить понимать JSON в ответе от REST API?

не тот чат, скинул ссылку в личку )

не тот чат, скинул ссылку в личку )

спс

гадский алертменеджер в ошибках мало контекста даёт даже в дебаг режиме – отстой

гадский алертменеджер в ошибках мало контекста даёт даже в дебаг режиме – отстой

что такое Alerta и зачем она в двух словах нужна?

гадский алертменеджер в ошибках мало контекста даёт даже в дебаг режиме – отстой

внимательно перепроверять url

у алерты // плохо

что такое Alerta и зачем она в двух словах нужна?

гугл ит

внимательно перепроверять url

дык, скопипастил вроде в курл и норм

гугл ит

спасибо Кэп

http://alerta.io/

http://alerta.io/

да нашёл я, не понял в чём суть

дашборда с алертами и api чтобы их туда засунуть/вынуть

дык, скопипастил вроде в курл и норм

ааа, это сам алертменеджер (го клиент) может нормализовывать

ща проверю

блин, гадский yaml

кавычки!

дашборда с алертами и api чтобы их туда засунуть/вынуть

разве это не тоже самое, что alertmanager тогда, это типо примочка какая-то?

алертменеджер минималистичен и заточен на менеджмент больше, а не на визуализацию

понял, спасибо

у меня сейчас алерта – это один из роутов куда летят сообщения

ааа, типо под хистори