LLD, его использование и лично ваша идеология

[satoo]

День добрый

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

Мы мониторим обычные/рабочие сервера, ПК и сетевое оборудование. Под обычными я понимаю не тестовые сервера, которые создаются пачками (а также внутри их создаются диски, службы и пр) и так же пачками удаляются. В основном используем стандартные шаблоны, где надо - дописываем свои. Мониторим, в основном, дефолтными шаблонами (т.к. они в большинстве решают наши задачи), без каких-то сильных "загонов".

Что сейчас "напрягает".
На виртуализаторах, порой, диски меняют свои индексы. Соответственно, lld находит новый диск, а старый перестаёт видеть. Таким образом, как минимум, теряется история мониторинга диска.

Создавать вручную ~10 элементов на один диск не хочется по многим причинам, человеческий фактор в том числе. Кроме того, хочется видеть новые диски - не исключена ситуация, что диск был добавлен без предупреждения, стал рабочим, а потом "что-то пошло не так ", т.е. "автопоиск" очень желателен.

Что-то подобное по коммутаторам. Не все железки позволяют называть свои интерфейсы внутри себя, а некоторые интерфейсы для удобства называть нужно. Если использовать lld шаблоны, то там мы ничего не можем изменить, а бывает очень нужно.

Поделитесь, если не сложно, как вы используете lld/мониторите рабочие сервера/станции/железки?

[Артём Мамзиков]

satoo, Добрый вечер.

На виртуализаторах, порой, диски меняют свои индексы. Соответственно, lld находит новый диск, а старый перестаёт видеть. Таким образом, как минимум, теряется история мониторинга диска.

Каким образом они мониторятся через snmp, специализированной утилитой от производителя сервера ?
Либо стандартным шаблоном из коробки через агента ?
Или что то вроде smartmontools что очень вряд ли если это raid.
На уровне железа сервера на котором подняты виртуалки диски не меняются id не должен меняться , если диск вышел из строя и его заменили аналогичным он быстрее всего будет, новым id хотя может быть и старым просто получит новые данные по диску в этом слоте.

Варианты на вскидку
Можно в lld поставить после потери диска не удалять элементы 90 дней и можно по ним историю смотреть, такой себе вариант.
Либо запилить какой то скрипт который в БД будет менять id диска если он изменился, но серийник диска совпадает, муторно надо разбираться и тестить. Либо сделать привязку не к id, а серийному номеру диска и создавать элементы данных, но запрос наверное все равно идет по id.

Или речь идет уже не о СМАРТ, а нагрузке диска, свободного места.

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

Тут авто обнаружение в целом само работает, появился новый диск встал на мониторинг и если что то не так сработает триггер.

Тут я думаю в обнаружении сделать пред обработку на javascript и руками к номеру порта добавить описание и выводит в макрос в имя триггера.

Предобработка JavaScript - JS в Zabbix
можно задать входные данные, то что это javascrit , хотим на выходе получить и запросить в GPT чате, в целом не плохие решения дает.
называть свои интерфейсы внутри себя

[satoo]

Если конкретно по дискам, то мониторится через агента, через родной шаблон windows.

Там может быть такой айтем:

perf_counter_en["\PhysicalDisk(2 F:)\Disk Writes/sec",60]

И после определенных операций номер диска может измениться. Понятно, что lld найдет новый диск и поставит его на мониторинг, но потеряется история по "старому" диску (на самом деле одному и тому же).

Тут авто обнаружение в целом само работает, появился новый диск встал на мониторинг и если что то не так сработает триггер.

Это тоже понятно, но lld получается "дубовый". С одной стороны - используем lld и теряем историю, если меняются номера дисков, с другой стороны - делаем все вручную и можем получить человеческую ошибку... Как-то не очень.

Либо запилить какой то скрипт который в БД будет менять id диска если он изменился, но серийник диска совпадает, муторно надо разбираться и тестить.

возможно это подойдет (запуск вручную), но в бд заббикса пока не лез, хотелось через гую все решать.

а можно как-то lld айтем переделать в "ручной"? прямым клонированием, не работает, т.к. есть уже айтем с аналогичным именем...

[Артём Мамзиков]

а можно как-то lld айтем переделать в "ручной"? прямым клонированием, не работает, т.к. есть уже айтем с аналогичным именем...

Переделать имя ключа добавив что то в него какой то параметр.
Можно даже на bash запросить оригинальный ключи , сделать необходимые операции в нем и передать траппером в lld.
Или lld будет запускать скрипт, а он запрашивает стандартный ключ и изменяет данные как нужно или проверяет.
Это если не заморачиваться с JavaScript в предобработке.

А так взять тестовый узел клонировать оригинальный шаблон и экспериментировать)))

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

[satoo]

Тут вот какое дело.

У меня как-то не складывается понимание философии заббикса.
Например:
- как может система мониторинга спокойно относиться к "потери" диска? Шаблон "из коробки".
- как может система мониторинга спокойно относиться к ошибкам в вычислении айтемов/триггеров?

Как еще один пример - опять-таки из коробки, поиск дисков делается через винду, номера дисков могут "гулять" (виртуалка или iscsi). Что делать, если изменился номер диска? Диск остался тем же. История нужна. Автоматом это не исправить, но и ручного изменения нет (кроме грубого ковыряния в базе).

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

[Артём Мамзиков]

satoo,

У меня как-то не складывается понимание философии заббикса.

Да бывает, такое местами почему именно так или нет вот так реализовано или почему тут нельзя вот так сделать. Есть моменты и понятные почему разработчики сделали именно так, а не иначе если учесть разные нюансы, а бывает логика не понятна.

На уровне железа например ipmi протокол Supermicro, dell iDcrac и другие. Либо специализированные утилиты для установки в OS например на dell -> OMSA, для Supermicro -> Superdoctor.
А обычный смарт тем -> smartmontools это уже берем счетчики id из самой ОС тут при замене могут меняться они как уж та или иная система устроена.

А так допиливаем сами что требуется и дорабатываем под себя.