LINUX.ORG.RU

Zabbix 3.0

 ,


1

0

Zabbix — это программное обеспечение для мониторинга многочисленных параметров сети, жизнеспособности и целостности серверов. Zabbix использует гибкий механизм оповещений, что позволяет пользователям конфигурировать уведомления основанные на e-mail практически для любого события. Это позволяет быстро реагировать на проблемы с серверами. Zabbix предлагает отличные функции отчетности и визуализации данных основанные на данных истории. Это делает Zabbix идеальным для планирования мощности.

Изменения в версии 3.0:

  • Новый веб-интерфейс.
  • Поддержка шифрования.
  • Прогнозирующие функции триггеров.
  • Опции SMTP аутентификации.
  • Проверка элемента данных в заданное время.
  • Поддержка пользовательских параметров в скриптах оповещения.
  • Приватные карты сети, комплексные экраны и слайд-шоу.
  • Экспорт и импорт преобразований значений.
  • Зависимости между прототипами триггеров.
  • Улучшения в производительности.
  • Поддержка нескольких OID в обнаружении SNMP.
  • Привязка групп элементов данных на основе значения обнаружения.
  • Улучшения в графиках.
  • Прозрачное раскрытие пользовательских макросов.
  • Автоматически выбор режима инвентарных данных узлов сети.
  • Массовое подтверждение сделано более гибким.
  • Улучшения в VMware мониторинге.
  • Поддержка контекста в пользовательских макросах.
  • Запуск Zabbix демонов в фоновом режиме.
  • Улучшения в веб-интерфейсе.
  • Улучшения в демонах.
  • Изменения/улучшения в элементах данных.
  • Улучшения в функциях.
  • Улучшения в макросах.
  • Улучшения в утилитах командной строки.
  • Улучшения в API.
  • Различные улучшения.

>>> Скачать Zabbix

>>> Подробности на русском

>>> Подробности на английском



Проверено: JB ()
Последнее исправление: ymn (всего исправлений: 2)

remoting-jmx уже поддерживается? мониторинг одинаковых сервисы на разных портах уже поддерживается? нет, они кнопочки блджад в веб-интерфейсе перерисовывали. клоуны

anonymous
()
Ответ на: комментарий от anonymous

Красивые картинки и графики, хотел поставить ...

... Graphite

LynxChaus
()
Ответ на: комментарий от alexvl

реально старый интерфейс был компактнее. На маленьком экране новый интерфейс неудобен.

apmucm
()

Запуск Zabbix демонов в фоновом режиме.

Мухахахаа.. я уж думал это jarvis англицким не владеет. А это оказывается такая документация про заббикс - foreground это «на переднем плане» а не в фоновом (background) режиме.

@alexvl - наймите блин корректора с нормальный русския языка, у вас в чего нового - лажа на лаже местами.

LynxChaus
()
Ответ на: комментарий от anonymous

Чем оно полезно для домашнего юзера?

Ничем, для локалхоста это оверкилл, есть более лёгкие вещи типа monit.

selivan ★★★
()
Ответ на: комментарий от NightOperator

Кстати по триггерам - множественные уровни важности триггеров уже запилили или всё также требуются костыли, чтобы в зависимости от того, какое именно условие сработало, покрасить одну и ту же ячейку в разные цвета?

Я бы сделал на каждой условие отдельный триггер с разной важностью.

selivan ★★★
()
Ответ на: комментарий от zloelamo

Любители забикса, а у вас есть инструкция для начинающих: «Как настроить забикс и не офигеть от мышкотыканья»

Там есть API, к нему наверняка есть модули для chef/puppet/... В ansible 2.0 тоже какие-то модуля для заббикса появились, но там пока не всё, что нужно.

selivan ★★★
()
Ответ на: комментарий от alexvl

А тёмная не подходит?

У меня, например, 3 заббикса. Очень удобно, если у каждого - своя тема....

