Архитектуру системы мониторинга, которой я симпатизирую, можно разложить на компоненты ( за которыми можно увидеть процессы):
1) Ядро, позволяющее генерировать события на основе данных от агентов. Триггеры. Отправка событий дальше. В систему обработки событий, а если таковой нет, то непосредственно заниматься уведомлениями.
2) Агенты. Сбор данных(метрик) с конечных устройств. Агенты собирают данные с ОС и ПО или удаленно, используя разнообразные протоколы.
3) База данных истории. Тем или иным образом данные от агентов попадают в базу данных истории.
4) Ну и портал. Интерфейс для тех данных что доступны. Хоть реальные данные с агентов, хоть данные из истории.
5) Система отчетности. Генерация отчетов на основе данных истории. Вывод данных html, excel, pdf и т. п.
А дальше еще куча компонентов.
Разработчики систем мониторинга могут перетасовывать основные компоненты разнообразным образом, решая свои задачи.
Так вот. Мое мнение что надо было разобраться с системой отчетности от той системы мониторинга, которая максимально удовлетворяет ваши потребности. Или прикрутить готовую систему отчетности к системе мониторинга или написать свою. Создание компонентов, которые можно интегрировать с существующими системами более продуктивно, чем создавать с нуля новые системы целиком.
Очень интересная фишка Zabbix это тригеры по истории. Но это являеться и не достатком. Для тригеров по истории нужна история в DB Zabbix. Для тригеров важны актуальные данные. В сумме получается непрерывный поток горячих данных, которые сохраняются в DB Zabbix. Отсюда высокие требования к СХД. Желательно реализовать «партиционирование»(если не путаю термин). Это откровение бывает растраивает тех, кто пытаесь «бесплатно» внедрить мониторинг для относительно крупнных инсталяций и параноей мониторить все раз в секунду.
А если еще поднять вопрос отказоустойчивости. Какой допустимый минимальный простой системы мониторинга? Резервное копирование сервера и базы данных? А большая часть внедрения, это постановка на мониторинг ИТ-инфраструктуры как сервисов.
Для системы мониторинга тоже актуальны такие вещи как: Согласования, разработка, внедрение, документирование, поддержка, развитие. И допущенные технические просчеты на этапе внедрения будут увеличивать сложность обслуживания в продуктиве.
В статье конечно все есть, но начинать стоит с простого. Что на роутере уже не помню. Настроил и забыл. Записи генерал через wpa_passphrase. Небезопасно?
Про ITM — Согласен. Подробней так:
1) Задаем в портале ситуацию.
2) Ситуация компилируется в select вариант. Потом в бинарный вид.
3) Результат на шаге 2 отправляется на агенты.
4) Агент исполняет этот sql с заданным периодом(скажем каждые 5 минут).
5) Если sql вернул строки, то данные уходят на сервер, где проверяются на пороги и генерируются события.
Если говорить о метриках, то в ITM это строка из таблицы с несколькими полями, а не ключ- значение.
В Zabbix агент каждый раз собирает метрики(сохраняет в буфер или сразу шлет, не важно) и отсылает на сервер. Я хотел донести мысль, что можно не отсылать данные на сервер если пороги не превышены.
Правильно ли я понял что события от Zabbix и vmalert обрабатываются разработанным решением в экосистеме kafka?
Есть стандартные способы хранения данных в key-value и они все(не уверен) перечислены в статье https://habr.com/ru/company/vk/blog/480850/
1) Если не нужен поиск по содержимому данных и получение частичных данных, то структура ключа как обычно.
Key1 | {Field1:Val1,Field2:Val2}
2) Если нужно получения только части данных. Естественно база должна уметь scan с первого совпадения части ключа.
Key1.Filed1 | {Val1}
Key1.Filed2 | {Val2}
3) Если нужен поиск по содержимому
Key1.Field1.Val1|NULL
Key1.Field2.Val2|NULL
1) Ядро, позволяющее генерировать события на основе данных от агентов. Триггеры. Отправка событий дальше. В систему обработки событий, а если таковой нет, то непосредственно заниматься уведомлениями.
2) Агенты. Сбор данных(метрик) с конечных устройств. Агенты собирают данные с ОС и ПО или удаленно, используя разнообразные протоколы.
3) База данных истории. Тем или иным образом данные от агентов попадают в базу данных истории.
4) Ну и портал. Интерфейс для тех данных что доступны. Хоть реальные данные с агентов, хоть данные из истории.
5) Система отчетности. Генерация отчетов на основе данных истории. Вывод данных html, excel, pdf и т. п.
А дальше еще куча компонентов.
Разработчики систем мониторинга могут перетасовывать основные компоненты разнообразным образом, решая свои задачи.
Так вот. Мое мнение что надо было разобраться с системой отчетности от той системы мониторинга, которая максимально удовлетворяет ваши потребности. Или прикрутить готовую систему отчетности к системе мониторинга или написать свою. Создание компонентов, которые можно интегрировать с существующими системами более продуктивно, чем создавать с нуля новые системы целиком.
А если еще поднять вопрос отказоустойчивости. Какой допустимый минимальный простой системы мониторинга? Резервное копирование сервера и базы данных? А большая часть внедрения, это постановка на мониторинг ИТ-инфраструктуры как сервисов.
Для системы мониторинга тоже актуальны такие вещи как: Согласования, разработка, внедрение, документирование, поддержка, развитие. И допущенные технические просчеты на этапе внедрения будут увеличивать сложность обслуживания в продуктиве.
У меня так:
Файл /etc/network/interfaces.d/wlan0
iface wlan0 inet dhcp
wpa-conf /etc/wpa_supplicant.conf
Файл /etc/wpa_supplicant.conf
network={
ssid=«Net_Home»
psk=111111111111111111111111111111111111111111111111111111111111
}
network={
ssid=«Net_Mob»
psk=111111111111111111111111111111111111111111111111111111111111
}
network={
ssid=«Net_Work»
key_mgmt=NONE
}
Когда нужен инет
sudo ifup wlan0
Когда не нужен
sudo ifdown wlan0
1) Задаем в портале ситуацию.
2) Ситуация компилируется в select вариант. Потом в бинарный вид.
3) Результат на шаге 2 отправляется на агенты.
4) Агент исполняет этот sql с заданным периодом(скажем каждые 5 минут).
5) Если sql вернул строки, то данные уходят на сервер, где проверяются на пороги и генерируются события.
Если говорить о метриках, то в ITM это строка из таблицы с несколькими полями, а не ключ- значение.
В Zabbix агент каждый раз собирает метрики(сохраняет в буфер или сразу шлет, не важно) и отсылает на сервер. Я хотел донести мысль, что можно не отсылать данные на сервер если пороги не превышены.