После 6 месяцев разработки доступна новая версия системы мониторинга Zabbix 4.4, код которой распространяется под лицензией GPLv2. Zabbix состоит из трёх базовых компонентов: сервера для координации выполнения проверок, формирования проверочных запросов и накопления статистики; агентов для осуществления проверок на стороне внешних хостов; фронтэнда для организации управления системой...Подробнее: https://www.opennet.me/opennews/art.shtml?num=51668
>Также добавлена поддержка хранилищ для VMWare и сервисов systemd,Что это такое?
>>Также добавлена поддержка хранилищ для VMWare и сервисов systemd,
> Что это такое?Какая-то Ф. в v-w и s-d. Очевидно же.
* vmware.datastore.*.*[] на https://www.zabbix.com/documentation/4.0/manual/config/items...
, которые "This item is supported since Zabbix 4.0.10",* systemd.unit.*[] на https://www.zabbix.com/documentation/4.4/manual/config/items...
, которые "is only supported in Zabbix agent 2".https://duckduckgo.com/?q=vmware+site:www.zabbix.com/documen...
https://duckduckgo.com/?q="systemd"+service+site:w...
Чем это лучше, чем Icinga2?
Тем что развивается )
> Тем что развивается )да неужели? и что там развивается?
А инсигна не развивается?
> Чем это лучше, чем Icinga2?в целях контроля сервисов - мышегуем и монстроидальностью.
Если совсем не в курсе.
Всем, попробуй.
А всё таки?Мы используем стандартизированную связку Nagios/Icinga + Munin. Однин для алертов что что-то упало или вышло за допустимые границы, другой для исторических графиков, кто сколько чего когда ел (раньше был Cacti, рзочаровал непредсказуемостью). Разврачиваем независимую копию на каждый проект, такова наша специфика. Проектов одновременно около 8-12, по 10-200 хостов в каждом. В минимальном варианте оно живёт комфортно на AWS EC2 t3.nano. Когда хостов становится много, то раздуваем инстанс. t3.medium, по моему, сейчас самый крупный. Чтобы посмотреть на всех одновременно, в центральной локации есть nagios-dashboard, но сами по себе копии полноценно работают независимо от него.
Хосты добавляем/удаляем вручную, по строго стандартизированой процедуре. Автоматизировать особо не торопимся, оказалось что потребность в явных телодвижениях помогают контролю. От CloudWatch стараемся не зависить по идеологическим соображениям, ибо живём не только в AWS, а хочется универсальности.
Собираемся, уже пару лет как, попробобовать Zabbix. Я так понимаю, что по функционалу он в состоянии заменить оба инструмента (Nagios/Icinga+Munin), что есть хорошо, но больше преимуществ не вижу, надо смотреть.
Пугает риск непредсказуемого поведения и тяжеловесность, что наблюдали когда пробовали в прошлый раз (но это неточно и давно).
Пока непонятно как будем адаптировать кастомные скрипты для монторинга прикладных программ через NRPE.Собственно, такой интерес. Так на какие лучшести Zabbix относительо Icinga2 надо обратить внимание?
забикс более всего по идеологии из перечисленого схож на нагиос но легче, логичнее и кастомнее.
при ваших объемах справится любая система мониторинга т.к. такое количество хостов для них это "тьфу". вот когда хостов десятки тысяч и на каждый хост 10-15 параметров с графиками и т.п. вот тут уже совсем другая задача.
По большому счету и в первую оччередь забиксом вы сможете уменьшить количество систем мониторинга минимум до двух, а вполне возможно все три заменить на забикс. Часто как раз самописные скрипты (не знаю какие у вас задачи они решают) есть в забиксе "изкаропки". уменьшение количества систем мониторинга повышает стабильность работы суммарной системы мониторинга как таковой.
Посему я на вашем месте поставил бы забикс "на коленке" рядом и попробовал импорто-экспортами перенести часть данных, покопаться в "итого" и попробоал бы заменить все три системы на забикс.
не агитируя за забикс просто скажу что одна система мониторинга однозначно лучше чем связка из трех.
Спасибо за развёрнутый ответ. Полностью согласен что одна система лучше чем связка из трёх. Я, наверное, плохо описал свой кейс. Систем сейчас не три, а две. Icinga и Nagios используются по одиночке, а не паралельно в каждом проекте. В новых проектах Icinga, в тех кто постарше Nagios. Во всех случаях они дополняются Munin. Идея в том чтобы уменьшить количество систем с 2 до 1.Я правильно понял, мне стоит ожидать что Zabbix легче, в смысле, требует меньше ресурсов? У меня было обратное впечатление, но по давнему опыту. Или предполагается что легче оператору в него тыкать, а от машины он требует больше? Мы туда особо не тыкаем, просто смотрим, а всe исменения в конфигурации идут скриптами по SSH и отражаются в GIT.
Самописные скрипты это шелл и питон в userspace, которые умеют возвращать чуточку текста и код 0, 1 или 2. Там зоопарк, отданный на откуп девопсам. Я их дёргаю из nrpe-server. Остальное стандартно: Load Average, # of processes, free space, swap usage, etc.
Совет поставить Zabbix рядом весьма дельный, думаю, оно так и будет. Собственно, в рамках этого треда я пытаюсь понять, чего ожидать в общем.
Zabbix не разу не легче. Ресурсов ему надо больше. Хотя бы потому что он хранит все в mysql/postgres. Сам использовал Icinga+Cacti на порядка 700 устройствах. Вполне устраивала связка. Честно сказать не сталкивался с непредсказуемостью Cacti. Всегда все четко работало. Перешел на новую работу решил попробовать Zabbix, минусы это либо самому делать шаблоны под конкретные нужды, либо существующие кастомизировать, потому как там много зачастую лишнего. Не зря говорят что после установки надо все шаблоны встроенные удалить :) Для сравнения база Cacti на 700 устройств порядка 19Гб, аналогичного размера база Zabbix на 200 устройств. Возможно минусы связки Icinga+Cacti что в ручную все надо настраивать, но по моему это плюс, потому что понимаешь что мониторишь, какие параметры. А у Zabbix шаблон такого может намониторить, что потом надо половину шаблона/хоста отключать за ненадобностью, хотя бы те же триггеры. И еще с чем столкнулся у Zabbix нету такой связки как parent-children т.е. вы не можете сделать связку чтобы зависимость одного хоста от другого. Грубо говоря есть хост, а за ним еще куча и если первый в цепочки недоступен, то не надо остальные проверять/оповещать. В Zabbix это не сделать, есть запрос по данному поводу (ZBXNEXT-46), он висит уже 10 лет на эту тему вроде обещают в 5й версии. Это говорит об отношении разработчиков к пользователям. Есть механизм зависимость сделать триггеров, но это не то и не удобно. Так же с оповещениями тоже не такая логика как на той же Icinga. Говорят что zabbix логичнее. Но нет, всю логику в Icinga сам настраиваешь, а Zabbix работает по какой то своей логике. Порой не понимаешь с теми же оповещениями почему они не приходят, то ли хост не в той группе, то ли прав нету на хост, толи еще что то. А еще если к примеру есть оповещение, но тебе не приходит, вроде все правишь и права, но они тебе все равно не прийдут, пока событие не поменяет статус на решено и только со следующей проблемой оповещение придет.
У меня жгучее желание вернуться на Icinga+Cacti.
Не просто же тот же cern использует Icinga :)
> Возможно минусы связки Icinga+Cacti что в ручную все надо настраивать, но по моему это плюс, потому что понимаешь что мониторишь, какие параметры. А у Zabbix шаблон такого может намониторить, что потом надо половину шаблона/хоста отключать за ненадобностью, хотя бы те же триггеры.Отключать ненужное всё-таки гораздо проще, чем вспоминать, что нужно и что ещё забыли замониторить. Особенно во время какого-нибудь ахтунга.
Спасибо за отзыв, вы мне кучу времени съэкономили.
Хуже Cacti я ещё не видел, честно говоря. Icinga - тоже так себе затея. Если вам только пяток графиков строить и полтора хоста мелкого ООО мониторить - да, оно ещё работать будет. Если у вас тысячи, а ещё хуже - десятки и сотни тысяч показателей и половина от столько оповещений - ваши какти с цингой загнутся раньше, чем вы успеете сказать "раз-два-три".
> Хуже Cacti я ещё не видел, честно говоря. Icinga - тоже так
> себе затея. Если вам только пяток графиков строить и полтора хоста
> мелкого ООО мониторить - да, оно ещё работать будет. Если у
> вас тысячи, а ещё хуже - десятки и сотни тысяч показателей
> и половина от столько оповещений - ваши какти с цингой загнутся
> раньше, чем вы успеете сказать "раз-два-три".Вы это лично проверяли что они на таком количестве загнутся? Сравнения проводили?
Я думаю там где загнётся icinga, zabbix и подавно загнётся.
А еще у zabbix нету суммаризации толковой по графикам. Например в cacti есть куча интерфейсов, можно взять и на 1м графике получить сумму данных интерфейсов. Как такое сделать в zabbix я не нашел. Что то добавили в 4.4 но тоже как то бестолково оно работает. А этого реально не хватает.
И еще возможно не до конца разобрался, но как сделать чтобы посмотреть по отдельной группе состояние сервисов в zabbix не понимаю. В icinga это все проще.
Графана в помощь, использует Zabbix как datasource
В 4.4 появилась агрегация данных на графикак дашборда как для одиночных метрик, так и для всего всего датасета.
> В 4.4 появилась агрегация данных на графикак дашборда как для одиночных метрик,
> так и для всего всего датасета.Да появилась, но опять же криво реализовано. Я не понял как например выбрать определенные интерфейсы. Можно выбрать например Incoming traffic on interface $1, а под это попадают все интерфейсы и нужные и не нужные.
Например так: Incoming traffic on interface eth*
Так оно тоже не работает.
Избавьтесь от макроса $1 в имени метрики и всё заработает.
Да я как уже не пробовал и имя интерфейса и $ и без.
Приходите на телеграм канал Zabbix. Уверен, что проблему решат в течении 5 минут. Что-то очень простое.
>Так на какие лучшести Zabbix относительо Icinga2 надо обратить внимание?Не на какие. Будет тошнить. Сильно.
В позу - много независимых инстансов + общий даш - не поставить от слова никак.
Все эти красивые графики красивы только в анонсах, на деле народ ставит графану чтоб не видеть это убожество.>Пугает риск непредсказуемого поведения и тяжеловесность, что наблюдали когда пробовали в прошлый раз (но это неточно и давно).
Теперь стало еще еще тяжеловесней и более затейливо непредсказуемей.
> В позу - много независимых инстансов + общий даш - не поставить от слова никак.Общий даш я, в худшем случае, по кусочкам в ifram'ах соберу.
> графики красивы только в анонсах, на деле народ ставит графану
Если потребуется прикручиват что-то ещё (Графану), то это сведёт на нет львиную долю преимуществ, красивость Мунина меня и так уже устраивает.
> Теперь стало еще еще тяжеловесней и более затейливо непредсказуемей.
А вот это неприятно... У нас в компании культ минимализма и предсказуемости. Я, недостойный, служу при нём жрецом.
> на деле народ ставит графану чтоб не видеть это убожествоВ графане кликов нужно делать чуть ли не больше, чем в самом заббиксе, чтобы что-то нарисовать, а ещё у них весь интерфейс на жирных джаваскриптах. Что из этого большее убожество в контексте рисования полезных (а не красивых) картиночек — вопрос дискуссионный.
>В графане кликов нужно делать чуть ли не больше, чем в самом заббиксе, чтобы что-то нарисовать,А какая разница, где гуевозить?
> а ещё у них весь интерфейс на жирных джаваскриптах.
В заббиксе этого овна тоже есть. и не мало.
>Что из этого большее убожество в контексте рисования полезных (а не красивых) картиночек — вопрос дискуссионный.
Заббикс. Пусть лучше будут картинки на толстых жабаскрптах и напрягается клиент (у него и 3D акселерация к GPU, и памяти больше, и авторы графикорисвалок умнее), чем быстрые но кривые графики (чего только стоит неумение в нормальное масштабирование).
>>В графане кликов нужно делать чуть ли не больше, чем в самом заббиксе, чтобы что-то нарисовать,
> А какая разница, где гуевозить?Вы на прошлой работе кроссовки шили за доллар в месяц? Пока найдёшь, где в новой версии выключается мешающая читать графики полупрозрачная заливка, пока доскроллишь в настройках каждого второго графика до галочки stack, рука успеет отсохнуть, мозг — деградировать, прод — сломаться, а компания — обанкротиться.
> Пусть лучше будут картинки на толстых жабаскрптах и напрягается клиент
> (у него и 3D акселерация к GPUкоторая почти ничего не даёт в контексте рисовалок графиков
> и памяти больше
Да-да, открываешь в соседней вкладке другой дашборд и теряешь браузер по OOM. Достало. Они умудряются жрать раму гигабайтами.
> и авторы графикорисвалок умнее
Торкель лично это рассказывал?
> чего только стоит неумение в нормальное масштабирование
Уточните определение нормального масштабирования.
Сравнил список пользователей двух систем. Zabbix использует Лада, а Icinga используется в Audi. Какая беда, в Audi работают некомпетентные администраторы. Им нужно срочно как-то сообщить про Zabbix!
You are not google.
>You are not google.Я не пытался утверждать, что я google. Мой разум слаб, объясните Ваш месседж, пожалуйста!
>>You are not google.
> Я не пытался утверждать, что я google [...] объясните Ваш месседжЭто были заодно ключевые слова :-)
Не всё, что хорошо для гугла/ауди/..., хорошо для меня. Ну и обратное -- "что русскому хорошо, то немцу смерть" -- тоже давно уж известно.
из опыта использования обоих систем (надеюсь Ваш вопрос без сарказма и меряния разным...)
- у ЖАБикса и Инсинги разные алгоритмы работы в принципе
- жабикс хорош в случае большого количества разнородных хостов с большим количеством и разной телеметрией
- жабикс справляется с большими нагрузками данных и лучше в качестве распределенной системы
- жабикс лучше кастомизируется
- забиксовое апи более интересное и лешче/проще (тут конечно субъективно) интегрируются различные сторонние NMS
- по забиксу больше наработок, экстеншенов, профилей и т.п.
- более отзывчивое комюнити
в защиту инсинги можно сказать , что она интеллектуальнее, лучше справляется с оч. большим трафиком (коремаршрутизаторы). система более аналитическая и с ее помощью можно "предсказывать" те или иные события и поведения. Для большого количества хостов инсинга не годится.п.с. по большому счету нельзя рассматривать одну систему мониторинга как догму. есть еще достаточно большое количество оных, тот же Мунин заслуживает внимания, дедушку Нагиос можно вспомнить и т.д.
При выборе системы мониторинга надо рассматривать:
1. какое количество задач в % покроет система
2. апгрейдабельность и апдейтность насколько мягко и безпроблемно лягут
3. интегрируемость системы мониторинга с различными сервисами, начиная от ТТ систем, NMS, биллинги и т.п.Мерятся чье кунг-фу круче это не тот случай. Круче то кунг-фу которое выполняет свои задачи максимально просто, легко и главное результативно и успешно. Кстати надо не забывать и про обучаемость смен мониторинга, оповещалках и т.п.
Любое кунг-фу надо еще уметь готовить :)
п.с. например Инсинга плохо реализует оповещение например при том то трафик упал ниже чем или тот же трафик резко вырос. Там с фильтрами есть ограничения и задача становится нетривиальной, в то время как тот же жабикс (люблю его так звать :) ) делает сие на раз-два.
> Там с фильтрами есть ограничения и задача становится нетривиальнойНету там ограничений, взял и написал. А в заббиксе - что дядя осилил то и пользуем.
> в то время как тот же жабикс (люблю его так звать :) ) делает сие на раз-два.
Ну-ка, покажи нам, как с помощью LLD нарисовать 2 триггера, которые будут по SNMP опрашивать железку и в зависимости от имени интерфейса (есть слово backup|standby или нету) генерить триггеры на
a) нет трафика в не-backup|standby интерфейсе.
b) есть трафик в backup|standby.
опционально, можешь кидать алерты - упал основной интерфейс и поднялся backup|standby.
Для придания пикантной остроты - пусть половина backup|standby - это динамические интерфейсы (типа ppp/pptp/openvpn).
Ы?
Легко там это делается, просто в заббикс и дискавери надо уметь. В задаче не сказано кстати как между собой коррелируют active и backup, поэтому сферический конь в вакууме.
Вы видимо не очень много и "глубоко" работали с zabbix, раз так уверены в своем утверждении "А в заббиксе - что дядя осилил то и пользуем." Уверяю Вас, за почти десятилетний опыт работы с данной системой могу уверенно сказать, что она очень ГИБКАЯ. Дополнить и написать триггер, график или то что Вам не хватает, совершенно не проблема. Все звисит только от Вашего воображения и желания...
> Для большого количества хостов инсинга не годится.Какое количество хостов Вы считаете большим?
Audi Automotive, Icinga monitors: 10,000+ hosts, 50,000+ services with 7 instances (distributed)Audi was in search of an infinitely scalable and flexible monitoring system, which could easily be distributed for high availability.
Согласитесь, что Вы написали глупость.
10000 хостов и всего 50000 item'ов - это очень мало, это один небольшой сервер (древненький 1x X5650 например) заббикса, с базой на нём же) потянет вообще без затруднений.
Оно созрело для IaC? В смысле конфигурацию хостов/шаблоны в виде версионируемых текстовых файлов можно хранить?
>Оно созрело для IaC? В смысле конфигурацию хостов/шаблоны в виде версионируемых текстовых файлов можно хранить?неа. точнее можно, но так же с кучей хуков и приседаний.
А вот IaC с нормальным аудитом и аггрегацией схожих триггеров в веб-интерфейсе как раз очень не хватает. Настолько, что без них обновление не нужно.
Нет.
Отчасти.Вы можете создавать\удалять хосты, навешивать темплейты, конфигурять айтемы\графики\триггеры через модули ansible. Но сильно не всё.
Годнота!
> Годнота!CPAMOTA
Мониторинг через почту - жесткий изврат :(
Вы больны и не лечитесь!
У меня Заббикс и чятики писал и смски слал и по телефону звонил, стоит только захотеть. Просто то куда вы шлёте оповещение и как заббикса не касается, он умеет базовое и предоставляет возможность прикрутить что угодно. Хоть скайп-бота себе запилите.
>Мониторинг через почту - жесткий изврат :(много лет этим занимаюсь, и не знал
Молодцы ребята, на месте не стоят. Добавления поддержки СУБД которая запилена под хранение временных рядов идеально для метрик, чем SQL и плох был, на больших базах порой партишининг не помогал и сколько костылей приходилось придумывать.
Надо будет вернуться к ней когда снова железо ко мне в оборот попадет, если попадет конечно. Эхх ещё бы поддержку сервис дискавери (etcd, consul) ну или хотя бы в автопоиск добавить теги или что то аналогичное что бы можно было в динамике узлы добавлять-удалять таргетрировано, в принципе и сейчас можно, но пинать приходится сбоку, а хочется нативно.
для сетей до 100 устройств вполне хорош observium по snmp
монстров типа заббикс кому нужно тому нужно
Ага за бабло, и даже хитрая крыса на сайте, ну ясно...
Мониторинг Docker из коробки опять не завезли.
А как вы это представляете?
sudo docker stat inspect примерно так
есть агент докеризированный, все отсальное работает как и без докера.
Используйте встроенную возможность сбора данных из Prometheus экспортеров.
Вот это главная вещь - реализована официальная поддержка СУБД TimescaleDB
Которая не свободна
Надеюсь, в будущем добавят поддержку VictoriaMetrics. Она требует в 70 раз меньше места на диске для хранения того же объема данных, что и TimescaleDB. Благодаря этому она намного меньше грузит дисковую подсистему и работает быстрее. См. https://medium.com/@valyala/measuring-vertical-scalabil...
Ты опять прибегаешь к агрессивному маркетингу? :-)
не надейтесь.
С timescale получилось только потому, что это надстройка над postgres.
Чтобы добавить поддержку не-sql db надо переписать примерно половину ужасающего спагетти-кода, в миллионе мест утыкав его проверками "тут конфигурация - ищем в sql, тут хистори - ищем в victoria", поскольку никакого нормального midlayer там не предусмотрено.учитывая оставшихся полутора разработчиков (остальные, похоже, переведены в менеджеры по продажам) - задача нереализуема вообще.
Да они даже экспорт дэшбордов не осилили - а как дысали, как дысали...
Kusto на очереди?
чем оно лудше чем check_mk ?
Кто-нибудь обновлялся уже?
Морда от базы не отваливается, как в прошлые обновления?
А то в прошлые разы апачу прав забывали отсыпать.
неужели это кому-то ещё надо?
А что не так? чем сейчас пользуются любители смузи?
вероятно influx/telegraf или promotheus
ещё на той неделе обновился до 4.4..
Спасибо. Keep us posted
Есть форк на базе кликхауса, не нужен этот мусор.
https://www.opennet.me/opennews/art.shtml?num=51053
ты его бы за пределами локалхоста поимел хоть раз, а потом бы написал тут ( и написал бы нытье - нытик ) , а этот КХ ваш - багомерзкое поделие , которое тешат в яндексах - чтоб моральный дух разрабов не сильно зачах на фоне их фатальных факапов и в кх тоже ( почитай их чат в телеге где автор постоянно оправдывается )
Не осилил, так и напиши неудачник девопс 300к/сек
> Есть форк на базе кликхауса, не нужен этот мусор.Заббикс сделан для совсем других целей.
Форк Заббикс сделан для других целей нежели Заббикс... мы уже вас поняли..
>кликхауса, не нужен этот мусорКликхаус не нужен, да.
Мде, что-то заббикс начал разочаровывать ... Как сломали они в 4.0 поведение параметра ITEM.LASTVALUE - так и не починили, хотя обещали, клялись , божились что в 4.4 починят, и тригеры будут нормально данные присылать, а не последнее значение до начала проблемы ... А воз и ныне там ... Обновил до последней версии, поведение не поменялось, да и в документации они просто пометили - что типо оно себя так вело до 4.0, а сейчас ...
Кто сидит на 3.* - и использует параметр ITEM.LASTVALUE - обновляться не рекомендую, все сообщения, к которым привыкли, а именно с отсылкой сообщений о текущем состоянии параметра, а не о состоянии в момент срабатывания триггера больше не работают ...
Обратите внимание на Operational data и параметры фильтра при отображении проблем.
В 4.4 добавили operational data. А вообще изменение поведения item.lastvalue лично нам оказалось очень удобным - к моменту, когда люди смотрят в нашу треевую тулзу для отображения триггеров, данные могут уже прилично уйти от момента взлёта триггера, и ситуация становится неочевидной. Сейчас получается best of both worlds, надо будет чуток тулзу допилить, чтобы текущие данные тоже показывала.
У меня 4.2.7.
ITEM.LASTVALUE в action присылает текущее значение, а не на момент сработки. ITEM.VALUE - тот да. Тот кажет историческое значение.Я прочитал и комментарий в доке и несколько тредов про изменения поведения. Насколько я понял, изменение было сделано ради problems. Там при выводе на экран большой простыни была большая нагрузка.
В общем, я на 4.2.7 не вижу спец-эффектов или не понимаю куда смротреть, чтобы их увидеть.
> У меня 4.2.7.
> ITEM.LASTVALUE в action присылает текущее значение, а не на момент сработки. ITEM.VALUE
> - тот да. Тот кажет историческое значение.
> Я прочитал и комментарий в доке и несколько тредов про изменения поведения.
> Насколько я понял, изменение было сделано ради problems. Там при выводе
> на экран большой простыни была большая нагрузка.
> В общем, я на 4.2.7 не вижу спец-эффектов или не понимаю куда
> смротреть, чтобы их увидеть.Так проблема и на дашборде - при использовании в триггерах - после срабатывания данные больше не обновляются, а остаются на момент срабатывания. А это не совсем удобно - к примеру как место на дисках - ну матернулся он что там меньше 10% на таком-то диске, не критично, но ранее - в дашборде данные обновлялись - и можно было посмотреть в рилтайме насколько быстро место съедается, не заходя в последние данные, просто с вида триггера, или к примеру триггеры на проверку срока действия сертификатов ссл - данные менялись каждый день, уменьшая количество оставшихся дней до истечения. И при отправке писем, смс и тд - да, есть воркараунд - {{HOST.HOST}:{ITEM.KEY}.last()} - но это не информативно, и если не подводит память - работает ТОЛЬКО в отправляемых уведомлениях, но не в триггерах и дашбордах.
Пример триггера : {HOST.NAME} ***** Status code {ITEM.LASTVALUE} ( проверка статуса ответа вебсервиса - 200 не 200 ) - присылает на момент срабатывания - latest value 200 - хотя на самом деле там не 200, и на момент восстановления - те-же 200 ... Как понять что ему стало легче ? только по концу сообщения - ok и problem ? Или места на диске 9% ,и момент восстановления - на диске 9% ОК - информативно .... Сколько стало реально места на диске ? Прыгает туда обратно 1 процент, или кто-то из админов добавил в лвм места ?
Если использовать заббикс для полторы машины - да, можно залезть посмотреть, но когда парк из овер 500 - ползать при таком срабатывании на каждую ? Или у каждой просматривать последние присланные данные, но значит требуется доступ к интерфейсу , которого нет - находясь к примеру вне офиса, и получая 9% проблема и через 5 минут 9% ОК - класс ...
.
На dashboard стандартный виджет problem может выводить текущее значение. По крайней мере у меня выводит. И там актуальное значение.Про проценты. Меня это не устроило и я сделал триггеры не pfree, а free. Теперь там байты и при условии, что показывается текущее значение, проблем я не вижу.
Ну и да, у меня не полторы машины, так что discovery используется вполне активно.
Меня вот парит, что они уже несколько лет не в состоянии сделать систему parent-child как в nagios. Из-за этого у нас стоят оба.
> На dashboard стандартный виджет problem может выводить текущее значение. По крайней мере
> у меня выводит. И там актуальное значение.
> Про проценты. Меня это не устроило и я сделал триггеры не pfree,
> а free. Теперь там байты и при условии, что показывается текущее
> значение, проблем я не вижу.
> Ну и да, у меня не полторы машины, так что discovery используется
> вполне активно.
> Меня вот парит, что они уже несколько лет не в состоянии сделать
> систему parent-child как в nagios. Из-за этого у нас стоят оба.Вопрос тогда - какой параметр в названии триггера у вас сейчас выводит реалтаймовое значение ? Я не нашёл в своё время. На текущий момент что и раздражает - выводится значение которое было при срабатывании триггера. Я как-раз во всех названиях триггеров использовал {ITEM.LASTVALUE} и засчёт этого в получаемых письмах-смс имел сразу текущее значение, как и автозамена статусов сервисов - которые брались из Преобразования значений - присылалось Service takojto DOWN , и при восстановлении Service takojto UP , сейчас и при восстановлении, и при падении - значение DOWN ...
По поводу места - как раз - используя данный параметр я в смс всегда имел - реальное значение на текущий момент времени, все шаблоны заббикса были переделаны на отсылку текущего положения дел, а не стандартные - которые присылают простой текст со значением - у вас на диске меньше стольки-то Problem или OK ...
Описание с доков самого заббикса :
Note that since 4.0, it will not resolve to the latest item value when viewing problem events, instead it will stay with the item value from the time of problem happening.
Supported since 1.4.3. It is alias to {{HOST.HOST}:{ITEM.KEY}.last()}.
В названии - никакой.Через telegram и почту приходит вот такое письмо
🔥 Problem started at 12:59:36 on 2019.10.16
Problem: Free space on datastore DATASTORE-NAMEOn start: 231 MB
Current: 353 MBOriginal problem ID: 111111111
Когда отпускает, вот такое
✅ Problem has been resolved at 13:34:36 on 2019.10.16
Problem: Free space on datastore DATASTORE-NAMECurrent: 353 MB
Original problem ID: 111111111
На dashboard в widget problems выводятся колонки
Time Info Host Problem Severity Latest values Duration Ack Actions
Вот в Latest values и выводится текущее значение. Если вам нужно тут-же видеть значение на помент сработки - воткните в название trigger ITEM.VALUE. Думаю, этого хватит.
> В названии - никакой.
> Через telegram и почту приходит вот такое письмо
> 🔥 Problem started at 12:59:36 on 2019.10.16
> Problem: Free space on datastore DATASTORE-NAME
> On start: 231 MB
> Current: 353 MB...
Этот воркараунд я и описал в своём первом сообщении сегодня, пришлось добавить в отправляемое сообщение ещё пару полей, которые да - присылают последнее значение, но как и написал изначально - убили функциональность, которая использовалась довольно многими, при отправке смс на телефон - достаточно 1 смс-ки с заголовком, в котором всё уже есть, сейчас-же отправляется смс с 3 строками - что-бы получить то что ранее было в 1-ой ...
За Operational Data - спасибо, добавил в дашборд .
По поводу состояния триггера на момент срабатывания - ну он и так у меня есть - шаблоны-то не переделывал, а значит {LAST.ITEMVALUE} и отображает ITEM.VALUE, так как они сделали их одним и тем-же, что даже исходя из названия триггера нелогично ...
>[оверквотинг удален]
>> On start: 231 MB
>> Current: 353 MB
> ...
> Этот воркараунд я и описал в своём первом сообщении сегодня, пришлось добавить
> в отправляемое сообщение ещё пару полей, которые да - присылают последнее
> значение, но как и написал изначально - убили функциональность, которая использовалась
> довольно многими, при отправке смс на телефон - достаточно 1 смс-ки
> с заголовком, в котором всё уже есть, сейчас-же отправляется смс с
> 3 строками - что-бы получить то что ранее было в 1-ой
> ...Ну, тут не поспоришь, краткость - сестра таланта. В заголовок все не воткнешь, но тело можно свести до одной строки, наверное.
От SMS мы отказались довольно давно. Разве что совсем критичные сервисы мониторить в режиме - CRITICAL/OK. А любые подробности - в telegram. У SMS есть свои плюсы, но минусы его превышают.
> За Operational Data - спасибо, добавил в дашборд .
Всегда пожалуйста. ;)
Приятно, когда кейсы доходят до релиза. Пусть и через 5 лет. Обновляюсь!