ВВ
Здорово. А данные в БД какой-то хранятся?
у пртг своя структура хранения данных как для бд, журналов так и для конфигов
Size: a a a
2021 February 02
ВВ
можно разделено хранить
O
у пртг своя структура хранения данных как для бд, журналов так и для конфигов
А может алертить на основе ряда проверок типо по условиям И/ИЛИ? Типа, как я описывал -" если последний бэкап БД был больше 7 дней назад на каждой из вот этих 3 реплик, то орать"?.
ВВ
вот к примеру отправка в телегу средствами пртг, а также добавлением скрипта на pshell
O
вот к примеру отправка в телегу средствами пртг, а также добавлением скрипта на pshell
Эт понятно. Это здорово. Мне бы главное понять эта штука может использовать данные нескольких проверок на разных серверах для отправки одного алерта?
ВВ
Эт понятно. Это здорово. Мне бы главное понять эта штука может использовать данные нескольких проверок на разных серверах для отправки одного алерта?
да
O
У всего, что я видел, кроме SCOM, были большие трудности с пониманием что такое кластер и отсюда росли неепические трудности
O
Вот. спасибо!
О奧
Ну и ещё нужно правильное дерево проверок... Чтобы не проверяло если вышестоящее сломано
ВВ
Я юзал заббикс и ском. Ском чудовищно монструозен и не годится, если не втащить всю линейку system center. Zabbix мне не понравился тем, что там можно только очень прямолинейные метрики делать. Например хрен сделаешь проверку наличия бэкапа бд хотя бы на одной реплике. Про кластера он вообще ничего не понимает и хрен объяснишь ему, что служба либо на этом хосте, либо на другом и это нормально. Короче, в итоге навасянили свою систему на том же sql server со сбором данных запросами. Получилась полноценная аналитическая платформа, знающая когда где и что произошло во всех деталях. Но это стоило пяти лет труда.
а вот кстати проверка регламентов из 1с, с подключением пртг не кластеру 1с, а непосредственно к таблицам sql
ВВ
можно все что угодно, тут какой принцип)), как напишешь так и полетит))))
O
мы щас пришли к тому, что собираем данные с хостов с помощью telegraf, а все проверки и оповещения в т.ч. в телегу идут в аналитической системе собственной разработки. telegraf оказался удобен как транспортный агент.
ВВ
как в поговорке:
- Что пишешь?
- Не знаю! Напишем посмотрим
)))))
- Что пишешь?
- Не знаю! Напишем посмотрим
)))))
ВВ
мы щас пришли к тому, что собираем данные с хостов с помощью telegraf, а все проверки и оповещения в т.ч. в телегу идут в аналитической системе собственной разработки. telegraf оказался удобен как транспортный агент.
т.е. это что то связанное с метриками?
ВВ
я просто телеграф не юзал
O
т.е. это что то связанное с метриками?
это просто агент, который может выполнить какие-то действия, собрать данные, например запросом, выполнить простенькую аггрегацию и выплюнуть данные в JSON куда скажешь.
O
У нас он выполняет ряд SQL-запросов, собирает счётчики производительности, сведения о состоянии сервера. На ходу кое-какие из счётчиков нормализует и отдаёт в систему, аккумулирующую данные со всего нашего хозяйства.
O
у нас посто всё линуксовое и SQL Server тут как белая ворона. Ради него одного городить чистые виндовые инструменты не гоже, вот и взяли наоборот максимально универсальное средство, которому просто пофигу чего добывать и куда сплевывать.
ВВ
ну в принципе если только по sql, то можно же собрать данные запросом и отправить их используя shell прямо из мантей-заданий самого скуля, при чем используя агрегацию условий используя логический конструктор. У меня так некоторые базы до сих пор шлют всякое)))
ВВ
у нас посто всё линуксовое и SQL Server тут как белая ворона. Ради него одного городить чистые виндовые инструменты не гоже, вот и взяли наоборот максимально универсальное средство, которому просто пофигу чего добывать и куда сплевывать.
так он же вроде уже под линь есть