Comments 25
Основной минус DataDog — цена. 23$/хост/месяц — дороговато. Понятно, что своя инфраструктура мониторинга тоже стоит денег, но все же на порядок дешевле. Особенно если надо наблюдать за состоянием сотен хостов. Тот же Zabbix + Grafana прекрасно справляются с 1000 хостами\100 000 метриками.
Ну а настраивать всё надо — нет волшебной системы которая сама определит проблему...
И честно говоря — без нормального описания процессов все это слабо работало. Дело в том, что тот кто следит за мониторингом — либо получает разумное количество сообщений в единицу времени и обрабатывает их, либо получает больше необходимого и на часть забивает. К тому же, у него есть еще и функциональные задачи + какую то часть времени он за мониторингом не следит (например поехал в отпуск или командировку) и мониторинг бесхозный и бесполезный, начинает присылать тонны сообщений.
В итоге, так это и похоронили — слишком сложно для понимания, мало полезно.
Идеальна система мониторинга, которая:
а) не пишет ненужного, а пишет только по делу;
б) суперлегко настраивается (типа развернул сервис, ввел параметры, подцепил процессы и забыл, а не обновлял БД и настраивал таблицы руками);
в) легок в освоении для саппорта (сотрудник отвалился — новый сел, получил письмо и понял что там написано).
Так же клево, когда менеджмент продумал и внедрил систему реагирования на события. Например в отделе работают Вася и Петя. Вася отвечает за мониторинг все будние дни. Петя отвечает за мониторинг все выходные дни, и дни когда Вася в командировке. Если мониторинг присылает письмо с проблемой, ответственный пишет в ответ «Принято в работу, номер тикета в саппорте 31337» и это рассылается на группу. Далее он работает по тикету в рамках текущего процесса поддержки, а когда инцидент решен — пишет в группу — «Инцидент решен — дело было в засорившемся логами диске С; по результатам создана проблема тикет 31338 — анализ использования места на ЖД для сервера N».
Конечно, можно дофига к мониторингу прикрутить — нагрузку ЦП в пике, IO на ЖД, загрузку памяти и т.д. и т.п. — но нужна ли вам реально эта информация — на мой взгляд она отладочная, должна либо в лог писаться, либо это должно быть обнаружено на тестировании.
Мониторить это у заказчика — не знаю, не знаю…
Но статью плюсану, интересно, спасибо.
И не надо «изобретать велосипед». Есть BMC TrueSight Operations Management, в котором и Infrastructure & Cloud Monitoring, и APM, и End-User Experience Monitoring (Active & Passive), и Artificial Intelligence для анализа данных из разнородных источников и т.д.
Спасибо за статью. Поддерживаю комментарий выше про 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 под все языки и технологии сразу. Его можно поставить внутри закрытого контура? Или он только как внешний сервис работает?
upd: парсер съел ссылку github.com/Percona-Lab/PromHouse
Не говоря уже о том, что если у вас есть grafana с её алертами, у вас может быть любой сторадж под ней от graphite, до opentsdb — события по проблемам настраивать будет проще простого.
Тема освещена достаточно неплохо:
— shop.oreilly.com/product/0636920025986.do
— shop.oreilly.com/product/0636920050773.do
— Плюс несколько глав из этой книги: shop.oreilly.com/product/0636920041528.do
Так потому страшно и неудобно смотреть, потому что Графану юзать нужно. Я думаю, что так разработчики и хотят.
Прочёл свободно доступную первую главу «Анти-паттерны»: conferences.oreilly.com/velocity/vl-ca/public/content/practical-monitoring, этого мне хватило. Содержимое перекликается с комментариями и дополняет тему статьи.
Организация системы мониторинга