+1 за оранжевую тему.

EuGeneus ★★
()
Ответ на: комментарий от Pronin

Можешь не тыкать мышой, а редактировать templates прямо в vim.

в mcedit сильно удобнее

в принципе комплексные экраны сос ведением кучи сетей удобнее через export/edit/import делать

EuGeneus ★★
()
Ответ на: комментарий от selivan

Я бы сделал на каждой условие отдельный триггер с разной важностью.

все так и делают, типовое решение

EuGeneus ★★
()
Ответ на: комментарий от alexvl

Она темно-СИНЯЯ, а хотелось бы темно-ОРАНЖЕВУЮ как в старой версии. Себе я поправил css , но из коробки было бы лучше.

apmucm
()
Ответ на: комментарий от EuGeneus

У меня, например, 3 заббикса. Очень удобно, если у каждого - своя тема....

Хорошая идея! Конечно, не полноценная замена, но можно также устанавливать различные лого (меняя CSS) и имя сервера в конфиге.

alexvl
()
Ответ на: комментарий от selivan

Это сильно захламляет веб-интерфейс. Он у меня постоянно открыт на мониторе справа и отследить изменение цвета видимой ячейки намного проще, чем той, которая погребена под множеством других строк ячеек и требует прокрутки. К тому же для некоторых параметров (например температуры) это просто удобнее, если ячейка меняет цвет от зелёного к жёлтому, оранжевому, красному, чем наблюдать один и тот же параметр в разных ячейках.

NightOperator ★★★
()
Последнее исправление: NightOperator (всего исправлений: 1)
Ответ на: комментарий от itn

Я вот только обновился с 2.2 на 2.4 с бэкпортс. Часть триггеров не отображается теперь в обзоре, хотя они включены.

leg0las ★★★★★
()
Ответ на: комментарий от alexvl

можно также устанавливать различные лого (меняя CSS) и имя сервера в конфиге.

Особое logo обязательно ставится на праздники ;)

На новый год было, что будет на это 1-е апреля - ещё не знаю.

EuGeneus ★★
()
Ответ на: комментарий от leg0las

Я вот только обновился с 2.2 на 2.4 с бэкпортс.

Очень советую подключить ветки от zabbix и postgres. Действовать аккуратно, вдумчиво, с бэкапами.

deb http://repo.zabbix.com/zabbix/2.2/debian wheezy main

deb http://mirror.yandex.ru/wheezy-pgdg/ wheezy-pgdg main

Ну, в вашем случае видимо будет

deb http://repo.zabbix.com/zabbix/2.4/debian wheezy main

EuGeneus ★★
()
Последнее исправление: EuGeneus (всего исправлений: 1)
Ответ на: комментарий от EuGeneus

Да я уже разобрался с триггерами. он не отображается (строка) до тех пор, пока один из элементов не поменяет значение триггера, тогда он появляется в обзоре. Багофича типа, но главное то, что я увижу проблему, если она возникнет.

Обновляться на 3.0 пока не буду.

leg0las ★★★★★
()
Последнее исправление: leg0las (всего исправлений: 1)
Ответ на: комментарий от Pronin

Это обычные xml-ки.

Ну, блин спасибо. Всю жизнь мечтал этим заниматься: редактировать xml. Кроме того, там же не только темплейты приходится натыкивать.

zloelamo ★★★★
()

Номальные зависимости сделали? Или по прежднему, если «А» зависит от «Б», то велика вероятность что все равно сработают оба тригера и придет 2 смски.

swelf
()
Ответ на: комментарий от zloelamo

Я не страдаю, что из сотен систем мониторинга видел только десяток ;)

Таки да, munin в список не попал - да и эта тема не про него.

У Zabbix огромный плюс - возможность купить хороший суппорт для решения своих экзотических хотелок (руководство хочет? = руководство платит)

P.S. Кактуса и Заббикса мне хватает для моих задач

