System administration
System Analysis and Design
ITSumma corporate blog
Server Administration
DevOps
Comments 25
+1
Что-то я думал, что это презентация своей системы. Когда начал читать минусы других систем, подумал ну теперь точно будут пиарить свою систему, а тут бац и заключение: «Хотите что-то нормальное — пишите свое.».
-1
Мне из систем мониторинга очень нравится DataDog. Из минусов — сложно настраивать кастомные метрики. Из плюсов — красивые графика, множество интеграций и агентов, частично бесплатный (для ограниченного кол-ва хостов).
-1

Основной минус DataDog — цена. 23$/хост/месяц — дороговато. Понятно, что своя инфраструктура мониторинга тоже стоит денег, но все же на порядок дешевле. Особенно если надо наблюдать за состоянием сотен хостов. Тот же Zabbix + Grafana прекрасно справляются с 1000 хостами\100 000 метриками.
Ну а настраивать всё надо — нет волшебной системы которая сама определит проблему...

0
У нас ранее был на поддержке проект, с круглосуточной поддержкой и критичными для заказчика сервисами. Никакого особенного RocketScience там не было — виндовые службы (и их резервные копии на соседнем сервере), БД Оракл и ее резервная копия, переключалка БД, + не забился ли жесткий диск (логирование же), нет ли проблем с тэйблспейсами — всего 20-25 компонентов на 1 заказчика, заказчиков около 20. Мониторили работоспособность каждого компонента (делали софт сами).
И честно говоря — без нормального описания процессов все это слабо работало. Дело в том, что тот кто следит за мониторингом — либо получает разумное количество сообщений в единицу времени и обрабатывает их, либо получает больше необходимого и на часть забивает. К тому же, у него есть еще и функциональные задачи + какую то часть времени он за мониторингом не следит (например поехал в отпуск или командировку) и мониторинг бесхозный и бесполезный, начинает присылать тонны сообщений.
В итоге, так это и похоронили — слишком сложно для понимания, мало полезно.
Идеальна система мониторинга, которая:
а) не пишет ненужного, а пишет только по делу;
б) суперлегко настраивается (типа развернул сервис, ввел параметры, подцепил процессы и забыл, а не обновлял БД и настраивал таблицы руками);
в) легок в освоении для саппорта (сотрудник отвалился — новый сел, получил письмо и понял что там написано).
Так же клево, когда менеджмент продумал и внедрил систему реагирования на события. Например в отделе работают Вася и Петя. Вася отвечает за мониторинг все будние дни. Петя отвечает за мониторинг все выходные дни, и дни когда Вася в командировке. Если мониторинг присылает письмо с проблемой, ответственный пишет в ответ «Принято в работу, номер тикета в саппорте 31337» и это рассылается на группу. Далее он работает по тикету в рамках текущего процесса поддержки, а когда инцидент решен — пишет в группу — «Инцидент решен — дело было в засорившемся логами диске С; по результатам создана проблема тикет 31338 — анализ использования места на ЖД для сервера N».
Конечно, можно дофига к мониторингу прикрутить — нагрузку ЦП в пике, IO на ЖД, загрузку памяти и т.д. и т.п. — но нужна ли вам реально эта информация — на мой взгляд она отладочная, должна либо в лог писаться, либо это должно быть обнаружено на тестировании.
Мониторить это у заказчика — не знаю, не знаю…
Но статью плюсану, интересно, спасибо.
0
Тема мониторинга в современной ИТ среде не освещена, увы…
И не надо «изобретать велосипед». Есть BMC TrueSight Operations Management, в котором и Infrastructure & Cloud Monitoring, и APM, и End-User Experience Monitoring (Active & Passive), и Artificial Intelligence для анализа данных из разнородных источников и т.д.
0

Спасибо за статью. Поддерживаю комментарий выше про graphite. Мой опыт с мониторингом такой. Сначала InfluxData: telegraf, influxdb. И плюсом Grafana для alert-ов и графиков с таблицами. Telegraf потому, что он умеет мониторить всё, плагинов у него куда больше, чем у Prometeus. А InfluxDB развертывается в один клик на любой платформе. Когда производительности InfluxDB перестаёт хватать, а купить коммерческую версию не получается, тогда уже есть Graphite. В Graphite уже есть масштабирование. Или есть Prometeus, который гордится своим партицированием. Неизменными остаются telegraf, который умеет писать данные в Graphite и Prometeus. И Grafana, которая умеет их читать.


Чтобы иметь теоретическую возможность переехать, не надо в Grafana писать слишком сложные запросы к Influx (я уже успел написать). Чтобы потом не так долго их переписывать под другой синтаксис. А вообще надо бы сравнить скорость работы движков. Не сравнивал ещё. Но проседания скорости работы Influx ощущаю, на стандартных настройках. Её тоже надо уметь тюнить, и запросы в Grafana к Influx надо тоже писать оптимально.


Про информацию о New Relic тоже спасибо. Сейчас доволен работой JavaMelody — APM под Java, свою работу делает, open source. New Relic выглядит интересно — APM под все языки и технологии сразу. Его можно поставить внутри закрытого контура? Или он только как внешний сервис работает?

0
Спасибо за статью. Интересным и удобным показался PromHouse . С немаловажным нюансом — на настоящий момент он не рекомендуется к серьëзному проду. Но сколько возможностей к аналитике — и есть возможность дописать что-то своë специфичное под профиль подлежащих мониторингу процессов.

upd: парсер съел ссылку github.com/Percona-Lab/PromHouse
0
Надеюсь будет продолжение с подробными деталями. Мне кажется, что вопрос мониторинга не в инструменте мониторинга (которые по функционалу все достаточно продвинутые было бы желание этим заниматься), а в четком определении регламентов, метрик, критериев алертов или предиктивного действия — что гораздо сложней. Check_MK закрывает большую часть вопросов любого мониторинга, если рассматривать как программный продукт, внутри её можно делать свои миры на Python. Жни, как-то попроще.
0
Очень поверхностная статья, почему то ни слова о том, что в prometheus есть alert manager, который умеет сильно больше, чем встроенный алертинг в prometheus.
Не говоря уже о том, что если у вас есть grafana с её алертами, у вас может быть любой сторадж под ней от graphite, до opentsdb — события по проблемам настраивать будет проще простого.
0
Спасибо — вот эта книга Effective Monitoring and Alerting, действительно интересная.
0
> Prometheus — отличное решение для сборки огромного количества метрик… И это все очень здорово, но очень неудобно смотреть, поэтому к нему добавляется Grafana.

Так потому страшно и неудобно смотреть, потому что Графану юзать нужно. Я думаю, что так разработчики и хотят.
0
У elastic есть APM мониторинг с недавних пор, он ещё молод конечно но на него думаю имеет смысл поглядовать так как в отличие от того же newrelic он будет self hosted.
0
Appdynamics вроде как денег хочет. в случае с APM от elastic денег платить не нужно за сам APM (нужно за многое другое, но APM бесплатный).
0
У Appdynamics есть кое-что бесплатное типа мониторинга 1 приложения. А Elastic да, крутое решение особенно в свете развития всяких там *beat расширений
0
К сожалению не приведено определение мониторинга. К сожалению многие понимают его по разному.
Only those users with full accounts are able to leave comments. , please.