Comments 43
UFO just landed and posted this here
Достаточно установить Hyper-V роль на одном из серверов, скачать Hyper-V appliance http://www.zabbix.com/download, установить по инструкции и пользоваться.
Особых проблем с установкой не должно возникнуть
Особых проблем с установкой не должно возникнуть
Из личного опыта — Zabbix Server на виртуалке это не очень хорошее решение. На 150+ айтемов в секунду дисковая подсистема умирала (гипервизором служил Xen). После переезда на выделенное железо с теми же ТТХ сейчас обрабатывается в разы больше.
Это уже другой вопрос :) Спросили как поднять Zabbix Server на Windows
Я, к сожалению сталкивался не один раз, когда на одном и том же железе Xen работал медленнее Linux + kvm, VMware или Hyper-V, драйвера и поддержка виртуализации гостем и хостом гостевой ОС всё таки сильно влияют.
Тут скорее вопрос, что используется в качестве дисковой системы. Мониторим сегмент ЦОД, 25 хостов, около 90 виртуалок. Все работает без нареканий, но тут оговорюсь, в качестве дисковой системы используются полноценные СХД.
Есть агенты под Win, так что проблемы быть не должно. К тому же есть специальные механизмы для сбора данных из EventLog'ов Windows, например.
Простите за глупый вопрос.
Вот в примерах (допустим в «система перегружена») есть 2 условия: на вход (где TRIGGER.VALUE = 0) и на выход (где TRIGGER.VALUE = 1)… Там со знаками больше/меньше все правильно?
Вот в примерах (допустим в «система перегружена») есть 2 условия: на вход (где TRIGGER.VALUE = 0) и на выход (где TRIGGER.VALUE = 1)… Там со знаками больше/меньше все правильно?
Всё правильно. При отсутствии проблемы, если минимальный LA за 5 минут больше 3, то триггер срабатывает.
При сработавшем триггере, он остаётся активным, если максимальный LA за последние 2 минуты больше 1.
При сработавшем триггере, он остаётся активным, если максимальный LA за последние 2 минуты больше 1.
Начиная с версии 3.2 есть разделение на условие проблемы и условие восстановления (выхода из проблемы). Макросы {TRIGGER.VALUE} больше не нужны. Несколько примеров: https://www.zabbix.com/documentation/3.2/manual/config/triggers/expression#hysteresis
Мне вот интересно другое. То что для алертов и прочего Zabbix отлично подходит это понятно. Но вот что делать с метриками приложений? Допустим приложение пишет сотни метрик с хоста. По ним нет алерта, но они нужны например аналитику компании. У Zabbix ядро работает с mysql, который я что-то сомневаюсь что выдержит такие нагрузки, особенно когда таких приложений десятки. Я так понимаю что выгоднее в этом случае использовать что-то более предназначенное для таких сценариев, вроде Prometheus или InfluxDB.
Может есть уже готовые подобные связки или плагины для Zabbix?
Может есть уже готовые подобные связки или плагины для Zabbix?
Zabbix умеет выгребать практически любые данные с хоста. И работать с Postgres. Думаю у вас задача стоит не как выгрести миллионы событий в секунду, а как их правильно сгруппировать на клиенте и вытягивать разумное число раз.
Ну, грубо говоря, приложение генерит кучу разных бизнес-метрик, их реально может быть много. То что их требуется прям каждую секунду смотреть я конечно не скажу. Но их желательно все сохранять и потом анализировать.
Собирайте среднее\макс\мин на клиенте (просто не в курсе что именно вам важно) и вытягивайте раз в 10 секунд, например, в заббикс сервер, зачем вам для этого высокопроизводительная БД?
Я просто нагрузку прикидываю. У меня сейчас графит жарит в RAM диск порядка 350 тысяч метрик, не знаю уж, в минуту или в секунду (вряд ли). Я боюсь mysql тупо загнется с такой нагрузкой. Конечно у меня метрики шлются каждые 10 секунд и весьма вероятно их так часто слать не надо. Я пытаюсь понять в какую сторону двигаться.
350 тыс метрик или тысячи значений для нескольких метрик? С трудом себе представляю 350 тыс разных метрик…
Ну это не так уж сложно, вопрос в размере инфраструктуры и детализации. С одного среднего коммутатора вполне можно брать 1-2 тысячи метрик не особо увлекаясь. А идеология того же графита говорит о том что собирать нужно максимум возможного чтобы когда эта информация потребуется она уже была.
Ну вот пример, бизнес-задача выполняется пакетными заданиями. Каждое задание генерит какой-то набор метрик — выполнено/запланировано, получено/отправлено и т.п. ну допустим где-нибудь десяток-другой метрик. Но самих заданий выполняется за час тысячу. Конечно у заданий есть свои классы. Вот хотя бы по классу заданий неплохо бы видеть картину происходящего, чтобы аналитик мог их корректировать и т.д. А еще это все надо уметь агрегировать, графики строить и т.п.
Zabbix не замена графиту. На среднем сервере 1000 значений в секунду для заббикса уже много. Основное отличие и плюс графита — RRD базы в разы лучше работающие со сбором подобного рода информации.
При большом объеме загружаемой в Zabbix информации как минимум нужно использовать партиционинг чтобы избежать лишней нагрузки от хаускипера (удаление старых данных). И все равно такие объемы метрик как в графите будут нереальны.
По моему опыту в заббикс имеет смысл лить то на чем построены тригеры + немного «справочной» информации (не перебарщивая), а разного рода метрики действительно удобнее иметь в графите или чем-то подобном с RRD базами.
При большом объеме загружаемой в Zabbix информации как минимум нужно использовать партиционинг чтобы избежать лишней нагрузки от хаускипера (удаление старых данных). И все равно такие объемы метрик как в графите будут нереальны.
По моему опыту в заббикс имеет смысл лить то на чем построены тригеры + немного «справочной» информации (не перебарщивая), а разного рода метрики действительно удобнее иметь в графите или чем-то подобном с RRD базами.
Метрики неплохо собираются набором ELK, например.
Или просто тем же Carbon + Graphite, как, допустим, у меня сейчас на тестовом кластере.
Некоторые современные пакеты п/о сами изнаачально умеют слать метрики в Carbon, например PowerDNS
Очень сложная в настройке системе и очень прожорливая в ресурсах.
Мелкие ISP выбирают системе попроще, типа cacti и/или nagios.
Мелкие ISP выбирают системе попроще, типа cacti и/или nagios.
Cacti не умеет в алерты, только картиночки смотреть. Не SNMP там боль. Уж лучше Ganglia тогда.
Смотря с чем сравнивать.
Если сравнивать с продуктами линейки TrueSight, от той же BMC — то Zabbix выглядит как простая легковесная (как в настройке так и в эксплуатации) система.
И в то же время по функционалу (реальному, который несет бизнесу некоторый value) уступает совсем немного.
Для мелких компаний, с десятком серверов Zabbix (как и BMC) может быть действительно не актуален. Там и что-то типа Monit справится и даст тот же результат, что и Zabbix.
Но когда серверов тысячи или десятки тысяч или сотни тысяч — то Zabbix начинает выигрывать как минимум по стоимости лицензий: общая стоимость владения выходит на порядок (или даже более) дешевле, чем у «тяжелых» систем, при том, что ключевые проблемы им решаются.
Если сравнивать с продуктами линейки TrueSight, от той же BMC — то Zabbix выглядит как простая легковесная (как в настройке так и в эксплуатации) система.
И в то же время по функционалу (реальному, который несет бизнесу некоторый value) уступает совсем немного.
Для мелких компаний, с десятком серверов Zabbix (как и BMC) может быть действительно не актуален. Там и что-то типа Monit справится и даст тот же результат, что и Zabbix.
Но когда серверов тысячи или десятки тысяч или сотни тысяч — то Zabbix начинает выигрывать как минимум по стоимости лицензий: общая стоимость владения выходит на порядок (или даже более) дешевле, чем у «тяжелых» систем, при том, что ключевые проблемы им решаются.
Но когда серверов тысячи или десятки тысяч или сотни тысяч
Стоп, это уже редкость.
Да почему же редкость!
Даже сотня другая третья серверов, виртуалок, приложений, микросервисов, сетевых устройств, датчиков с snmp-интерфейсами или любых других объектов в инфраструктуре (заббиксу все равно что именно мониторить) — это далеко не редкость! Это по сути масштаб средненького ИТ-проекта.
И уже на таком масштабе Zabbix становится оправданным. Не говоря о любой энтерпраз-инфраструктуре, где всего разного еще на порядок больше. Стоит только присмотреться.
Даже сотня другая третья серверов, виртуалок, приложений, микросервисов, сетевых устройств, датчиков с snmp-интерфейсами или любых других объектов в инфраструктуре (заббиксу все равно что именно мониторить) — это далеко не редкость! Это по сути масштаб средненького ИТ-проекта.
И уже на таком масштабе Zabbix становится оправданным. Не говоря о любой энтерпраз-инфраструктуре, где всего разного еще на порядок больше. Стоит только присмотреться.
У вас проблемы с оценкой количеств метрик.
Для этого с головой хватит cacti.
Если IOPS и памяти хватит :)
Даже сотня другая третья серверов, виртуалок, приложений, микросервисов, сетевых устройств, датчиков с snmp-интерфейсами или любых других объектов в инфраструктуре
Для этого с головой хватит cacti.
заббиксу все равно что именно мониторить
Если IOPS и памяти хватит :)
Попробуйте Ganglia. Как раз для сотен тысяч серверов.
Попробуйте Ganglia.
Последняя версия 3.7.1 (1 апреля 2015)
Кто поддерживать будет?
Плюсану за сложную систему, особенно хардкорно триггеры создавать. :)
Честно сказать не вижу конструктива в ваших комментариях, по этому становится не интересно вести диалог. И на большее, чем кратенько ответить на комментарий интереса уже нет.
У вас проблемы с оценкой количеств метрик.
нет у меня никаких проблем, у меня все отлично :)
Для этого с головой хватит cacti.
по каким критериям вы решили что "хватит"? ведь у разных людей могут быть разные требования к системе.
Если IOPS и памяти хватит :)
а разве Zabbix потребляет много ресурсов? а много это сколько?
Очень интересная фишка Zabbix это тригеры по истории. Но это являеться и не достатком. Для тригеров по истории нужна история в DB Zabbix. Для тригеров важны актуальные данные. В сумме получается непрерывный поток горячих данных, которые сохраняются в DB Zabbix. Отсюда высокие требования к СХД. Желательно реализовать «партиционирование»(если не путаю термин). Это откровение бывает растраивает тех, кто пытаесь «бесплатно» внедрить мониторинг для относительно крупнных инсталяций и параноей мониторить все раз в секунду.
А если еще поднять вопрос отказоустойчивости. Какой допустимый минимальный простой системы мониторинга? Резервное копирование сервера и базы данных? А большая часть внедрения, это постановка на мониторинг ИТ-инфраструктуры как сервисов.
Для системы мониторинга тоже актуальны такие вещи как: Согласования, разработка, внедрение, документирование, поддержка, развитие. И допущенные технические просчеты на этапе внедрения будут увеличивать сложность обслуживания в продуктиве.
А если еще поднять вопрос отказоустойчивости. Какой допустимый минимальный простой системы мониторинга? Резервное копирование сервера и базы данных? А большая часть внедрения, это постановка на мониторинг ИТ-инфраструктуры как сервисов.
Для системы мониторинга тоже актуальны такие вещи как: Согласования, разработка, внедрение, документирование, поддержка, развитие. И допущенные технические просчеты на этапе внедрения будут увеличивать сложность обслуживания в продуктиве.
Вы пытаетесь жонглировать данными, но как только привели конкретные цифры, сразу сфейлились, что не в теме. Ни в телекоме, ни в DevOps.
Настройка Zabbix — очень увлекательное творческое занятие, причем толковой документации очень мало, скорее надо читать примеры внедрения и делать выводы в применении к своей ситуации.
Sign up to leave a comment.
Правильное обнаружение проблем с помощью Zabbix