EuGeneus ★★
()
Последнее исправление: EuGeneus (всего исправлений: 1)
Ответ на: комментарий от EuGeneus

У меня сейчас 2.2.3 и ничего не работает. Ты уверен что правильно меня понял? Или я чегото не понимаю. Рассмотрим пример, какойто параметр у нас отслеживается раз в 30 секунд на 2х девайсах, пускай они просто пингуются.

«А» стоит за «Б» и зависит от него. В идеале, если пропалает связь до «Б», то уведомление о проблеме от «А» не должно приходить. Но приходят зачастую оба, потому что легко может случиться так, что заббикс обнаружит сначала проблемы с «А», а потом уже проблемы с «Б».

swelf
()
Последнее исправление: swelf (всего исправлений: 1)
Ответ на: комментарий от EuGeneus

Что изменится в 2.2.9?

А если у меня в цепочке зависимостей 10 тригеров, и они добавляются шаблонами? в итоге у меня на 10м тригере будет время срабатывания в 300 секунд вместо 30?

swelf
()
Ответ на: комментарий от swelf

Если цепочка зависимостей/условий сложная - то уже пора данные собирать скриптом и им же принимать решения. Потом скормить результат zabbix-у удобным способом.

До 3.0 нет возможности указать временную точку сбора данных для item.

EuGeneus ★★
()
Ответ на: комментарий от EuGeneus

Проще скрипт уведомления модифицировать, чтобы он ориентируясь на триггеры решал слать sms,email или нет. Сейчас я сделал костыль в виде дополнительного тригера с более коротким временем срабатывания и сложной системой зависимостей, и все вроде ок. Лишние тригеры не зажигаются, лишние уведомления не летят. Но идеально было бы, чтоб тригеры горели на панели, а уведомления не летели.

swelf
()
Ответ на: комментарий от NightOperator

К тому же для некоторых параметров (например температуры) это просто удобнее, если ячейка меняет цвет от зелёного к жёлтому, оранжевому, красному

Интересный юз-кейс, но редкий, в основном всем кучи триггеров хватает. Вряд ли запилят, разве что сам патч пришлёшь.

selivan ★★★
()
Ответ на: комментарий от selivan

Не сильно редкий.

Я сейчас думаю, как сделать зависимость одних триггеров от других - вероятно я буду их «красить» через zabbix-api

EuGeneus ★★
()
Ответ на: комментарий от selivan

Сюда подходит не только температура, но и другие аналогичные параметры - например в нашей организации заббикс-агент стоит также на рабочих станциях, где мониторит в т.ч. свободное место на дисках. Когда оно заканчивается, требуется реакция кого-то из сотрудников техподдержки. Но реакция может быть срочной или нет в зависимости от того сколько места осталось и где - т.е. если меньше 100мб на системном диске, то надо решать проблему срочнее, чем если меньше 1 гб на диске с документами. Разбивать данные по месту на каждой станции на отдельные ячейки и выставлять сотни триггеров с разной важностью здесь неудобно.

Есть другой, также часто встречающийся у меня пример: несколько серверов выполняют одну задачу (шлюзы, виртуализация, терминальный и др.). Если становится недоступен один, то это не критично, но требует внимания и устранения проблемы в плановом порядке. Если становятся недоступны сразу несколько и прекращается предоставление сервиса, то требуется срочная реакция. В этом случае также хочется видеть в одной ячейке данные о состоянии предоставления сервиса, например зелёный - сервис предоставляется, доступны все сервера; оранжевый - сервис предоставляется, но какие-то недоступны и т.д. Патч может быть и пришлю, если не сделают раньше меня, но таких примеров можно привести ещё много, т.ч. я не думаю, что ситуация редкая и это нужно только мне.

NightOperator ★★★
()
Последнее исправление: NightOperator (всего исправлений: 3)

Крайне неудобная система.

