Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 34
Не совсем понятно, почему у вас все скрипты выглядять как
HOST=Ваш_агент_addr
SERVER=Ваш_сервер_addr
Вместо Ваш_агент_addr надо вписать IP или имя вашего агента. Вместо Ваш_сервер_addr — IP/имя сервера.
Почему во всех — потому что такой подход использовал: один шаблон + один(или пара) скриптов + один или несколько UserParameter.
(+) мониторы могут использоваться по отдельности (нет необходимости ставить весь пакет)
(+) пользователь видит внутренности скрипта-сборщика и понимает, как используются эти параметры, может изменить
(-) надо в каждый скрипт заходить и менять эти настройки. Для облегчения этого процесса я добавил SET_server_to_all.sh
(+) у каждого скрипта имеются дополнительные входные параметры, которые пользователю не мешало бы проверить
У меня не было цели собрать целый набор шаблонов, т.к. у каждого пользователя свой набор программ/сервисов. И, скорее-всего, они используют один-несколько мониторов, но не все.
Если кто-то имеет схожие со мной взгляды на принципы сбора параметров (использование одного запроса к службе, а потом — zabbix-sender для всех), то готов адаптировать свои мониторы под синтаксис библиотеки шаблонов. К сожалению, я не смог найти разработчика выложившего свои труды в виде скомпанованной библиотеки мониторов с подобным подходом.
Почему во всех — потому что такой подход использовал: один шаблон + один(или пара) скриптов + один или несколько UserParameter.
(+) мониторы могут использоваться по отдельности (нет необходимости ставить весь пакет)
(+) пользователь видит внутренности скрипта-сборщика и понимает, как используются эти параметры, может изменить
(-) надо в каждый скрипт заходить и менять эти настройки. Для облегчения этого процесса я добавил SET_server_to_all.sh
(+) у каждого скрипта имеются дополнительные входные параметры, которые пользователю не мешало бы проверить
У меня не было цели собрать целый набор шаблонов, т.к. у каждого пользователя свой набор программ/сервисов. И, скорее-всего, они используют один-несколько мониторов, но не все.
Если кто-то имеет схожие со мной взгляды на принципы сбора параметров (использование одного запроса к службе, а потом — zabbix-sender для всех), то готов адаптировать свои мониторы под синтаксис библиотеки шаблонов. К сожалению, я не смог найти разработчика выложившего свои труды в виде скомпанованной библиотеки мониторов с подобным подходом.
На самом деле, если вы не отправляется с хоста данные «за того парня», то чем указывать zabbix_sender руками имя хоста и сервера, проще и правильнее указать через опцию -z путь к конфигу заббикс агента на машине. Оттуда sender прекрасно заберет и отправителя и адресата.
В таком случае, вы можете менять эти параметры в одном месте и не бегать по куче скриптов, разыскивая, где осталась зарытая собака.
В таком случае, вы можете менять эти параметры в одном месте и не бегать по куче скриптов, разыскивая, где осталась зарытая собака.
Кому кстати лень всем этим заниматься, могу порекомендовать newrelic.com, не встречал более крутого и удобного мониторинга всего на сервере.
Конечно, если лень и у вас есть лишние 20-150$ в месяц — красивый, удобный сервис.
К плюсам newrelic могу отнести:
(+) наличие возможности уведомления пользователя
(+) супер-легкий процесс установки агента
(+) не нужно искать место, куда поставить zabbix-server (желательно, чтобы он всегда был в он-лайне. в худшем случае можно поставить его в виртуалку на свою персоналку, кстати, готовые виртуалки доступны для скачки прямо на сайте Zabbix)
Ну и жирный(для меня) минус:
(-) бесплатно первые 14 дней, а после — только мониторинг основных параметров ОС — диск, память, процессор (Zabbix умеет «из коробки»)
(-) бесплатно хранит данные только за последние 24 часа
В свое время пытался найти бесплатный сервис мониторинга доступности сервера. Много платных. Но я все-таки нашел бесплатный, который мне sms-ит в случае, если сервер не вернул определенный код на определенной странице. uptimerobot.com, называется. Кто ищет, тот всегда найдет.
+ zabbix — для разбора полетов с быстродействием, без ежемесячных вливаний. Вполне устраивает.
Зарегился сам, а также свежее описание по русски нашел тут:
zxmd.wordpress.com/2014/03/07/newrelic-monitoring/
Конечно, выбирать пользователю по доходу, навыкам и потребностям.
К плюсам newrelic могу отнести:
(+) наличие возможности уведомления пользователя
(+) супер-легкий процесс установки агента
(+) не нужно искать место, куда поставить zabbix-server (желательно, чтобы он всегда был в он-лайне. в худшем случае можно поставить его в виртуалку на свою персоналку, кстати, готовые виртуалки доступны для скачки прямо на сайте Zabbix)
Ну и жирный(для меня) минус:
(-) бесплатно первые 14 дней, а после — только мониторинг основных параметров ОС — диск, память, процессор (Zabbix умеет «из коробки»)
(-) бесплатно хранит данные только за последние 24 часа
В свое время пытался найти бесплатный сервис мониторинга доступности сервера. Много платных. Но я все-таки нашел бесплатный, который мне sms-ит в случае, если сервер не вернул определенный код на определенной странице. uptimerobot.com, называется. Кто ищет, тот всегда найдет.
+ zabbix — для разбора полетов с быстродействием, без ежемесячных вливаний. Вполне устраивает.
Зарегился сам, а также свежее описание по русски нашел тут:
zxmd.wordpress.com/2014/03/07/newrelic-monitoring/
Конечно, выбирать пользователю по доходу, навыкам и потребностям.
попробовал. красиво. Но его демоны очень хорошо нагружают систему. Отказался.
К сожалению, как и во многих других вариантах, несколько PHP-FPM серверов не могут мониториться с помощью одного скрипта и шаблона. Это печально.
Вот бы заббиксовый LLD каким-либо образом использовать для определения списка php-fpm серверов, а потом скриптом собирать данные с них…
Вот бы заббиксовый LLD каким-либо образом использовать для определения списка php-fpm серверов, а потом скриптом собирать данные с них…
Без проблем!
1) Давайте поищем программку, которая сможет делать запросы к php-fpm напрямую.
2) Найдем способ определения списка запущенных php-fpm серверов.
Просто, у нас один сервер php-fpm, ну и следовательно, у меня не стояло задачи делать discovery и обращаться напрямую к php-fpm.
Минусом этому мониторингу получим необходимость устанавливать средство для обращения к fastcgi.
В ZTC прописан протокол общения с php-fpm без сторонних fast-cgi приложений. Но, к сожалению, discovery там нет.
Давайте объединим знания, стремления и сделаем такой шаблон+скрипт.
Контакт отправил в личку, если Вы готовы тратить личное время.
1) Давайте поищем программку, которая сможет делать запросы к php-fpm напрямую.
2) Найдем способ определения списка запущенных php-fpm серверов.
Просто, у нас один сервер php-fpm, ну и следовательно, у меня не стояло задачи делать discovery и обращаться напрямую к php-fpm.
Минусом этому мониторингу получим необходимость устанавливать средство для обращения к fastcgi.
В ZTC прописан протокол общения с php-fpm без сторонних fast-cgi приложений. Но, к сожалению, discovery там нет.
Давайте объединим знания, стремления и сделаем такой шаблон+скрипт.
Контакт отправил в личку, если Вы готовы тратить личное время.
Так в чем проблема то? напишите скрипт который будет отдавать json со списком нужных инсталяций php-fpm и через низкоуровневое обнаружение ищите.
Уже думал над этим, но столкнулся с тем, что не нашел как получить список php-fpm пулов и мест, которые они «слушают» — это может быть как сетевой порт, так и сокет.
У вас конфиги генерируются или каждый раз сами пишете? Если генерируются — сделайте генерацию json'а из тех же мест, откуда конфиги генерируются. Если руками делаете, то переходите на генерирование конфигов и соответственно смотрите в сторону решения выше.
Список прослушиваемых tcp портов и сокетов pfp-fpm:
# netstat -ltpn -A unix | awk '/\/php-fpm / {if($1=="tcp")print $4; else print $10}'
127.0.0.1:9000
0.0.0.0:9001
/tmp/php-fpm.sock
/tmp/php-fpm2
Не надо «rpm -Uvh http://», таким образом вы не сохраняете эти операции в истории транзакций yum.
yum history полезное, не убивайте её.
yum install http://location/package.rpm yum localinstall /path/to/package.rpm
yum history полезное, не убивайте её.
Я бы порекомендовал пойти чуть дальше и генерировать из шаблонов и распространять все конфиги и скрипты мониторинга автоматически через любую удобную систему управления конфигурациями — puppet/chef/ansible и т.п. Тогда не надо будет ни о стандартах думать внутренних, ни переживать на тему «не забыл ли я скопировать какой-то скрипт, открыть порт в фаерволе, настроить status-page на веб-сервере». Впрочем, это тема для отдельного большого разговора ))
Думаю, что это слишком сложно, и потребует дополнительно много знаний (и желательно опыта) по работе с системой управления. Было бы хорошо так сделать, конечно, оформить в виде пакета, и на гит! Может кто займется?.. с мониторами Zabbix помогу ;) — получилась бы достойнейшая альтернатива ZTC.
Или: подключил к агенту шаблон, а на стороне агента автоматом возникли поддерживаемые UserParameter и скрипты. Если бы такое Zabbix мог, было бы круто! В офф.документации появилось описание Zabbix 2.4, может он такое будет уметь…
Ну и я сторонник того, чтобы устанавливать на сервере необходимый минимум. Мне кажется, предложенный мной способ — минимальнее :)
Или: подключил к агенту шаблон, а на стороне агента автоматом возникли поддерживаемые UserParameter и скрипты. Если бы такое Zabbix мог, было бы круто! В офф.документации появилось описание Zabbix 2.4, может он такое будет уметь…
Ну и я сторонник того, чтобы устанавливать на сервере необходимый минимум. Мне кажется, предложенный мной способ — минимальнее :)
Никто не мешает сделать так, например…
В конфиге заббикс агента:
Потом прописываете в puppet, например, в манифесте, который ставит
После этого вся установка nginx вместе с мониторингом будет занимать ровно одну строчку в описании ноды.
В конфиге заббикс агента:
Include=/etc/zabbix/zabbix_agentd.conf.d/Потом прописываете в puppet, например, в манифесте, который ставит
nginx, чтоб он - положил в этот каталог файлик с необходимыми пользовательскими параметрами
- в sites-enabled nginx положил конфиг сервера, который будет отдавать nginx_stats на 127.0.0.1
- запустил скрипт, который через
zabbix APIдобавит необходимый шаблон к вашему хосту - при необходимости — положил нужные скрипты, добавил в крон
- перезапустил заббикс агент
После этого вся установка nginx вместе с мониторингом будет занимать ровно одну строчку в описании ноды.
Не хочется много мест для управления агентами. В Заббиксе уже есть нативный интерфейс управления и было бы хорошо им воспользоваться. Это облегчило бы освоение нашего метода.
Привязали шаблон в Заббиксе к агенту, в шаблоне привязать Макрос, который говорит, какой скриптик надо запустить на клиенте для установки мониторинга. Можно было бы и без puppet'ов всяких обойтись.
Привязали шаблон в Заббиксе к агенту, в шаблоне привязать Макрос, который говорит, какой скриптик надо запустить на клиенте для установки мониторинга. Можно было бы и без puppet'ов всяких обойтись.
На вкладке Actions — Operations можно предусмотреть запуск скрипта на стороне агента.
Но оно делается только когда «Event acknowleged»… тоесть надо создать какую-то проблему прежде — Ивэнт, а потом на этот ивэнт событие сделать — запуск скрипта на стороне агента.
Получится?… вобщем, сейчас буду пробовать…
Для серъезных — да, не обойтись. Но я бы хотел сделать систему легкой для установки начинающими пользователями. А «продвинутые» сами сделают себе все мониторы за 5 минут.
Кинуть скрипты в корень, импортировать шаблоны в Заббикс. Привязал шаблон, установился монитор. Круто было бы…
Но оно делается только когда «Event acknowleged»… тоесть надо создать какую-то проблему прежде — Ивэнт, а потом на этот ивэнт событие сделать — запуск скрипта на стороне агента.
Получится?… вобщем, сейчас буду пробовать…
Для серъезных — да, не обойтись. Но я бы хотел сделать систему легкой для установки начинающими пользователями. А «продвинутые» сами сделают себе все мониторы за 5 минут.
Кинуть скрипты в корень, импортировать шаблоны в Заббикс. Привязал шаблон, установился монитор. Круто было бы…
Мониторинг диска через «sudo /sbin/hdparm -t /dev/vda1» это отличная заявка на победу.
ага, по моему полный бред и не нужная работа. Вполне достаточно смотреть сколько cpu проводит в iowait. У меня триггер на 20%
iowait может быть по множеству причин. Не факт, что винт там будет на первом месте. И не факт, что для всех 20% это правильный порог.
Вопрос в том, что синтетический тест чтения с диска — это для сферических коней в сжиженном вакууме может пригодится. Но автору виднее, может для него это важная метрика ))
Вопрос в том, что синтетический тест чтения с диска — это для сферических коней в сжиженном вакууме может пригодится. Но автору виднее, может для него это важная метрика ))
Да, да — попробуйте сказать хостеру «у меня высокий iowait». Предпологаю ответ «проблема в настройках виртуалки, разбирайтесь».
В моем случае я спрашивал в начале про высокое время генерации страницы, затем про iowait, затем мучал их hdparm. Результат был достигнут в результате последнего, что сказалось на iowait — он упал с 36% до 1.6%. Ну и генерация страниц по данным гугл ускорилась в три-четыре раза.
В моем случае это очень помогло.
К тому же я предупреждаю пользователей об оверхеде: «Хороший параметр, но не снимайте его слишком часто, ведь в эти 3-10 секунд замера диск будет очень занят, рекомендую раз в 10-60 минут, или вообще отключить, если статистика вам понравилась и не будете мучить хостера.»
Так-что не надо тут меня казнить…
В моем случае я спрашивал в начале про высокое время генерации страницы, затем про iowait, затем мучал их hdparm. Результат был достигнут в результате последнего, что сказалось на iowait — он упал с 36% до 1.6%. Ну и генерация страниц по данным гугл ускорилась в три-четыре раза.
В моем случае это очень помогло.
К тому же я предупреждаю пользователей об оверхеде: «Хороший параметр, но не снимайте его слишком часто, ведь в эти 3-10 секунд замера диск будет очень занят, рекомендую раз в 10-60 минут, или вообще отключить, если статистика вам понравилась и не будете мучить хостера.»
Так-что не надо тут меня казнить…
В моем случае я спрашивал в начале про высокое время генерации страницы, затем про iowait
Поубивал бы.
затем мучал их hdparmНадеюсь перед этим не забыли снять всю нагрузку с виртуалки.
К тому же я предупреждаю пользователей об оверхеде:Вот «те кто в теме» и говорят вам что это в принципе не хорошо. А те кто «в первый раз» сначала бездумно запихнут это дело в мониторинг, а потом будут удивляться.
Зы zabbix это система мониторинга, а не тестирования диска. Хотите головками пошуршать? пожалуйста. Только опять же не забудьте всю нагрузку с виртуалки снять.
Так может стоит быть более последовательным?
Во первых, снимать статистику по LA и IOwait.
Во вторых, снимать статистику по дискам из /proc/diskstats и/или iostat
В третьих, мониторить dmesg на ошибки.
И уже при возникновении проблем по этим метрикам проводить какие-то тесты, которые могут повлиять на измеряемые параметры и работу приложений.
Иначе можено дойти до того, что у вас вечь сервер будет покрыт тестами, но работать на нем будет невозможно.
И, кстати, никогда не забивайте разделы диска, сетевые интерфейсы и т.п. в мониторинг руками, пользуйтесь низкоуровневым обнаружением.
Во первых, снимать статистику по LA и IOwait.
Во вторых, снимать статистику по дискам из /proc/diskstats и/или iostat
В третьих, мониторить dmesg на ошибки.
И уже при возникновении проблем по этим метрикам проводить какие-то тесты, которые могут повлиять на измеряемые параметры и работу приложений.
Иначе можено дойти до того, что у вас вечь сервер будет покрыт тестами, но работать на нем будет невозможно.
И, кстати, никогда не забивайте разделы диска, сетевые интерфейсы и т.п. в мониторинг руками, пользуйтесь низкоуровневым обнаружением.
Можно, но это материал для отдельной статьи, т.к. тут hdparm — это лишь пример создания своего монитора, с которым мне пришлось повозиться(надеюсь эти знания не пропадут).
Для основного материала даны готовые скрипты и шаблоны.
Для основного материала даны готовые скрипты и шаблоны.
Кстати как я тут недавно выяснил, стандартные заббиксовые vfs.dev.read и vfs.dev.write снимаются через чтение «этого вашего» /proc/diskstats
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Мониторинг PostgreSQL + php-fpm + nginx + диска с помощью Zabbix