Введение
Если у вас еще нет своего сервера для мониторинга, то рекомендую материалы на эту тему. Для тех, кто предпочитает систему CentOS:
- Установка CentOS 8.
- Настройка CentOS 8.
- Установка и настройка zabbix сервера.
То же самое на Debian 10, если предпочитаете его:
- Установка Debian 10.
- Базовая настройка Debian.
- Установка и настройка zabbix на debian.
В заббикс существуют различные способы получать данные для мониторинга. Наиболее распространенные источники информации:
- Zabbix агент. Устанавливается на наблюдаемую машину и отправляет данные на сервер мониторинга.
- SNMP агент. Чаще всего присутствует на устройстве, либо может быть установлен на сервер.
- Простые проверки — simple check. Выполняются непосредственно на сервере zabbix с помощью встроенных инструментов, не требуют дополнительных действий со стороны хоста.
- Внешние проверки — external checks. Как и простые проверки выполняются на сервере мониторинга, но не встроенными средствами, а внешними скриптами.
Есть и другие способы получения данных. Не буду их все перечислять, ознакомиться с ними можно в соответствующем разделе официальной документации. В нашем случае мы воспользуемся первыми двумя способами для мониторинга служб и сервисов в linux.
Тут можно пойти разными путями. Меня интересует мониторинг различных линукс служб, работающих как локально (samsdaemon, postgrey) в пределах конкретного сервера, так и для публичного доступа по сети, в частности squid, smtp, imap, http. Первое, что пришло в голову, это использовать итем с ключом service_state[]. Но как оказалось, этот тип данных снимает значения только с системных служб windows. Я не сразу это понял и некоторое время повозился в консоли, не понимая, почему при тестировании значения получаю сообщение, что данный item не поддерживается:
# zabbix_agent -t service_state service_state
Дальше придумал через UserParameter запускать какой-нибудь скрипт, который будет проверять запущен ли сервис в системе или нет. Например с помощью ps ax | grep squid. В принципе, рабочий вариант, но мне казалось, что такую простую задачу можно решить проще и быстрее, без создания на каждом хосте скрипта и изменения файла конфигурации. И я не ошибся. Есть 2 различных способа мониторинга служб (сервисов) в linux с помощью zabbix. Рассмотрим первый из них.
Я ничего не понял. JMX, RMI, JNDI? WTF?
Хорошо-хорошо, давайте немного разберёмся, как всё это работает.JMX (Java Management Extensions) — технология Java, предназначенная для мониторинга и управления (в т.ч. удалённо) различными объектами (ресурсами): приложениями, устройствами, сетями — лишь бы этот объект был написан на Java.
Эти ресурсы называются MBeans (ManagedBeans). Каждый такой объект реализует определённый интерфейс, через который можно получить доступ к значениям атрибутов этого объекта, а также вызвать его методы и получать уведомления (если приложение зарегистрирует соответствующие “слушающие” MBean’ы).
MBeans регистрируются на MBean Server — реестре объектов. Любой зарегистрированный объект становится доступным для приложений (точнее, становится доступным его интерфейс).
Доступ к ресурсам осуществляется при помощи JMX-коннекторов, которые делают MBean Server доступным для JMX-клиентов. JMX-коннектор состоит из клиента и сервера. Коннектор-сервер соединяется с MBean-сервером и слушает запросы соединений от клиентов. Коннектор-клиент обычно находится на другой JVM, а чаще всего вообще на другой машине по отношению к коннектор-серверу.
JMX API имеет стандартный протокол подключения, основанный на Remote Method Invocation (RMI). Этот протокол позволяет JMX-клиенту удалённо получить доступ к MBean’ам на MBean-сервере. Кроме штатного RMI существуют и другие протоколы: JMXMP, JBoss Remoting, Hessian, Burlap, и даже HTTP и SNMP.
Используя интерфейс MBean’а клиент может получать различные метрики этого объекта, а также вызывать публичные методы.
Схематично взаимодействие компонентов можно изобразить так:
Любое приложение на платформе Java SE “из коробки” имеет возможности для его мониторинга: RMI коннектор автоматически делает доступным ваше Java приложение для удалённого управления и мониторинга. Достаточно лишь запустить приложение с нужными параметрами, и JMX-клиенты (а Zabbix Java Gateway — это JMX-клиент) уже смогут подключаться к нему удалённо и получать нужные метрики.
Чтобы указать JMX-клиенту конкретное приложение, к которому вы хотите подключиться, используется специальный адрес, который называется JMX endpoint (он же JMXServiceURL). Если говорить строже, то это адрес коннектор-сервера JMX API. Формат этого адреса определяется RFC 2609 и RFC 3111. В общем случае он выглядит так:
Где «service:jmx:» — константа.
protocol — это транспортный протокол (один из многих: RMI, JMXMP, etc), используемый для подключения к коннектор-серверу.sap — адрес, по которому коннектор-сервер может быть найден. Задаётся в таком формате (это подмножество синтаксиса, определённого в RFC 2609):
host — ipv4 адрес хоста (или ipv6, заключённый в квадратные скобки) и необязательный (в зависимости от протокола) номер порта.url-path — необязательный URL (обязательность зависит от протокола).
Лучше всего разобраться с этим на примере. Часто можно встретить такой JMX endpoint, вид которого некоторых может ввести в ступор:
Но на самом деле не всё так страшно.host — это целевой хост, где запущено наше приложение.port1 — это порт RMI-сервера, к которому мы хотим подключиться.
а port2 — это порт RMI registry (каталог, где регистрируются RMI-серверы). По умолчанию: 1099.
Если знать о том, что RMI-реестр выдаёт адрес и порт RMI-сервера по запросу клиента, то становится понятно, что первая часть здесь лишняя. Таким образом адрес можно сократить до такого вида:url-path часть означает буквально следующее: возьми ту часть URL, которая следует сразу за /jndi/ и выполни по этому адресу JNDI-запрос в RMI registry, чтобы получить информацию об RMI-сервере. Реестр вернёт в ответ его хост и порт.
Следует отметить, что порт в таком случае генерируется случайным образом и могут возникнуть проблемы с настройкой файрвола. В таких случаях и записи JMX endpoint’а, потому что он позволяет явно указать порт.
Если вам хотелось бы глубже разобраться в JMX, то рекомендуем обратиться к официальной документации Oracle.
Модуль мониторинга PostgreSQL в составе Zabbix Agent 2
Для соединения с PostgreSQL используется быстрый и популярный драйвер pgx (PG driver and toolkit for Go).
Пока мы используем два интерфейса: Exporter, вызывающий обработчик по ключу, и Configurator Zabbix Agent 2, который считывает и проверяет параметры соединения с сервером, заданные в конфигурационном файле.
Мы постарались оптимизировать работу СУБД, группируя метрики и используя обработчик (handler) для метрик и групп метрик, а также используя группы метрик в JSON как зависимые переменные (dependency items), и низкоуровневое обнаружение (discovery rules).
Основные возможности
- сохранение постоянного соединения с PostgreSQL между проверками;
- поддержка гибких интервалов опроса;
- совместимость с версиями PostgreSQL, начиная с 10, и Zabbix Server, начиная с версии 4.4;
- возможность подключения и мониторинга нескольких инстансов PostgreSQL одновременно благодаря тому, что Zabbix Agent 2 позволяет создавать несколько сессий.
Уровни параметров подключения к PostgreSQL
Всего доступны три уровня параметров подключения к PostgreSQL, т. е. задач и настроек:
- Global,
- Sessions,
- Macros.
-
Параметры Global задаются на уровне агента, параметры Session и Macros определяют параметры подключения базе.
-
Параметры подключения к PostgreSQL — Sessions задаются в файле zabbix_agent2.conf.
Параметры подключения к PostgreSQL — Sessions
- После ключевого слова Sessions указывается уникальное имя сессии, которое должно быть указано в ключе (шаблоне).
- Параметры URI и UserName обязательны для каждой сессии.
- Если имя базы не задано, используется общее по умолчанию имя базы для всех сессий для PostgreSQL, которое также задается в конфигурационном файле.
- Параметры подключения к PostgreSQL — Macros задаются в ключе метрики в шаблоне (аналогично способу, использованному в Zabbix Agent 1), т. е. создаются в шаблоне и далее указываются как параметры в ключе. При этом последовательность макросов фиксирована, т. е., например, URI всегда указывается на первом месте.
Параметры подключения к PostgreSQL — Macros
Модуль мониторинга PostgreSQL включает уже более 95 метрик, которые позволяют охватить довольно широкий объем параметров PostgreSQL, включая:
- количество соединений,
- объем баз данных,
- архивация wal-файлов,
- контрольные точки,
- количество «раздувшихся» таблиц,
- статус репликации,
- отставание реплики.
Метрики PostgreSQL не информативны без параметров операционной системы. Но Zabbix Agent 2 уже умеет собирать параметры операционной системы, поэтому для получения полной картины просто подключаем к узлу сети необходимые шаблоны.
Обработчик (handler)
Обработчик (handler) — основная единица модуля, в которой выполняется сам запрос и которая позволяет получать метрики.
Чтобы получить простую метрику:
- Создаем файл для получения новой метрики:
zabbix/src/go/plugins/postgres/handler_uptime.go
- Подключаем пакет и указываем уникальный ключ (ключи) метрик:
- Создаем обработчик (handler) с запросом, т. е. инициируем переменную, в которой будет результат:
- Выполняем запрос:
Необходимо проверить запрос на предмет ошибок, после чего результат будет подхвачен процессом Zabbix Agent 2.
- Регистрируем ключ новой метрики:
После регистрации метрики можно пересобирать агент с новой метрикой.
Модуль доступен, начиная с Zabbix 5.0 на сайте https://www.zabbix.com/download. В этой версии Zabbix параметры задаются отдельно через host и port. В версии Zabbix 5.0.2, которая скоро выйдет, параметры подключения будут скомпонованы в один URI.
Спасибо за внимание!
#10. Sensu
Ключевые особенности:
- Sensu – это инструмент для мониторинга событий с открытым исходным кодом.
- Sensu контролирует серверы, службы, работоспособность приложений, сеть.
- Инструмент мониторинга Sensu использует стороннюю интеграцию.
- Инструмент мониторинга Sensu использует агент sensu для проверки операционной системы и показателей.
- Мы можем контролировать облачную инфраструктуру с помощью инструмента мониторинга sensu.
- Sensu написан на Ruby.
Преимущества:
- Инструмент мониторинга Sensu является портативным.
- Простота использования
- Инструмент для мониторинга Sensu быстрый.
см. также:
А что там с JMX обнаружением?
JMX обнаружение появилось в Zabbix одновременно с появлением нативной поддержки мониторинга Java приложений через JMX. За эту функцию отвечает недокументированный (на тот момент) ключ jmx.discovery. В документации о нём не было ни слова, потому что это была ещё очень сырая функция:
- В таком обнаружении нет особого смысла, потому что нет никаких возможностей для фильтрации. А вряд ли кому-то требуется обнаруживать все существующие JMX-объекты.
- Это очень медленное решение, т.к. здесь выполняется по одному запросу на каждый MBean, а их может быть довольно много. Очень вероятно, что такая проверка просто отвалится по таймауту.
- В таком виде можно создать лишь одно правило обнаружения в рамках хоста, что весьма печально, потому что на практике хотелось бы создавать множество правил (банально могут отличаться типы данных для разных атрибутов).
В Zabbix 3.4 появилась возможность фильтрации, что сразу решает многие проблемы.
Новая проверка выглядит так:
И позволяет указать, требуется ли обнаружение MBean’ов или их атрибутов, а также по какому шаблону их искать.
Давайте попробуем её в деле! Замониторим, к примеру, сборщики мусора. Известно, что их имена могут различаться в зависимости от того, с какими параметрами запущена JVM. А значит мы не можем задать статичные имена и ключи для элементов данных — это работёнка как раз для jmx.discovery.Документация описывает нам четыре примера использования:
Ключ | Описание |
---|---|
Получение всех JMX MBean атрибутов | |
Получение всех JMX MBeans | |
Получение всех атрибутов сборщика мусора | |
Получение всех сборщиков мусора |
Первые два варианта мы использовать не будем, т.к. это не очень хорошо с точки зрения производительности. Посмотрим, что возвращают нам два последних.
Для этой цели мы можем просто создать item с нужным нам ключом и текстовым типом данных. Но это не очень удобно. Во-первых, вывод будет неформатированным и ненаглядным. Во-вторых, чтобы изменить запрос, нам всякий раз придётся изменять ключ item’а и какое-то время ждать обновления данных.
Это не наш путь. Давайте лучше сделаем что-то вроде zabbix_get, только вместо агента будем обращаться к Java Gateway. Для этого немного доработаем предложенный в этой заметке скрипт под новый API: добавим jmx_endpoint в запрос и поправим удаление заголовка из ответа:
Теперь мы с лёгкостью можем посмотреть, что возвращает нам шлюз в ответ на наши запросы:
То что нужно!
Если бы нам требовалась, допустим, всего пара метрик, то мы могли бы обнаружить все gc и создать на каждую метрику по прототипу.
Создаём правило обнаружения
Ищем MBean’ы (кстати, обратите внимание, что везде используется кастомный JMX endpoint).
Создаём прототипы на каждую интересующую нас метрику. В имени элемента данных и его ключе мы можем использовать любые макросы, которые видели в JSON’е.
Кстати, о макросах. При обнаружении MBean’ов макросы генерируются динамически на основе свойств MBean’ов (таких как type и name).
Но, допустим, мы хотим создать все доступные числовые метрики по сборщикам мусора.
- Тогда мы создадим правило обнаружения атрибутов с фильтром по типу данных.
- И всего лишь один прототип:
Вот таким нехитрым образом можно замониторить любое Java приложение. Дерзайте!
Дополнительные материалы по Zabbix
Онлайн курс «DevOps практики и инструменты»
Если у вас есть желание научиться строить и поддерживать высокодоступные и надежные системы, научиться непрерывной поставке ПО, мониторингу и логированию web приложений, рекомендую познакомиться с онлайн-курсом «DevOps практики и инструменты» в OTUS. Курс не для новичков, для поступления нужны базовые знания по сетям и установке Linux на виртуалку. Обучение длится 5 месяцев, после чего успешные выпускники курса смогут пройти собеседования у партнеров.
Проверьте себя на вступительном тесте и смотрите программу детальнее по .
Рекомендую полезные материалы по Zabbix: |
Настройки системы |
---|
Видео и подробное описание установки и настройки Zabbix 4.0, а также установка агентов на linux и windows и подключение их к мониторингу. Подробное описание обновления системы мониторинга zabbix версии 3.4 до новой версии 4.0. Пошаговая процедура обновления сервера мониторинга zabbix 2.4 до 3.0. Подробное описание каждого шага с пояснениями и рекомендациями. Подробное описание установки и настройки zabbix proxy для организации распределенной системы мониторинга. Все показано на примерах. Подробное описание установки системы мониторинга Zabbix на веб сервер на базе nginx + php-fpm. |
Мониторинг служб и сервисов |
Мониторинг температуры процессора с помощью zabbix на Windows сервере с использованием пользовательских скриптов. Настройка полноценного мониторинга web сервера nginx и php-fpm в zabbix с помощью скриптов и пользовательских параметров. Мониторинг репликации mysql с помощью Zabbix. Подробный разбор методики и тестирование работы. Описание настройки мониторинга tcp служб с помощью zabbix и его инструмента простых проверок (simple checks) Настройка мониторинга рейда mdadm с помощью zabbix. Подробное пояснение принципа работы и пошаговая инструкция. Подробное описание мониторинга регистраций транков (trunk) в asterisk с помощью сервера мониторинга zabbix. Подробная инструкция со скриншотами по настройке мониторинга по snmp дискового хранилища synology с помощью сервера мониторинга zabbix. |
Мониторинг различных значений |
Настройка мониторинга web сайта в zabbix. Параметры для наблюдения — доступность сайта, время отклика, скорость доступа к сайту. Один из способов мониторинга бэкапов с помощью zabbix через проверку даты последнего изменения файла из архивной копии с помощью vfs.file.time. Подробное описание настройки мониторинга размера бэкапов в Zabbix с помощью внешних скриптов. Пример настройки мониторинга за временем делегирования домена с помощью Zabbix и внешнего скрипта. Все скрипты и готовый шаблон представлены. Пример распознавания и мониторинга за изменением значений в обычных текстовых файлах с помощью zabbix. Описание мониторинга лог файлов в zabbix на примере анализа лога программы apcupsd. Отправка оповещений по событиям из лога. |
#8. MRTG
Ключевые особенности:
- MRTG расшифровывается как Multi Router Traffic Grapher.
- MRTG – это инструмент мониторинга сети.
- MRTG использует SNMP (Simple Network Management Protocol для мониторинга сетевого трафика.
- У MRTG есть агент, который знает управленческую информацию на местном уровне.
- NMS (Network Management System) система в MRTG, которая запускает приложения, которые контролирует управляемые устройства.
- В управляемом устройстве MTRG содержит агент SNMP и находится в управляемой сети.
Преимущества:
- MRTG предоставляет ресурсы, необходимые для управления сетью.
- Агент делает информацию доступной по протоколу SNMP.
- С помощью MRTG анализируется сетевой трафик.
- Живой сетевой трафик такой анализируется в MRTG.
- Сетевой трафик также отслеживается на наших сетевых портах и ссылках.
- MRTG – это инструмент мониторинга с открытым исходным кодом.
- Есть оптимизация сети.
- Есть устранение неполадок сети.
см. также:
Дополнительные материалы по Zabbix
Онлайн курс «DevOps практики и инструменты»
Если у вас есть желание научиться строить и поддерживать высокодоступные и надежные системы, научиться непрерывной поставке ПО, мониторингу и логированию web приложений, рекомендую познакомиться с онлайн-курсом «DevOps практики и инструменты» в OTUS. Курс не для новичков, для поступления нужны базовые знания по сетям и установке Linux на виртуалку. Обучение длится 5 месяцев, после чего успешные выпускники курса смогут пройти собеседования у партнеров.
Проверьте себя на вступительном тесте и смотрите программу детальнее по .
Рекомендую полезные материалы по Zabbix: |
Настройки системы |
---|
Видео и подробное описание установки и настройки Zabbix 4.0, а также установка агентов на linux и windows и подключение их к мониторингу. Подробное описание обновления системы мониторинга zabbix версии 3.4 до новой версии 4.0. Пошаговая процедура обновления сервера мониторинга zabbix 2.4 до 3.0. Подробное описание каждого шага с пояснениями и рекомендациями. Подробное описание установки и настройки zabbix proxy для организации распределенной системы мониторинга. Все показано на примерах. Подробное описание установки системы мониторинга Zabbix на веб сервер на базе nginx + php-fpm. |
Мониторинг служб и сервисов |
Мониторинг температуры процессора с помощью zabbix на Windows сервере с использованием пользовательских скриптов. Настройка полноценного мониторинга web сервера nginx и php-fpm в zabbix с помощью скриптов и пользовательских параметров. Мониторинг репликации mysql с помощью Zabbix. Подробный разбор методики и тестирование работы. Описание настройки мониторинга tcp служб с помощью zabbix и его инструмента простых проверок (simple checks) Настройка мониторинга рейда mdadm с помощью zabbix. Подробное пояснение принципа работы и пошаговая инструкция. Подробное описание мониторинга регистраций транков (trunk) в asterisk с помощью сервера мониторинга zabbix. Подробная инструкция со скриншотами по настройке мониторинга по snmp дискового хранилища synology с помощью сервера мониторинга zabbix. |
Мониторинг различных значений |
Настройка мониторинга web сайта в zabbix. Параметры для наблюдения — доступность сайта, время отклика, скорость доступа к сайту. Один из способов мониторинга бэкапов с помощью zabbix через проверку даты последнего изменения файла из архивной копии с помощью vfs.file.time. Подробное описание настройки мониторинга размера бэкапов в Zabbix с помощью внешних скриптов. Пример настройки мониторинга за временем делегирования домена с помощью Zabbix и внешнего скрипта. Все скрипты и готовый шаблон представлены. Пример распознавания и мониторинга за изменением значений в обычных текстовых файлах с помощью zabbix. Описание мониторинга лог файлов в zabbix на примере анализа лога программы apcupsd. Отправка оповещений по событиям из лога. |
Установка Zabbix Agent на Linux
Если вы хотите установить zabbix-agent на сам сервер мониторинга, то ничего делать не надо, кроме самой установки. Для других систем необходимо подключить репозитории заббикса, которые мы использовали во время установки сервера. Можете посмотреть их в соответствующих разделах для своей системы.
Установка zabbix agent в Centos:
# yum install zabbix-agent
Тоже самое в Ubuntu/Debian:
# apt install zabbix-agent
Для работы с сервером, который установлен локально на этой же машине, больше никаких настроек не надо делать. Если же вы будете устанавливать zabbix agent на другую машину, то в файле конфигурации агента /etc/zabbix/zabbix_agentd.conf нужно будет задать следующие параметры:
# mcedit /etc/zabbix/zabbix_agentd.conf
Server=192.168.13.117 ServerActive=192.168.13.117 Hostname=srv10 # имя вашего узла мониторинга, которое будет указано на сервере zabbix, Zabbix server если это сам сервер заббикса
Запускаем агент и добавляем в автозагрузку:
# systemctl start zabbix-agent # systemctl enable zabbix-agent
Проверяем лог файл.
# cat /var/log/zabbix/zabbix_agentd.log 14154:20181004:201307.800 Starting Zabbix Agent . Zabbix 4.0.0 (revision 85308). 14154:20181004:201307.800 **** Enabled features **** 14154:20181004:201307.800 IPv6 support: YES 14154:20181004:201307.800 TLS support: YES 14154:20181004:201307.800 ************************** 14154:20181004:201307.800 using configuration file: /etc/zabbix/zabbix_agentd.conf 14154:20181004:201307.800 agent #0 started 14157:20181004:201307.801 agent #3 started 14159:20181004:201307.802 agent #5 started 14155:20181004:201307.804 agent #1 started 14158:20181004:201307.806 agent #4 started 14156:20181004:201307.810 agent #2 started
Все в порядке. Идем в веб интерфейс и проверяем поступление данных. Для этого идем в раздел Мониторинг -> Последние данные. Указываем в разделе Узлы сети Zabbix Server и ждем поступления первых данных. Они должны пойти через 2-3 минуты после запуска агента.
Теперь попробуем остановить агент и проверить, придет ли уведомление на почту. Идем в консоль и выключаем агента:
# systemctl stop zabbix-agent
Ждем минимум 5 минут. Именно такой интервал указан по-умолчанию для срабатывания триггера на недоступность агента. После этого проверяем главную панель, виджет Проблемы.
Настройка из Веб интерфейса
Откроется страница приветствия
Нажмите «Next step».
Далее вы попадете на страницу преднастроек. Если вы ранее указали временную зону, то во всех пунктах должно быть «ОК».
Нажмите «Next step».
Укажите данные для подключения к ранее созданной базе данных.
В поле:
Database host — укажите адрес сервера 127.0.0.1Database port — стандартный порт postgres 5432Database name — имя базы данных zabbixUser — логин пользователя zabbixPassword — пароль пользователя zabbixpassword
Нажмите «Next step». При неправильно указанных данных или неправильной конфигурации базы данных появится сообщение об ошибке подключения к базе.
В этом окне нужно ввести IP адрес хоста сервера zabbix и номер порта для его работы. Можно оставить значения по умолчанию.
Нажмите «Next step».
Проверьте правильность введенных данных и нажмите «Next step».
При успешном окончании установки вы увидите следующую страницу.
Нажмите «Finish».
Введите логин и пароль сервера zabbix. По умолчанию имя пользователя Admin, пароль zabbix.
Нажмите «Sign in».
Вы попадете в панель управления. На этом zabbix настроен.
Для смены языка интерфейса зайдите в профиль и выберите нужный язык:
Для добавления нового узла в zabbix нужно открыть Настройки -> Узлы сети -> Создать узел сети.
Далее нужно вписать имя узла, указать в какой группе будет состоять узел, прописать ip или dns и нажать внизу страницы кнопку «Добавить»
Настройка новый итемов на сервере zabbix
Мы можем добавить новые итемы на одиночный хост, в котором указаны в агенте необходимые для сбора UserParameter, либо создать сразу шаблон и потом его добавить к нужным хостам. Если у вас хостов с одинаковым мониторингом больше одного, то делать нужно шаблон, чтобы упростить себе жизнь.
Создаем новый итем в хосте, либо шаблоне. Указываете следующие обязательные параметры (я рекомендую использовать английский язык везде):
Имя
Произвольное имя итема
Тип
В общем случае используются пассивные проверки (Zabbix agent)
Ключ
Название ключа, который указан в агенте в UserParameter
Тип данных
Выбираете в зависимости от типа поступаемых данных. В моем случае это были цифровые целые или с плавающей точкой, если значения дробные, и текстовые
Здесь важно не перепутать тип. Если перепутаете, получите ошибку итема.
Интервал обновления
Как часто будут поступать новые данные
На этом все. Сохраняете итем и ждете поступление данных. Числовые значения, которые генерируют скрипты на клиенте с агентом будут поступать на сервер.