1) Сбор данных и отправка их на сервер сделана топорно. Нельзя для каждого параметра делать свое tcp-соединение и запрос. Должен быть сервис, который собирает снимаемые параметры от агентов и отправляет скопом по одному постоянному соединению на сервер мониторинга. А то, как сейчас сделано - жрет много ресурсов на самой станции, на коммутаторах, на фаерволах, и вызывает задержки. Получается такая же проблема, как с увлечением антивирусами - антивирус в итоге жрет больше ресурсов, чем приложение. А за все это надо платить более мощной техникой.

2) Еще лет 15 назад пользовался системой мониторинга, где концепция графического представления была не в виде таблицы с ячейками, а в виде полноценной схемы системы с серверами, связями между ними, с подсистемами. Подводишь мышь к объекту - видишь сведения о ней, параметры и т.п. Т.е. полноценная система мониторинга должна выглядеть как центр управления в ГазПроме - огромный экран с картой страны/региона и труб, хранилищ, насосов... Вышла одна нитка газопровода из строя (насос отказал и т.п.) - переключили на резервную нитку и отправили бригаду устранять неисправность.

Когда где-то происходит сбой (сервер, сервис, приложение, соединение/связь) - выделяется определенным цветом, морганием, всплывающим окошком. Причем надо выделять - где именно источник сбоя, а где проблемы работы являются лишь следствием сбоя в цепочке раньше. Если не видеть и не понимать этого, то администраторы теряют время на борьбу со следствием, а не с причиной. Админы даже понять не могут, связаны ли несколько сбоев в системе между собой или это разные проблемы - соответственно будет неверная стратегия ее устранения. Подводишь мышь и видишь - что за сбой. Нажимаешь - получаешь сведения более детально. Хочешь отследить историю по объекту, параметру - смотришь в виде таблицы с событиями в хронологическом порядке. Хочешь видеть хронологию в целом - проматываешь графическое представление пошагово по событиям в ней, в итоге можешь отследить, как развивался отказ системы. В мониторинге не должно быть намешано все в одну кучу. Должна быть возможность фильтровать мониторинг прикладной части от системной и сетевой, если функции контроля разделены.

Админ с такой системой мониторинга будет сидеть как в ЦУПе и видеть на большом экране всю систему в целом вместе с взаимосвязями между всеми ее элементами. При этом его не грузят кучей цифр и списком параметров - он видит живую систему целиком и ее самочувствие в целом. Если все нормально, то зачем ему лишнее? Если же произойдет сбой - он сразу видит, где отказало, что именно и как оно влияет на работу системы в целом. Админу не надо лезть в какие-то документации - все на ладони и все понятно. Систему неплохо дополнить Базой Опыта. В привязке к конкретной ситуации сбоя можно впоследствии описать - что там было и как это устраняли. Тогда при следующем аналогичном сбое уже можно просто кликнуть мышью и получить готовую инструкцию. Есть еще много подобных моментов, крайне удобных в эксплуатации... Вот такая система мониторинга будет настоящей. А zabbix - крайне неудобный продукт, годный системному админу, которого интересует только работа отдельных серверов, а не эффективное функционирование системы в целом, тем более на уровне приложений. В конечном итоге ведь важна работоспособность внешнего функционала системы, а не какие-то отдельные системные проблемы на сервере, которые вполне нивелируются кластерной технологией или резервированием.

Iremel36
()
Ответ на: Крайне неудобная система. от Iremel36

Сбор данных и отправка их на сервер сделана топорно. Нельзя для каждого параметра делать свое tcp-соединение и запрос.

Активные проверки с буфферизацией на агенте лишены этого недостатка. Прокси позволяют накапливать данные собранные удалённо и эффективно их отправлять большими кусками.

Еще лет 15 назад пользовался системой мониторинга, где концепция графического представления была не в виде таблицы с ячейками, а в виде полноценной схемы системы с серверами, связями между ними, с подсистемами.

