Использую на работке telegraf(мониторинг) + influxdb(где хранить, можно какой-нибудь прометеус вместо него использовать) + grafana(графики в вебе, можно хронограф, более навороченый, у нас его фаервол не пускает) + kapacitor(когда нужны алерты, в целом графана их тоже умеет, только более ограничено).
Для дома netdata зашла, там сразу все, удобно года надо одну машину мониторить
Параллельно с этим держу собственный стэк на ELK+grafana. Пока им не очень доволен, поскольку из эластика нельзя строить процентные графики, для них использую Timelion + плагин для него в графану. Графики оно рисует, но иногда тупит с временными промежуткам и не умеет в алерты. Постепенно пилю и улучшаю, может когда-то буду им доволен.
Там владельца фирмы словом ssh можно только пугать, а с учетом того, что нас всего трое, да и мульены в день не зарабатываем - хочется чтоб каждый член команды мог принять меры, вот хочу мониторинг сделать, бекапы и перезапуск докера.
Домашний сервер, работающий рутером, файлохранилищем, сервером печати, медиасервером и площадкой для опытов. Наиболее важные для мониторинга параметры в данном случае - состояние винтов(smartctl), свободное место, датчики температуры, нагрузка на систему и сеть.
Более пяти лет назад пробовал Nagios, познал дзен ,пока все настроил как надо.
В настоящий момент развернул Zabbix, настроил правила автодискавери для сетевого оборудования + через GPO раскидал на сервера подготовленый агент. Как итог За два дня работы (с подготовкой сервера и конфигурацией агента) Zabbix мониторит более 150 сетевых устройств + около 50 серверов. Все уже со своими шаблонами, комплексными экранами и настроенными аляртами. Единственое думаю еще прикрутить парсер, для полного феншуя.
Из недостатков по сравнению с обзервиумом, не строит сам карту на основе LLDP. Хотя может быть скриптами можно и допилить.
Не возьмусь говорить это модно или нет, но по мне так функционально и лично мне удобно.
Как только пойдете в микросервисы типа Mezos, Kubernetis. Как только пойдут облака типа AWS с эласитити (т.е. счас 10 instances, тут бах и уже 20, и раз - уже 5), Вот тогда вы проклянете свой Zabbix.
Что там из плюсов? Автодискавери? Распределенная инфраструктура, 100 серверов в Usa, 200 в UK, и все в разных VPC, да еще с перекрытиями по IP адресам. Как будите дискаверить? А если это вообще сервис типа SQS? А сервисы в k8s?
Все изменения делать руками или через restAPI? А как же парадигма инфраструктура как код? Пример - выкатываем новый релиз, у нас добавляется Apache (ну вот все работало в nginx) и в новом релизе нам нужно добавить и его мониторинг. Могу я залить в git конфиги и данные, что с выкатом пакета релиза начать мониторить новые сервисы сразу же, причем конфиги взять вот эти? А если откат сделать? Чё, лезть уже удалять зареганные сервисы? Т.е. инфраструктура как код - не работает.
Графики убогие. Нельзя их использовать для инвестигаций как в grafana или kibana.
Итого из недостатков Zabbix
1. Работа через базу. Забываем про гибкость, никакой инфраструктуры как код.
2. Плохая работа с динамическими энвайроментами. Да что там плохая - все через пачку скриптов, и жутко не надежно.
3. Ненужный ныне автодискавери. Если только у вас не завод, где просто нужно 100 серваков смотреть.
4. Не информативные графики, не позволяющие делать анализ ситуаций типа вот тут цпу вырос, ага а тут по сетке проблемы в этот же момент. Только не говорите, что можно grafana прикрутить. Нафига крутить если можно сразу туда гнать всё.
5. Разработка рф. Уже идет в минус. Продайте в европу или сша проект с заббиксом. Могут быть проблемы. Да, бесплатный, да нормальный, но кто-его знает, вдруг там кгб дописало чего... может и смешно, но случаи уже слышал.
icinga2 без агентов, сбор сразу в grafana через нативный плагин.
или prometheus. плюс ELK.
Здравствуйте.
По существу я так понял что вы не сильно разбирались в возможностях забикса. Только не подумайте что я выгораживаю его. То что вы говорите по поводу нового релиза и смены сервисов, все это рещается как раз установленными агентами которые шлют нужную инфу как вы сказали в динамике, есть сервис, есть итемы по нему и тригеры, нет сервиса, нет итемов и тригеров по нему, все это дополняется автодискавери который вы сочли не нужным =) В итогде вся инфраструктура граммотно настраивается один раз и потом только отслеживается наличие бэкапов, что справедливо для любой системы. Далее по пунктам:
1. База данных быть должна, ибо хистори вы где будете хранит? Анализ статистики никто не отменял.
2. Агенты заббикс на любой операционой системы поддерживают сбор данных с использованием переменных окружения, не вижу в этом ключе проблем.
3. Автодискавери может быть вы как-то по другому понимаете, но вот он как раз и нужен для динамической инфраструктуры, дабы не не переделывать все вручную когда соседний отдел решил поменять ее родимую.
4. Комплексные экраны не слышали? Только не те которые статические, от них кстати тоже польза есть, но в другом ключе. А я сейчас про динамические которые формируются шаблонами прикрепленными к хосту.
5. Вот тут вообще странно слышать такое. Ибо если готовится проект, то изачально составляется ТЗ под которое заббикс либо подходит либо изначально предпологается что-то другое. Поэтому размышления изначально не верны. Только если вы продаете не проект а ПО или проект без согласованного ТЗ, то это уже отдельная песня и не нужно тут сваливать все на вендора =)
А что касаемо графаны так она и в Заббиксе есть. Только вот честно я не увидел в ней практического смысла. Ибо красота графиков мне не нужна, информативность графиков добивается не хуже чем в графене с помощью комплексных экранов в шаблонах. Которые использую только при анализе тикетов. А постоянно смотреть на них у меня нет ни времени ни желания, в лучшем случаи отображение интерактивной карты с тригерами по обьектами или линкам между ними. Для всего остального есть оповещение (смс,жабер,мейл).
Как заключение могу сказать что для меня система мониторинга это сервис который вместо меня будет следить за ввереными ему показателями и вот если он что-то найдет не штатное только в этом случаи привлекает мое внимание с предоставлением хистори для анализа. Все остальное время его должно быть не видно и не слышно.
вот смотрите, агенты шлют данные, а нужно ли настраивать заббикс дабы увидеть, что мы имеем? как можно изменить эту конфигурацию? через UI? API? прямо через базу? чем именно можно изменить? руками? самописанной тулой, которая будет следить, что сейчас имеем в проде, деве и т.д.?
1. База данных быть должна, ибо хистори вы где будете хранит? Анализ статистики никто не отменял.
----
что конкретно вы там храните? Лог того, что cpu был 100%?
и что вам это даёт? ну знаете вы что цпу был таким вчера, а сейчас он нормально 1% жрет? алерт вам пришел, а анализ всего проще делать в grafana. Сбор же логов типа nginx - проще в ELK. Только не говорите, что вы в забикс их шлете. Т.е. я не понимаю вообще, что можно логировать в МОНИТОРИНГЕ. Мониторинг это - алерт система, которая должна лишь знать, что происходит.
Т.е. это посути лампочка, с веревочкой. Давление выросло - лампочка загорелась, веревочка дернулась - телеграмма ушла. Что логировать? Письма пришло, остальное в систему логирования.
2. Я здесь не вижу вопроса. Агенты есть и у prometheus. Правда там все проще. В заббиксе вы их настраиваете, а я настраиваю не агенты а конфиг мониторинга. Пофигу на агенты. Просто проставил пакет. А уже там решим, будем мы собирать и как часто. Я считаю это профит.
3.соседний отдел решил поменять? как? просто взял и реконфигурнул? инфраструктура как код. читаем, что так не должно быть. Кроме того, я писал выше - ваш дискавери не будет работать в облаках в различных регионах, зонах и VPC.
4. Комплексные экраны - ну если они могут как Grafana динамически настраиваться, растягиваться, и прочее. А, нет, не могут.
да и не могут они храниться как код (конфиг файл) https://www.youtube.com/watch?v=BC_YRNpqj5k
5. Обсуждать бессмысленно - зависит от клиента... Но некоторые смотрят косо, просто константация факта. Поверьте, если бизнес «дорогой» они даже ELK с Prometheus не будут смотреть. Тут я просто сказал, что слышал.
В итогде вся инфраструктура граммотно настраивается один раз и потом только отслеживается наличие бэкапов, что справедливо для любой системы.
у меня нет инфраструктуры ))) вы никогда не слышали про динамические среды? у меня сегодня 2 сервера в проде может быть, а завтра 2000. какой один раз? У меня до десяти DEV environments, причем завтра они могут быть пересозданы за полчаса, я же написал выше - у меня не завод с 100 серверами.
А вообще я тут подумал, вы, наверное, системный администратор. Поэтому мы говорим о разных подходах. Вам нужно - настроил, под себя, и не трогаем пока работает. И желательно без дикой кастомизации. А я девопс и занимаюсь тем, чтобы сделать инвариантное решение, которое будет работать в облаке, само себя настраивать и без надзора. Эдакий код для мониторинга. Не в обиду, просто подходы действительно разные в случаи облаков, и при работе в крупном офисе «на железе и с железом».