Zabbix выгрузка данных в excel
Теперь, когда у вас имеется соответствующая размерам вашей среды установка Zabbix, вы можете захотеть на самом деле запустить её мониторинг. Хотя совершенно просто определить какие хосты или приложения, физические или какие- либо ещё вы можете пожелать подвергнуть мониторингу, может оказаться не сразу не ясным какие реальные замеры вы должны выполнять в них. Метрики, которые вы можете определять на хосте называются элементами (item), а данная глава обсудит их основные свойства и характеристики. Первая часть по большей части является теоретической и будет сосредоточена на следующем:
Элементы в качестве метрик, а не для проверок состояния
Поток данных и направленность для элементов
Улавливающие элементы как средство контроля над вашим потоком данных
Затем мы переместимся к более практическим и специфичным методам и обсудим как настраивать элементы для сбора данных со следующих источников данных:
Баз данных и ODBC в качестве источников
Приложений Java, консоли JMX, агентов SNMP < Прим. пер.: а также, например, через протокол MQTT >
Мониторинга веб- страниц
Агрегирующих и вычисляемых элементов
Накопление элементов в виде необработанных данных
Одно из самых важных свойств, которое выделяет Zabbix из прочих решений мониторинга заключается в том, что его главный режим взаимодействия с объектами мониторинга сосредотачивается на сборе исходных данных вместо получения предупреждений или обновлений состояний. Другими словами, многие приложения мониторинга имеют рабочий поток (или его видоизменения) отображаемый следующей схемой:
Рисунок 1
Иными словами, агент или любой другой датчик мониторинга не просто для выполнения измерения, но также и для включения некоего вида принятия решения о состоянии о проведённом измерении перед его отправкой на вашу главную серверную компоненту для дальнейшей обработки.
С другой стороны, основной рабочий поток Zabbix едва уловимо, но при этом очень существенно, отличается, что отображает следующая схема:
Рисунок 2
В этом случае агент или датчик мониторинга запрашивается только для измерений с последуюшей отправкой выполненных измерений на серверную компоненту для хранения в конечном итоге для дальнейшей обработки.
Эти данные не связываются каким- либо определённым решением о срабатывании спускового механизма (trigger), а именно: пропустить/ отвергнуть, хорошо/ предостережение/ ошибка или любые другие возможные варианты, а вместо этого удерживаются на вашем сервере как отдельная точка данных или измерений. Если это допустимо, например, для численных данных, они также сохраняются агрегированном и обобщающем динамику формате в виде минимума, максимума и среднего на протяжении различных периодов времени. Сохранение данных отличается от логики принятия решений, однако помещение всего в одно место снабжает Zabbix двумя отличительными преимуществами.
Первое состоит в том, что вы можете использовать Zabbix для сбора данных о вещах, которые не связаны непосредственно с возможными предостережениями и действиями, которые вы должны предпринимать, однако относятся к общей производительности и поведению системы. Классическим примером является коммутатор со множеством портов. Вас могут не интересовать предостережения об аномальном обмене в отдельном порту (так как может быть также непросто определять аномальный обмен по отдельному порту без наличия информации о контексте), однако вас может интересовать сбор замеров обмена как на уровне порта, так и на уровне коммутатора для установления базового уровня, определения узких мест, или планирования расширения вашей сетевой инфраструктуры. Аналогичный случай может рассматриваться при использовании ЦПУ и ядер, ёмкости хранилища, одновременного числа пользователей для данного приложения и тому подобного. В своих простейших вариантах применения, Zabbix может даже использоваться для сбора применяемых данных и визуализации их в различных графиках и диаграммах, без касательства его мощных свойств триггеров (запускающих механизмов) и согласования, и по прежнему оставаться исключительным вкладом вашего времени и ресурсов.
Говоря о механизме запуска (triggering), второе большое преимущество наличия полной, централизованной базы данных исходной информации, в противовес отдельным замерам (или, в лучшем случае, лишь несколькими измерениями одного и того же элемента), состоит в том, что для каждого триггера (запускающего механизма) и схемы принятия решений вы можете использовать выгоду от всей базы данных измерений для точного определения типа события, которое вы хотите отслеживать и получать о нём предупреждения. У вас нет нужды полагаться на отдельное измерение; вам даже не нужно полагаться на самое последнее измерение плюс несколько предыдущих для того же самого элемента с того же самого хоста. На самом деле вы можете сопоставлять что угодно с чем угодно ещё в вашей базе данных истории элементов. Это свойство настолько мощное, что мы выделяем ему целую главу, и вы можете непосредственно перейти к следующей если это то, о чём вы хотите прочитать. Было бы достаточно сказать, что вся эта мощь основывается на том факте, что в Zabbix полностью разделяются все функции сбора данных от логики запуска (trigger logic) и функций действия.
Таким образом, в Zabbix элемент представлен отдельной метрикой - отдельным источником данных и измерениями. Существует множество видов внутренних элементов Zabbix даже без рассмотрения индивидуальных пользовательских, которые вы можете определить применяя внешние сценарии. В данной главе мы изучим некоторые менее очевидные, но очень интересные из перечня таких элементов. Вы увидите как иметь отношения с базами данных, как интегрировать нечто чуждое в виде ловушек SNMP в образе мышления Zabbix, как агрегировать существующие элементы вместе для представления кластеров наблюдения, и тому подобное. Так как вы заложите прочную основу в разумном и стратегическом определении элемента и сборе данных, вы сможете уверенно полагаться на неё для развития управления своими событиями и функциями визуализации данных, с которыми вы ознакомитесь в последующих главах.
Понимание потока данных для элементов Zabbix
Элемент Zabbix можно понимать по его самым необходимым частям - идентификатору, типу данных и связанному хосту. Эти элементы обычно являются наиболее полезными для всех остальных компонентов Zabbix. Идентификатор (обычно это имя и связанный ключ элемента) и его сопутствуюший хост применяются для отличия отдельного элемента между тысячами, которые могут быть определены в среде мониторинга. Тип данных важен чтобы Zabbix знал как сохранять данные, как их визуализировать (текстовые данные не могут отображаться графиками, например) и, что наиболее важно, какой вид функций можно к ним применять для дальнейших моделей запуска и обработки.
Имя элемента является описательной меткой, которая подразумевается лёгкой для прочтения, в то время как ключ элемента следует определённому синтаксису и в точности определяет метрику, которую мы хотим измерять.
Двумя очень важными элементами, которые являются общими для всех элементов являются история (и обобщённая динамика, trend) периода сохранности и тип элемента. Мы уже видели в Главе 1, Развёртывание Zabbix, как сохраняемая история напрямую воздействует на размер вашей базы данных мониторинга, как делать её оценку, и как сводить баланс между производительностью и доступностью данных. С другой стороны, тип элемента является существенным, поскольку сообщает Zabbix как данные элемента в действительности становятся доступными вашему серверу, что, другими словами, означает как Zabbix намеревается собирать данные: через агента, запрос SNMP, внешний сценарий и так далее.
Как вы вероятно уже знаете, существует достаточное количество различных типов элементов. Хотя достаточно просто понять разницу между элементом SSH и элементом ODBC, также важно понимать как данные преодолевают путь между сервером и его датчиками, а также то, являются ли они агентом Zabbix, датчиком со стороны сервера или внешней проверкой какого- либо рода. С этой точки зрения, мы сначала сосредоточимся на нашем агенте Zabbix и разнице между пассивным и активным элементами.
Прежде всего, активная и пассивная концепции должны пониматься с точки зрения агента, а не сервера. Помимо этого, они служат для иллюстрации компонентов, которые инициируют соединение для отправки и получения информации о настройках и данные мониторинга, как это отображено на следующей схеме:
Рисунок 3
Таким образом, стандартный элемент Zabbix рассматривается как пассивный с точки зрения агента. Это означает, что именно стороной сервера является задание опрашивать своего агента, причём в определённые для этого элемента временные интервалы, с целью немедленного получения нужных замеров и отчётов обратно. В терминах сетевых операций, вашим сервером инициируется и сбивается выделенное соединение, в то время как агент находится в состоянии прослушивания.
С другой стороны, в случае с активным элементом Zabbix, именно сам агент выполняет задание запрашивать свой сервер о том какие подлежащие мониторингу данные он должен собирать и в какие интервалы. Затем он выполняет согласно расписанию свои собственные измерения и соединяется для их отсылки назад на свой сервер для дальнейшей обработки. В терминах сетевых операций в данный процесс вовлечены следующие два различных сеанса:
Агент запрашивает свой сервер об элементах и интервалах для мониторинга
Агент отправляет такие данные мониторинга, которые собираются на его сервере
В отличие от стандартных пассивных элементов, ван необходимо выполнить настройку агента таким образом, чтобы он знал с каким сервером он должен соединяться для целей настройки и обмена данными. Естественно, это определяется в конкретном файле zabbix_agentd.conf для каждого агента; просто установите ServerActive на конкреное имя хоста или определённый IP адрес вашего сервера Zabbix и задайте в RefreshActiveChecks необходимое значение секунд, которое агент должен ожидать перед проверкой есть ли какие либо новые или изменённые определения элемента. Следующая схема отображает это:
Рисунок 4
В отличие от инициации обычного сетевого соединения, основная разница между пассивным и активным элементами состоит в том, что в последнем случае невозможно определять гибкие интервалы мониторинга. В случае пассивного элемента вы можете определять различные интервалы мониторинга на основании времени суток и дня недели. Например, вы можете проверять доступность сервера управления идентификацией каждую минуту на протяжении рабочих часов и каждые 10 минут ночью. С другой стороны, если вы используете активный элемент, вы застрянете всего лишь с одним вариантом интервала мониторинга.
Возможно, вы также отметили выходящую за рамки пассивности схожесть между вашими активными и пассивными элементами, а также схожесть между функциональностью и свойствами активных и пассивных прокси Zabbix.
На самом деле, мы можем выбирать между активными и пассивными элементами во многом таким же самым образом и по тем же самым причинам, как мы выбирали между активными или пассивными прокси в Главе 2, Распределённый мониторинг для разгрузки некоторых заданий расписания серверов и работы с охватом ограничений и пределов вашей сетевой среды и маршрутизации или настроек межсетевого экрана.
Конечно,существует основная разница между прокси и агентами. Не является фактом, что прокси может получать данные мониторинга с большого числа хостов, в то время как агент теоретически (но не практически, несомненно, существует возможность растягивать его функциональность с использованием пользовательских элементов, которые основываются на сценариях или внешних приложениях) ограничен в средствах мониторинга только тем хостом, на котором он установлен.
Когда речь идёт о потоке данных, основной разницей является то, что режим работы прокси- сервера применяется для всех тех хостов и элементов, которыми управляет этот прокси. На самом деле он не заботится о природе тех элементов, которые подлежат мониторингу со стороны прокси. Однако, когда активный прокси собирает свои данные (будь то данные от активных или пассивных элементов агентов, внешних сценариев, SNMP, SSH и тому подобного), он всегда будет инициировать все соединения со своим сервером. Аналогичное происходит и с пассивным прокси; не имеет значения будут ли все имеющиеся у него элементы для мониторинга активными или пассивными. Он всегда будет ожидать от своего основного сервера запросов для обновления настроек и измерений.
С другой стороны активный или пассивный элемент это просто один элемент из множества. Хост может определяться смесью активных и пассивных элементов; поэтому вы можете предполагать, что агент будет всегда инициировать все свои соединения с сервером. Чтобы сделать это, все полагающиеся на этого агента ваши элементы должны быть определены как активные, включая появляющиеся в будущем.
Понимание улавливающих элементов Zabbix
Крайней версией активного элемента, которая всё ещё основывается на протоколе Zabbix является элемент ловушки (trapper item) Zabbix. Выделяясь среди всех прочих типов элементов, элемент ловушки не имеет интервала мониторинга определяемого на уровне сервера. Другими словами, сервер будет знать определён ли элемент ловушки, его тип данных, связанный с ним конкретный хост, а также период сохранности как для истории, так и для обобщённых динамик (trend). Однако он никогда не будет управлять по расписанию проверками для такого элемента и не будет передавать информацию о своём расписании и интервале мониторинга какому- либо прокси или агенту. Поэтому он настроен на определённое снятие показаний управляемое по расписанию неким образом с последующей отправкой полученной информации о собранных данных на свой сервер.
Улавливающие элементы, до некоторой степени, являются противоположностью внешних проверок Zabbix с точки зрения потока данных. Как вы вероятно уже знаете, вы определяете тип элемента внешней проверки когда вы желаете, чтобы сервер выполнял внешний сценарий для сбора измерений вместо опроса агента (Zabbix, SNMP и тому подобных). Это может настоятельно потребовать дополнительных расходов производительности сервера, поскольку такой подход создаёт новую ветвь процесса для каждого внешнего сценария, который он должен выполнить, а затем дождаться отклика. По мере того, как число сценариев растёт, это может существенно замедлять работу сервера до того момента, когда накопится значительное число просроченных проверок в то время как он занят исполнением сценариев. Чрезвычайно простой и примитивный, но всё ещё эффективный вариант обработки этой проблемы (естественно, помимо уменьшения числа внешних сценариев настолько большого, насколько это возможно) состоит в преобразовании всех элементов внешних проверок в улавливающие элементы, следующие исполнению по тому же расписанию, что и те же самые применяемые для внешних проверок сценарии через crontab или любое другое средство планирования, и изменить сами эти сценарии таким образом, чтобы они использовали zabbix_sender для взаимодействия от ваших измеряемых данных к их серверу. Когда мы обсудим протокол Zabbix в Главе 8, Обработка внешних сценариев, вы увидите приличное число примеров такой наладки.
Обзор потока данных
Это краткая сводка классифицированных по типу соединения типов элементов с предложением альтернативы, если пожелаете по любой причине, для другого подхода. Как вы можете увидеть, Zabbix Trapper зачастую единственно возможная, хотя и неуклюжая и топорная, альтернатива если вам совершенно необходимо поменять тип соединения. Отметим, что в приводимой ниже таблице термин Passive подразумевает, что данное соединение инициируется его сервером, а Active означает, что данное соединение инициируется там, где применяется прибор. Хотя это может казаться противоречащим здравому смыслу, это на самом деле не связано с аналогичными терминами в их применении к прокси и агентам, что отображено в следующей таблице:
Имеется возможность настройки экспорта в режиме реального времени событий по триггерам, значений элементов данных и динамики изменений в формате JSON с разделением новой строкой.
Экспортирование выполняется в файлы, где каждая строка файла экспорта является JSON объектом. Преобразования значений не применяются.
В случаях, когда данные не удается записать в файл экспорта или файл экспорта не удается переименовать или не удается создать новый после переименования его, Zabbix будет пытаться повторить операцию каждые 10 секунд, пока операция не будет успешной.
Для получения подробных сведений о том какая информация экспортируется, смотрите страницу протокола экспорта.
Обратите внимание, что узел сети/элемент данных может не иметь метаданные (группы узлов сети, имя узла сети, имя элемента данных), если узел сети/элемент данных удаляются после того, как получены данные, но до того как сервер выполнил экспорт этих данных.
Настройка
Чтобы настроить экспорт в режиме реального времени событий по триггерам, значений элементов данных и динамики изменений необходимо указать директорию для файлов экспорта - смотрите параметр ExportDir в конфигурации сервера.
Другой параметр - ExportFileSize можно использовать, чтобы задать максимально разрешенный размер отдельных файлов экспорта. Когда процессу нужно выполнить запись в файл, он сначала проверяет размер этого файла. Если размер превышает заданный лимит размера, тогда файл переименовывается, к его имени добавляется .old, и создается новый файл с исходным именем.
Файл будет создаваться каждым процессом, который выполняет запись данных (то есть примерно 4-30 файлов). Так как по умолчанию размер каждого файла экспорта равен 1Г, тогда хранение больших файлов экспорта может привести к быстрому уменьшению свободного пространства на диске.
Except where otherwise noted, Zabbix Documentation is licensed under the following license: CC Attribution-Noncommercial-Share Alike 4.0 International
Проверяя рейтинг 100 лучших триггеров, вы можете легко просмотреть триггеры с наиболее частыми изменениями триггеров.
1.4Bar reportsКонфигурация отчета
После завершения добавления нажмите кнопку «Показать», чтобы отобразить эффект отображения, показанный на рисунке ниже, но, к сожалению, сохранить его невозможно.
Интеллектуальная рекомендация
Java.nio.Buffer flip () метод jdk Ошибка перевода на китайский язык
Когда я сегодня читал «Идеи программирования на Java», я столкнулся с методом java.nio.Buffer flip (). Дело в том, что «[color = red] переворачивает этот буфер. Сначала установите ог.
Предварительное понимание регулярных выражений Python (4)
Сегодня я продолжу делиться базовыми знаниями о регулярных выражениях Python. В основном я представляю использование специального символа "<>". Ниже приведено конкретное руководство. .
Все белое Введение Сверток Neural Network (CNN)
Использование внутреннего соединения, левого соединения, правого соединения в оракуле
Левое-правое соединение фактически говорит, какая таблица является результатом нашего совместного запроса ~ 1. Взаимосвязь проста select A.*, B.* from A,B where A.id = B.id select A.*, B.* from.
[Код очень подробный] POJ 2492 A Bug's Life (и проверьте коллекцию)
1. Описание заголовка 2. Инструкции по анализу алгоритмов и руководство по написанию кода. Похожие темы:POJ 1182 Решение проблемы пищевой цепи Наблюдается m насекомых и n вязок. Насекомые u и v могут .
Эта система - это система, которую я написал, чтобы экспортировать данные, контролируемые Zabbix в таблицу Excel.
Springboot + JPA + POI на заднем плане
Vue + Elementui передний конец
Исходный код сначала:
Давайте сначала посмотрим на эффект.
Чтобы увидеть экспортируемую форму
Исторические записи данных экспорта были реализованы, установленные экспортированные элементы мониторинга, настройки сопоставления псевдонимов элементов мониторинга и функции сортировки веса.
После нескольких потоков оптимизацию данные вычисления займут около 4 секунд.
Фон развертывания:
2. Измените файл конфигурации Application.yml
Нужно изменить следующие места к вашим настройкам
Файл SQL является каталогом SQL Resource.
4. Начните проект.
Развернуть передний конец:
2. Выполните команду
Фон использует Transhboot JPA POI Technology, которая не расширяется подробно.
Объявите внутренний класс, Asynclu является многопоточным асинхронным асинхронным расчетом, потому что данные каждого хоста не пересекаются, поэтому мы используем многопоточное количество каждого хоста для расчета идей их соответствующих данных. В то же время также реализован Callable интерфейс с возвращающим значением, а рассчитанный результат возвращается.
Выполнить в соответствии с порядком строительства:
1.Login () Метод получения токена
2. Экономика () Получить предмет хоста
По установке вывода и выбораInterfaces вы можете получить нужные данные, уменьшите расход разрешения данных
3. GetItem () Получить мониторинг
То же самое также устанавливает выходные атрибуты.
4.Этистория () Получить исторические данные в соответствующем диапазоне времени
Настоящим обратите внимание, что исторические данные различных типов данных самой Zabbix хранятся в разных таблицах. Мы должны устанавливать параметры в соответствии с значением value_type, который вы получили в GetItem, в противном случае приготовление данных не будет доступно.
6. Верните расчетные данные в коллекцию RES
7. Excel Заполните данные, это не отключено, а инструкции для POI ищут ее самостоятельно.
Код введения здесь здесь
Объяснение: Эта система используется для транспортировки и технического обслуживания интрасети, поэтому нет модуля входа в систему, а небольшой партнер нуждается в моем блоге о перехвате логина.
Это первая версия. Если у вас есть какие-либо вопросы, пожалуйста, оставьте свои комментарии или выпуск. Если вы чувствуете себя легко в использовании, гостевой офицер не забудет похвалить его, вы можете пойти в GitHub, вы будете лучше.
Если у вас есть какие-либо вопросы, вы можете прокомментировать или в частном порядке, у меня есть ежедневно (Ляо) сомнение (SAO).
Я большое имя, скромный фермер Micro-Code, который готовит 996, я чувствую себя хорошо для похвалы! ! !
Интеллектуальная рекомендация
Java.nio.Buffer flip () метод jdk Ошибка перевода на китайский язык
Когда я сегодня читал «Идеи программирования на Java», я столкнулся с методом java.nio.Buffer flip (). Дело в том, что «[color = red] переворачивает этот буфер. Сначала установите ог.
Предварительное понимание регулярных выражений Python (4)
Сегодня я продолжу делиться базовыми знаниями о регулярных выражениях Python. В основном я представляю использование специального символа "<>". Ниже приведено конкретное руководство. .
Все белое Введение Сверток Neural Network (CNN)
Использование внутреннего соединения, левого соединения, правого соединения в оракуле
Левое-правое соединение фактически говорит, какая таблица является результатом нашего совместного запроса ~ 1. Взаимосвязь проста select A.*, B.* from A,B where A.id = B.id select A.*, B.* from.
[Код очень подробный] POJ 2492 A Bug's Life (и проверьте коллекцию)
1. Описание заголовка 2. Инструкции по анализу алгоритмов и руководство по написанию кода. Похожие темы:POJ 1182 Решение проблемы пищевой цепи Наблюдается m насекомых и n вязок. Насекомые u и v могут .
Современный человек стремится автоматизировать как можно больше сфер своей личной и профессиональной жизни. Ранее в нашем блоге мы уже рассмотрели возможность автоматизированного сбора данных со счётчиков расхода воды в заданный период времени. В этой статье мы рассмотрим ещё один вариант автоматизации – отправку ежемесячного отчёта о данных расхода воды при помощи интеграции устройства мониторинга компании NetPing с системой мониторинга Zabbix.
В отчёте необходимо отразить следующую информацию:
- дата отправки отчёта;
- информация о счётчике;
- итоговый расход воды/электроэнергии за последний месяц;
- показания на начало периода;
- показания на конец периода;
- итоговая сумма оплаты в рублях по тарифу
Требуемое оборудование и программное обеспечение
Для реализации отправки ежемесячных отчётов нам потребуется следующий комплект оборудования:
- Устройство удалённого мониторинга NetPing IO v2 или UniPing v3 – 1 шт.;
- Счётчики расхода воды с импульсным выходом – 2 шт.;
- ПК или сервер для сбора и хранения информации с установленной системой мониторинга Zabbix – 1 шт.;
- Локальная/глобальная сеть передачи данных – 1 шт.
Считаем, что устройство мониторинга NetPing IO v2 настроено на работу в вашей локальной сети. Подробнее ознакомиться с настройками NetPing IO v2 можно в документации. Счётчики расхода воды с импульсным выходом подключены к соответствующим линиям ввода-вывода устройства NetPing IO v2 и настроены в соответствии с рекомендациями этой статьи. Также считаем, что система мониторинга Zabbix настроена на работу с устройством мониторинга NetPing IO v2 и счётчиками расхода воды с импульсным выходом (подробнее здесь). В этом примере мы используем Zabbix версии 3.4.8.
Настройка устройства мониторинга NetPing IO v2
Для большей информативности отчётов, нужно указать памятки IO линиям устройства NetPing IO v2, к которым подключены счётчики расхода воды с импульсным выходом. Для этого переходим на страницу «Ввод-вывод» через навигационное меню под шапкой web-интерфейса устройства мониторинга NetPing IO v2 и заполняем параметр «Памятка» для IO линии 1 и IO линии 2. К сожалению, Zabbix не распознает кириллицу, переданную по протоколу SNMP, поэтому памятки нужно указать латиницей. Настройки остальных параметров IO линий подробно рассматриваются здесь.
Настройка системы мониторинга Zabbix для отправки e-mail отчётов.
Далее переходим в web-интерфейс системы мониторинга Zabbix. Следуя этой статье, мы добавили по два новых элемента данных для каждого из счётчиков – для получения текущих показаний расхода воды от счётчика и вычисляемые элементы данных, которые определяют расход воды за месяц:
Создадим ещё два вычисляемых элемента данных: один для счётчика холодной воды, второй для счётчика горячей, которые будут вычислять стоимость расхода воды за месяц. Переходим на страницу «Configuration → Hosts →Items»:
Нажимаем кнопку «Create Item»:
Заполняем поля в открывшейся форме, как в нашем примере:
где:
Name – название элемента данных в Zabbix. В нашем примере «Price_cold» для счётчика холодной воды и «Price_hot» для счётчика горячей воды;
Type – параметр, определяющий метод опроса элемента данных;
Ключ – уникальное имя ключа элемента данных в пределах одного узла. В нашем примере «1price» для счётчика холодной воды и «2price» для счётчика горячей воды;
Formula – арифметическое выражение для расчёта необходимых показаний на основе других элементов данных.
В нашем примере мы умножаем расход воды за месяц на стоимость одного кубометра по тарифам ЖКХ. Для счётчика холодной воды последнее значение элемента данных «1month» умножаем на 33,03 руб. Для счётчика горячей воды последнее значение элемента данных «2month» умножаем на 116,86 руб (тарифы условны). Нажимаем кнопку «Add» и повторяем создание элемента данных для второго счётчика.
Далее нам необходимо настроить ежемесячную отправку отчёта на e-mail. Переходим на страницу «Administration → Media Types». Проверьте, что способ оповещения «Email» активен. Если требуется, активируйте его и произведите настройку в соответствии с документацией.
Затем переходим к настройкам пользователя Admin «Administration → Users» и добавляем новый способ оповещения на вкладке «Media». Нажимаем ссылку «Add» и в появившемся pop-up окне «Media» прописываем параметры, как в нашем примере:
где:
Type – параметр для выбора способов оповещения, созданных ранее в системе мониторинга Zabbix («Administration → Media Types»). В нашем случае выбираем из списка тип оповещения «Email»;
Send to – адрес ящика , на который будут отправляться e-mail отчёты;
When active – время срабатывания данного оповещения. Настройку можно оставить по умолчанию;
Use if severity – важность триггера. Чек-боксы определяют, при какой важности триггера будет срабатывать данное оповещение. В примере установлены все чек-боксы для лучшей наглядности данного параметра.
Enabled – параметр для включения и отключения данного оповещения.
Сохраняем изменения нажатием кнопок «Add» и «Update».
Далее переходим к созданию действия, при выполнении которого будут отправляться наши e-mail отчёты. В этой статье мы рассмотрим отправку e-mail отчёта с показаниями счётчиков 1 раз в месяц по 20 числам. Сначала создадим триггер, при срабатывании которого будет отправляться ежемесячный отчёт. Переходим на страницу «Configuration → Hosts →Triggers» и нажимаем кнопку «Create trigger»:
Заполняем поля в открывшейся форме, как на скриншоте:
где:
Name – название триггера. В нашем примере «Monthly report cold water» для счётчика холодной воды и «Monthly report hot water» для счётчика горячей воды;
Severity – выбор требуемой важности триггера. Выбираем уровень важности «Information»;
Expression – логическое выражение, при истинности которого срабатывает триггер.
Для настройки логического выражения нажимаем кнопку «Add» (1) и заполняем поля в открывшейся форме:
где:
Item – выбираем элемент данных, который соответствует требуемому счётчику. В нашем примере «NetPing IO v2: Water meter 1 Cold Water Supply» для счётчика холодной воды и «NetPing IO v2: Water meter 2 Hot Water Supply» для счётчика горячей воды;
Function – выбираем из выпадающего списка «Day of month is = N»;
N – указываем требуемый день месяца. В нашем примере 20.
Далее нажимаем кнопку «Insert». Остальные параметры можно оставить по умолчанию. Сохраняем изменения нажатием кнопки «Add» (2). Повторяем создание триггера для второго счётчика расхода воды.
Затем переходим в раздел «Configuration → Actions» и нажимаем кнопку «Create Action»:
В открывшемся окне на вкладке «Action» заполняем поля как в нашем примере. Здесь нам необходимо отсортировать триггеры, при срабатывании которых будут отправляться e-mail отчёты:
где:
Name – уникальное имя действия. В нашем примере «Monthly report cold water» для счётчика холодной воды и «Monthly report hot water» для счётчика горячей воды;
Conditions – условия, при которых будет срабатывать действие. В нашем примере имена триггеров, при срабатывании которых отправляются e-mail отчёты, «NetPing IO v2: Monthly report cold water» для счётчика холодной воды и «NetPing IO v2: Monthly report hot water» для счётчика горячей воды;
New condition – поле для создания нового условия. Добавление правил подтверждается нажатием на ссылку «Add» в поле «New condition»;
Enabled – параметр для включения и отключения данного действия.
Затем переходим на вкладку «Operations» и прописываем текст e-mail отчёта, который будет отправлен при срабатывании триггера, описанного на вкладке «Action»:
В поле «Operations» нажимаем ссылку «New» и заполняем развернувшуюся форму описания действия как в нашем примере. Добавляем пользователя «Admin» в поле «Send to Users». В поле «Send only to» выбираем из списка тип уведомления «Email». Подтверждаем изменения нажатием ссылки «Add» (1):
Подтверждаем создание нового действия нажатием кнопки «Add» (2). Повторяем создание триггера для второго счётчика расхода воды.
Теперь по 20 числам месяца администратор системы будет получать e-mail отчёты о месячном расходе и стоимости воды:
Таким образом, мы автоматизировали не только учёт данных о расходе воды, но и отправку отчёта с билингом.
Читайте также: