Формы ФСС 2020 August 14
ну, берите если вам так удобнее
а он оттуда и берёт
дискавери зависит от этого же точно WMI get
Все перелопатил в 4.2 нет
Хотя странно, братья Латыши ж
Не странно ) Братья американцы Гейтс и Джобс как-то не особо дружили
При выполнении обнаружения выводит сообщение «Не удалось отправить запрос: ошибочный тип правила обнаружения.»
Но все таки я не понимаю =))
У каждой метрики должен быть уникальный ключ. В данном случае это зависимая метрика и имя ключа просто совпадает с аналогичным из встроенного в агента. Для однотипности. Правило обнаружения зависит от мастер метрики, так же как и прототипы в этом правиле обнаружения. Сделано для уменьшения количества опросов — не каждый ключ генерит запрос, а один мастер за раз получает все значения в json. Потом все зависимые от мастера матрики получают свои значения с помощью препроцессинга
я пытаюсь с помощью препроцессинга получить данные, точно знаю что данные в мастер метрике у меня вот такие https://codebeautify.org/jsonviewer/cb70f322
ключ в обнаружении произвольный, тип зависимый элемент от данных метрики которую я показал
А зачем прокси на роутере? У роутера подходящий диск для работы с базой данных и много свободного места? Вряд ли. Обычно стоит флэш для прошивки и логов. С большой долей вероятности впаянный. Базой данных вы его быстро ушатаете и роутер останется только выбросить
и в чём проблема?
Когда пытаюсь правило обнаружение выполнить пишет «ошибочный тип правила обнаружения.»
что указано в правиле в поле Type?
тип зависимый элемент данных
замечательно. а как настроен мастер элемент?
тип заббикс агент, читает фаил потом через js формирует json который я оптравлял
чтобы не терять данные при пропадании интернета. в обычном микротике свободно 40-50 мегабайт что оперативной памяти, что на диске. Базу в 10-20 мегабайт в памяти можно было бы держать, а это сутки-двое логов. Это для того, чтобы не ставить сервер на филиал из 3 компьютеров
Type of information у него какой?
7 Репутация автора
Я использую Zabbix 3.2 для более чем 100 виртуальных машин (Windows, Linux, Mac), и я добавил скрипт для всех виртуальных машин Windows. Сценарий является локальным для каждой виртуальной машины, и agentd.conf имеет:
Он также имеет несколько других параметров пользователя, хотя это не является частью этой проблемы.
Когда я перехожу к пунктам «Предметы», присутствует красный «i», статус «Не поддерживается», а над красным «i» говорится:
Я нахожу это очень странным, поскольку локально наблюдать за виртуальной машиной и не использовать RDP. Я пытался использовать общую папку и иметь сценарий в 1 месте. Это явно не сработало, поэтому я делаю это локально.
В журнале написано «old_random_var не поддерживается». Это еще один параметр, который работает в zabbix, но предоставляет этот журнал. Еще раз, этот old_var совершенно не связан с var.
Использование zabbix_get говорит о том, что элемент не поддерживается.
Любой совет будет принята с благодарностью.
E: Интересное дополнение, из всех узлов, оно работает примерно в 20 случайных, а не в других. В этих узлах нет НИЧЕГО уникального. Совершенно случайно.
Ответы
3091 Репутация автора
Пользовательский параметр подключается к Windows FTP. Предел подключения должен быть увеличен на стороне Windows.
Данный блог был создан как дублирование моей странички www.bubnov.su, но без всяких личных материалов – только то, что касается IT
Четверг, 19 октября 2017 г.
А триггер ты какой настроил под проверку файла?
Триггер из ленности настроил «On change» – под мою задачу хватает. хотя по идее, да, надо глубже было копнуть =)
Немного истории
Для меня описанный функционал был важен в связи с тем, что на нашем предприятии используется несколько СХД от HP, а именно HP MSA 2040/2050, метрики с которых снимаются запросами к их XML API с использованием Python-скрипта.
В самом начале, когда встала задача наблюдения за обозначенным оборудованием и был найден вариант с использованием API, выяснилось, что в самом простом случае, чтобы узнать, скажем, состояние здоровья одного компонента СХД, требовалось сделать два запроса:
Теперь представьте, что хранилище состоит из 24 дисков (а может и больше), двух блоков питания, пары контроллеров, вентиляторов, нескольких дисковых пулов и пр. — умножаем всё это на 2 и получаем более 50 элементов данных, что равно стольким же запросам к API при ежеминутных проверках. Если попробовать пойти по такому пути, API быстро «ложится», а ведь мы говорим только о запросе «здоровья» компонентов, не учитывая остальные возможные и интересные метрики — температура, наработка на часы для жестких дисков, скорость вращения вентиляторов и т.д.
Первым решением, которое я сделал чтобы разгрузить API, еще до выхода Zabbix версии 3.4, было создание кэша для получаемого токена, значение которого записывалось в файл и хранилось N-минут. Это позволило снизить количество обращений к API ровно в два раза, однако, ситуацию сильно не изменило — что-то помимо состояния здоровья получать было проблематично. Примерно в это время я посетил Zabbix Moscow Meetup 2017, устроенный компанией Badoo, где и узнал о упомянутом выше функционале зависимых элементов данных.
Скрипт был доработан до возможности отдавать подробные JSON объекты, содержащие интересующую нас информацию по различным компонентам хранилища и вывод его стал выглядеть примерно так вместо одиночных строковых или числовых значений:
Это пример с отдаваемыми данными по всем дискам хранилища. По остальным компонентам картина схожая — ключом является ID компонента, а значением — объект JSON, содержащий нужные метрики.
Всё было хорошо, но быстро всплыли нюансы, описанные в начале статьи — все зависимые метрики приходилось создавать и обновлять вручную, что было довольно мучительно (порядка 300 метрик на одну СХД плюс триггеры и графики). Нас могло бы спасти LLD, но тут, при создании прототипа, оно не позволяло нам указывать в качестве родительского айтема тот, что не был создан самим правилом, а грязный хак с созданием фиктивного айтема через LLD и подменой его itemid в БД на нужный, ронял сервер Zabbix. В багтрекере Zabbix быстро появились упомянутые фичреквесты, что указывало на то, что данный функционал важен не только мне.
Т.к. все подготовительные операции с моей стороны были завершены, я решил потерпеть и не плодить временных решений, таких как динамическая генерация шаблона и ждал только закрытия указанных в начале статьи ZBXNEXT’ов и вот совсем недавно это было сделано.
Как всё выглядит теперь
Для демонстрации новых возможностей Zabbix мы возьмем:
Родительский элемент данных будет представлять собой «внешнюю проверку» (external check), вызывающую скрипт с необходимыми аргументами и хранить полученные данные как текст.
Подготовка
Python-скрипт устанавливается в соответствии с документацией и имеет в зависимостях Python библиотеку «requests». Если у вас RHEL-based дистрибутив, установить её можно с помощью пакетного менеджера yum:
Или с помощью pip:
Протестировать работу скрипта можно из оболочки, запросив, например, данные LLD о дисках:
Настройка хоста
Для начала нужно создать родительские элементы данных, которые будут содержать все необходимые нам метрики. В качестве примера создадим такой элемент для физических дисков:
Приходит JSON, значит всё сделано правильно.
Следующим будет настройка правил обнаружения, которые отыщут все доступные для мониторинга компоненты и создадут зависимые айтемы и триггеры. Продолжая пример с физическими дисками, выглядеть оно будет так:
После создания правила LLD потребуется создать прототипы элементов данных. Создадим такой прототип, на примере данных о температуре:
Имя — указываем произвольно; Тип — зависимый. В качестве родительского элемента данных выбираем соответствующий созданный ранее элемент; Ключ — проявим фантазию, но нужно учесть, что каждый ключ должен быть уникальным, поэтому включим в него макрос LLD; Тип информации — в данном случае числовой; Период хранения истории — в примере это пользовательский макрос, указывается по вашему усмотрению; Период хранения трендов — опять же, пользовательский макрос;
Так же я добавил прототип «Приложения» — к нему можно удобно привязывать метрики, относящиеся к одному компоненту.
На вкладке «Препроцессинг» создадим шаг типа «JSON Path» с правилом, извлекающим показания температуры:
Обратите внимание, что теперь в выражении можно использовать макросы LLD, что не просто значительно упрощает нам работу, но и вообще дает проделывать подобные штуки довольно просто (раньше вас бы направили в Zabbix API).
Далее, по аналогии с температурой, создадим оставшиеся прототипы элементов данных:
На этом этапе можно проверить получаемый результат, зайдя в «Последние данные» по хосту. Если там вас всё устраивает, продолжаем работу дальше. Я в итоге получил следующую картину:
Ждем пока обновится конфигурационный кэш или толкаем его обновление вручную:
После этого можно воспользоваться еще одной крутейшей «фишкой» версии 4.0 — кнопкой «Check now» для запуска созданных правил LLD:
У меня получился следующий результат:
Заключение
В итоге, всего девятью запросами к XML API мы смогли получить более трехсот метрик с одного узла сети, затратив на это минимум времени и получив максимум гибкости. L LD даст нам возможность автоматически обнаруживать новые компоненты или обновлять старые.
Спасибо, что читали, ссылки на используемые материалы, а там же на актуальный шаблон для HPE MSA P2000G3/2040/2050 можно найти ниже.
Вот код сервиса:
код с компонента формы откуда вводятся данные:
пост метод в контроллере:
И класс в апи с этими свойствами
Все параметры в пост запросе соответствуют с теми что в классе airline
Буду признателен любой помощи и подсказке.
В свагере все работает как надо и проблема во фронтенд части как я понимаю.