Рисуем карту с объектами и связями между ними, привязываем к её элементам проблемы-индикаторы, и сразу видим общую картину.

Если что-то отвалилось и надо решать проблему в ручном режиме, то кликаем на объект и выполяем действия: презапустить, перейти на резервный канал и т.д.

Причем надо выделять - где именно источник сбоя, а где проблемы работы являются лишь следствием сбоя в цепочке раньше.

Для этого существуют IT Services, которые позволяют описывать структуру сервисов, их зависимости друг от друга и нижнего уровня (триггеры).

К сожалению, для сервисов пока нет графического представления, рано или поздно появится.

Систему неплохо дополнить Базой Опыта. В привязке к конкретной ситуации сбоя можно впоследствии описать - что там было и как это устраняли. Тогда при следующем аналогичном сбое уже можно просто кликнуть мышью и получить готовую инструкцию.

В Zabbix эту роль играет описание триггера, которое может содержать детальную пошаговую инструкцию по решению проблемы. Она может отправляться и по емайлу. Макрос {TRIGGER.DESCRIPTION}, чтобы было легче найти интересующимся.

Zabbix'у есть куда расти, как в горизонтальном направлении (существующий функционал), так и в новые области. Видимо поэтому и выходят новые версии.

alexvl
()
Ответ на: комментарий от zloelamo

Всю жизнь мечтал этим заниматься: редактировать xml

Не хочешь редактировать XML-ки и тыкать мышкой - пиши скрипты...
А как это в Nagios устроено?
Или нужно модуль телепатии встраивать?

Pronin ★★★★
()
Последнее исправление: Pronin (всего исправлений: 1)
Ответ на: комментарий от zloelamo

я не фанат заббикса, но у него настройки выгружаются в xml. и загружаются обратно таким же образом. а править их можно хоть руками, хоть скриптами.

Iron_Bug ★★★★★
()
Ответ на: комментарий от Iron_Bug

Это сложный вопрос. Нормальные файлы парсить трудно, но легко править руками. XML парсить легко, но трудно править. При этом генерировать по шаблону просто и первое и второе.

zloelamo ★★★★
()

А в чём отличие 3.0 от 3.2? Я что-то так и не понял.

generator ★★★
()
Ответ на: комментарий от alexvl

Активные проверки с буфферизацией на агенте лишены этого недостатка.

У них, как и у остального заббикса есть один фатальный недостаток - хреново документированны. Вот никто и не знает про эту волшебную возможность.

Прокси позволяют накапливать данные собранные удалённо и эффективно их отправлять большими кусками.

Для прокси нужно гораздо больше места. И какой-никакой SQL. А не везде есть возможность запихать монстрика.

В Zabbix эту роль играет описание триггера

Ага. А если триггер из темплейта, мы имеем на 1000 триггеров один-и-тотже дескрипшин.

LynxChaus
()
Ответ на: комментарий от LynxChaus

У них, как и у остального заббикса есть один фатальный недостаток - хреново документированны. Вот никто и не знает про эту волшебную возможность.

Да все знают как-бы...

Для прокси нужно гораздо больше места. И какой-никакой SQL. А не везде есть возможность запихать монстрика.

Ой да ладно, у меня все прекрасно работало на минимальном центосе с hdd на 8гб и 2 гб RAM, стоял mysql. На каждой висело порядка 2к хостов.

phoen ★★
()
Ответ на: комментарий от LynxChaus

Для прокси нужно гораздо больше места. И какой-никакой SQL. А не везде есть возможность запихать монстрика.

Используйте SQLite. На Raspberry Pi таким прокси сможете мониторить пару сотен устройств с помощью Zabbix агентов. И никаких «монстров» MySQL, PostgreSQL или Oracle не нужно.

alexvl
()
Ответ на: комментарий от pinachet

скорее всего. Но это делается только на сервере. Один раз можно и обновится.

snaf ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.