Как бы так складывать в graphite системные метрики (cpu, vsz, rss..) про каждый процесс, запущенный supervisord'ом?
52 views
Skip to first unread message
Кирилл Матусов
Feb 19, 2016, 1:30:30 PM2/19/16
to devopsru
Привет!
Супервизор рулит всякими разными скриптиками. Свои внутренние метрики они шлют в графайт через statsd. Про их рестарты графайту может сообщать плагин sulphite. А вот смотреть, кто из них после рестарта съел всю оперативу не очень удобно, разве что руками atop'ом. Есть ли удобный способ складывать в графайт и это тоже?
Можно, конечно, из supervisorctl status тянуть список запущенного, по пидам клеить метрики из ps'а и тд.. но пока жива надежда на существование более-менее готового решения %)
Anton Lebedevich
Feb 19, 2016, 2:04:14 PM2/19/16
to devo...@googlegroups.com
Вопрос, процессов несколько одновременно запущено, или только один на
одной машине?
Если в каждый момент времени один, то все просто, пишешь рестарты в
логи, и потом по таймстампам смотришь, кто жил в момент кончившейся
памяти.
Если процессов много, то это интересная коробочка с червями, которую
кушают нынешние системы мониторинга в связи с наступлением
контейнеров. Готового решения не знаю, найдешь - покажи.
Варианты слепить из того, что есть:
- зашивать пид процесса в имена метрик, которые он шлет, и валить это
дело в графит, включив там lazy allocation. Файлов создаст неимоверное
число, место должно от lazy allocation экономиться, но графит (или
графана) скорее всего взорвется, делая из этого агрегаты (или просто
ища максимум из моря метрик)
- зашивать пид процесса в тег метрики и использовать систему, которая
умеет теги, типа OpenTSDB или что там сейчас у InfluxDB из не
сломанных фич осталось.
> --
> Вы получили это сообщение, поскольку подписаны на группу "devopsru".
> Чтобы отменить подписку на эту группу и больше не получать от нее сообщения,
> отправьте письмо на электронный адрес devopsru+u...@googlegroups.com.
> Чтобы настроить другие параметры, перейдите по ссылке
> https://groups.google.com/d/optout.
одной машине?
Если в каждый момент времени один, то все просто, пишешь рестарты в
логи, и потом по таймстампам смотришь, кто жил в момент кончившейся
памяти.
Если процессов много, то это интересная коробочка с червями, которую
кушают нынешние системы мониторинга в связи с наступлением
контейнеров. Готового решения не знаю, найдешь - покажи.
Варианты слепить из того, что есть:
- зашивать пид процесса в имена метрик, которые он шлет, и валить это
дело в графит, включив там lazy allocation. Файлов создаст неимоверное
число, место должно от lazy allocation экономиться, но графит (или
графана) скорее всего взорвется, делая из этого агрегаты (или просто
ища максимум из моря метрик)
- зашивать пид процесса в тег метрики и использовать систему, которая
умеет теги, типа OpenTSDB или что там сейчас у InfluxDB из не
сломанных фич осталось.
> Вы получили это сообщение, поскольку подписаны на группу "devopsru".
> Чтобы отменить подписку на эту группу и больше не получать от нее сообщения,
> отправьте письмо на электронный адрес devopsru+u...@googlegroups.com.
> Чтобы настроить другие параметры, перейдите по ссылке
> https://groups.google.com/d/optout.
Timur Batyrshin
Feb 20, 2016, 3:53:06 AM2/20/16
to devopsru
Привет,
Если supervisor может высунуть PID в виде pidfile, то на этот pidfile можно натравить monit, и он будет собирать данные по памяти, cpu, рестартам и т.п.
А уже он будет высовывать все по HTTP, либо через monit status.
Тимур
пятница, 19 февраля 2016 г., 21:30:30 UTC+3 пользователь Кирилл Матусов написал:
пятница, 19 февраля 2016 г., 21:30:30 UTC+3 пользователь Кирилл Матусов написал:
Reply all
Reply to author
Forward
0 new messages