вот понять бы где

вдруг кому надо, менять тут: [http] max-row-limit =

I love this

prometheus new release: v1.5.1 - 1.5.1 / 2017-02-07 * [BUGFIX] Don't lose fully persisted memory series during checkpointing.

Какие все эти тулзы прям классные

что твои смузи, прям

Граждане, а проведите пожалуйста ликбез. Есть питон приложение, допустим smallhttpserver. я хочу собирать с него request per seconds и время ответа. Что мне для этого надо? Пушить хочу это всё в прометей. Что-то я туплю и не знаю с какого конца подлезть к задаче.

плохое решение: telegraf и его метрика http_response_response_time.

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

надо посмотреть где лагает, хочу разрабам показать proof of concept завтра

тогда вот такая штука: https://lincolnloop.com/blog/tracking-application-response-time-nginx/, то бишь специальный формат лога нджинкса

а если просто взять nginx exporter?

а не пойдёт

?

Граждане, а проведите пожалуйста ликбез. Есть питон приложение, допустим smallhttpserver. я хочу собирать с него request per seconds и время ответа. Что мне для этого надо? Пушить хочу это всё в прометей. Что-то я туплю и не знаю с какого конца подлезть к задаче.

перед ним же nginx стоит? парси логи

Вообще для Django есть statsd инструментилки которые сами времена засекут

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

Нужно только statsd собирать

перед ним же nginx стоит? парси логи

хм

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

.... а не пойдёт потому, что вот эта дрянь - https://github.com/discordianfish/nginx_exporter - умеет только дёргать страничку /nginx_status

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

.... а не пойдёт потому, что вот эта дрянь - https://github.com/discordianfish/nginx_exporter - умеет только дёргать страничку /nginx_status

печально

мои глаза...

нормально. опен-сорсный нджинкс содержит крайне мало всяких этих экспортёров и метрик потому, что эти фичи входят в состав Nginx+

а вы смотрели на этот /status который в nginx+ ?

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

однако могу предложить чит.

вот и у меня такое же ощущение от их мониторинга

поэтому мы делаем свой сервис =))

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

у нджинкса есть такая фича: он умеет после успешной обработки запроса следом обработать ещё какой-нибудь запрос (http://article.gmane.org/gmane.comp.web.nginx.english/1305), пасхалка от Сысоева.

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

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

?

а зачем этот post action в данном случае? почему просто в лог upstream_response_time`

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

а я и не говорю что мы из любого лога соберем это. Но если upstream_response_time и/или просто response_time есть в логе, то мы всё можно покажем

ну нет так нет ?

Граждане, а проведите пожалуйста ликбез. Есть питон приложение, допустим smallhttpserver. я хочу собирать с него request per seconds и время ответа. Что мне для этого надо? Пушить хочу это всё в прометей. Что-то я туплю и не знаю с какого конца подлезть к задаче.

кажется прометей с его pull моделью просто тут не очень подходит

есть конечно какие-то (lua) модули к nginx, в которые можно собирать статистику и по запросу отдавать

ну или тоже самое в самой апликухе (а-ла codahale metrics), но кажется лог парсинг + пуш лучше

ну или тоже самое в самой апликухе (а-ла codahale metrics), но кажется лог парсинг + пуш лучше

пойду у девопсов спрошу, как оно правильно делать)

Спасибо за советы!

бугага)

есть второй девопс чат;)

пойду посмотрю что там наотвечают, если сразу нах не пошлют

у прометеуса есть же пуш гейтвей

https://github.com/prometheus/pushgateway

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

вот спасибо, именно это и надо: нужно высчитать полное время обработки на reverse proxy (нджинкс например) - тут без примочек к нджинксу не обойтись. подскажите пожалуйста какие именно примочки нужны???

Ссылка выше на кастомный лог с upstream response status

Кроме того вроде был модуль для nginx который statsd умеет

я вот этот нашел: https://github.com/markuslindenberg/nginx_request_exporter

но оно только текущие запросы логит

а мне бы время генерации ответов собирать

а мне бы время генерации ответов собирать

во во

во во

??

В лог формат вместо time:$request_time

Впишите time:$upstream_response_time

ыы, да, чет не подумал о том что эти параметры можно редактировать

спасибо огромное, щас попробую

Только по урлам разбивку не получите

Точнее - хз, кажется оно может умереть от этого, но я не пробовал

а это уже страшно

а что от чего умереть может?

nginx от пересылки таких логов?

или прометей от такой группировки?

ERROR: S client not available

Если пытаться считать отдельные метрики для каждого урла, то или этот экспортер или сам Прометей могут прогнуться

Но это ничем кроме чуйки не обоснованное мнение

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

спасибо

Кул, пиши что поймёшь потом

я вот этот нашел: https://github.com/markuslindenberg/nginx_request_exporter

то есть фактически парсим лог и фигачим его в прометей?

грубо - да. либо модуль/скрипт на Lua или nginx-скрипте.

грубо - да. либо модуль/скрипт на Lua или nginx-скрипте.

А по производительности выйдет тоже на тоже наверное?

А по производительности выйдет тоже на тоже наверное?

там оверхед в общем никакой на такие вещи

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

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

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

писать самому видимо такой модуль)

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

Вроде на гитхабе была пара вариантов

Вроде на гитхабе была пара вариантов

завтра поищу, спасиб

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

ну, начнем с этого

вообще есть мысль сделать рпник и деб пакет в котором будет сразу прометей + node exporter + экспортеры под популярные фронты и бекенды. с предустановленными конфигами. из серии мониторинг диска, сетевых пакетов, запросов в nginx и запросов к базе. и просто разраб ставит это, мы заводим в графану по быстрому, смотрим графики, тыкаем носом и так же в один клик удаляем прометей с экспортером

или я зря упираюсь в один прометей для такой цели?

увидительный подход. будто бы мониторинг это мгновенная вещь а не процесс.

мониторинг имхо в идеале часть дефолтного имиджа разворачиваемого из шаблона

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

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

он вообще ничего нигде не хранил

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

со стороны инфраструктуры мониторинг есть, мы видим, что всё ок, но разрабы не хотят верить, что их апп говно

так что нужен такой instant мониторинг

как молотком в морду

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

время обработки запроса

sql выборки

кровавый интегратор. куча разных команд

приходят только когда "лагает"