Zabbix мониторинг лог файла и много "динамичес&

[NvAriec]

Здравствуйте.
Есть лог файл, в который пишется лог с контроллера, который опрашивает датчики.
Формат лога1 такой:

2014-11-11 12:03:00:543 Plc Transport.Plc2Var2 Bit set: 1611
2014-11-11 12:13:00:543 Plc Transport.Plc2Var2 Bit cleared: 1611

и т.д.
Имя датчика: Transport.Plc2Var2, значение которое он передал - 1611. Это соответствует какой-то ошибке.

Формат лога2 такой:
15:50:16.345-06.02.2015 | D | received (0) : 6682 10 01 TSTA 2204 0
15:50:16.345-06.02.2015 | D | received (0) : 6682 10 01 TSTA 2204 1

2204 - адрес, 0 или 1 - значение. 0 - норм, 1 - ошибка.
Какое есть желание:
не руками создавать триггеры, а как-нибудь автоматически.
Например: парсится лог1, возникает новое значение из раздела set, и создаётся триггер со значением "На 2204 что-то пошло не так - значение 0", при значении 1, триггер переходит в состояние ОК.
По такому же принципу создаются и триггеры по второму логу.

А потом уже понимаем - какие триггеры нам не нужны - отключаем, нужные - переименовываем. Так как ВСЕ значения просто не реально проставить. Их в районе 2000 вариантов. Система сейчас запускается только. поэтому есть возможность обкатать и набить базу этих значений.
К тому же из этих 2000 ВСЕ сообщения могут и не попасть вообще в базу.

Поможет кто-нибудь или может предложит другой путь решения?

[NvAriec]

Не будет помощи?)

[rough-84]

.Какое есть желание:
не руками создавать триггеры, а как-нибудь автоматически.

На сколько мне известно zabbix такого не умеет. Есть прототипы триггеров, но там другая суть, там 1 триггер на множество устройств и одно событие. Не понятно как вы собираетесь связать 1 лог с другим. Вы хотите чтобы триггер сработал на слово set(лог1) и при этом данные были из лога 2.
Возможно если бы мне была поставлена такая задача я бы извратился и cделал что то типа того:
1. Парсил бы оба лога.
2. Создал триггер который бы срабатывал при наличии в новых данных в первом логе слова "set:"
Триггер провесит ровно до следующих полученных данных и соответсвенно отправит уведомление.
3. В отправку уведомления я бы включил последние полученные данные из обоих логов.
В будущем, в данный триггер я бы добавлял условия при которых он не должен сработать на слово "Set:".
Всё это прекрасно работало бы если данные ошибки в логах появляются не часто, то есть нет по туче строк с ошибками за каждую новую проверку данных.

[NvAriec]

НЕнене. Связывать их никак не надо. Это два отдельных лога.

Упрощу задачу. А то перечитал сам и понял что ошибься видимо.

Есть файл в который валятся логи. Ошибочные или не ошибочные. Ошибочный сопровождается определённой строкой с адресом датчика.

Вот хотелось бы, чтобы этот адрес датчика попадал в триггер.
То есть парсилась строк, по регулярному выражению доставался адрес устройства на котором ошибка и возникал триггер. Опреатор смотрел - важный он или нет. Если не важный - деактивировал его. Если важный - оставлял и правил под нужные требования.

Сложность создать триггер в большом количестве возможных ошибок. И забивать их все - не вариант. Они могут и вообще никогда не возникать на нашей системе.

[rough-84]

Довольно сложно помочь, если вы стоите на своем:

Вот хотелось бы, чтобы этот адрес датчика попадал в триггер.
То есть парсилась строк, по регулярному выражению доставался адрес устройства на котором ошибка и возникал триггер.

Zabbix не создаёт сам тригеры из ничего.

Вот вам ещё 1 решение:
Парсите лог через regexp по условию и достаёте из лога адрес.
Создаете 1 триггер в котором указываете:
Сработать, если последние полученные данные не равны nodata, то есть если в данных что то пришло.
Настраиваете отправку уведомлений по данному триггеру.
В уведомлении указывать последние данные триггера.

Единственное что вы не узнаете исправилась ли ошибка, т.к я не представляю как настроить триггер, чтобы он висел до тех пор пока не придёт строка с починкой. Как вариант сделать дополнительный триггер, на починку

[yukra]

Вы хотите чего то странного. Во первых на сколько я вижу парсинг логов хоть и есть в заббиксе, но это явно не его конек. Во вторых: Почему 0 это проблема, а 1 это хорошо, или почему 1 это проблема, а ноль это хорошо? нет, вы правда хотите что бы мониторинг сам решал что хорошо, а что плохо? Кого винить будете если в логе проскочит "не то" значение, а заметят через месяц что "очень важная штука висит в статусе 2, и при этом написанно что это ок, хотя это ПАНИКАААА!!!!"?

Заббикс имеет ldd, на основании их можно делать поиск, ну нужно понимать что вы ищите и по каким параметрам. Вообще если это ваша система, то я бы советовал прикручивать SNMP, а не в логи все писать. Все таки логи они больше для "разобраться что это было" а SNMP для наблюдения и управления.

[NvAriec]

Вы хотите чего то странного. Во первых на сколько я вижу парсинг логов хоть и есть в заббиксе, но это явно не его конек. Во вторых: Почему 0 это проблема, а 1 это хорошо, или почему 1 это проблема, а ноль это хорошо? нет, вы правда хотите что бы мониторинг сам решал что хорошо, а что плохо? Кого винить будете если в логе проскочит "не то" значение, а заметят через месяц что "очень важная штука висит в статусе 2, и при этом написанно что это ок, хотя это ПАНИКАААА!!!!"?

Заббикс имеет ldd, на основании их можно делать поиск, ну нужно понимать что вы ищите и по каким параметрам. Вообще если это ваша система, то я бы советовал прикручивать SNMP, а не в логи все писать. Все таки логи они больше для "разобраться что это было" а SNMP для наблюдения и управления.

Если бы была система моя, я бы вопросы не задавал, а встроил SNMP без раздумий(

Дело в том, что это система на производстве. Система Немецкая и Голландская. НИ о каких SNMP там речи не идёт. Это конвеер на базе сименсовских контроллеров и PLC контроллера, который конвертирует сигналы с датчиков и контроллеров в цифровой формат, обрабатывает их и пишет в лог в онлайн режиме данные. Каждый час лог испытывает ротацию.
За секунду в лог падает порядка 100 сообщений. С ошибками, без ошибок, wathcdog сообщения и куча мусора. Но есть определённые сообщения-телеграммы в вышеописанном формате. nodata тут не катит( Данные есть постоянно.

Почему 0 это хорошо, а 1, 2, 3 - ошибка? Потому что так указано в документации. Для определённых телеграмм 0 означает, что всё гуд, конвеер работает. 1 - конвеер выключен, 2 - ошибка, 3 - вышел из строя (предположу что какая-то механическая часть).

Документация на всё это дело есть, но в ней овердохрена сообщений. Забить их все очень гемморойно (но наверное так и придётся делать).

Так что мониторинг лог файла в данном варианте это как раз та единственная вещь, с помощью которой можно отмониторить какие-либо ошибки и неполадки.

[gescheit]

Я бы написал приложение которое постоянно парсит файл и хранит и выдает информацию от данных с датчиков по snmp. Пришла инфа о новом датчике - появилась новая запись в snmp. Дальше lld находит все датчики, создает проверки и триггеры.

[Huko]

Как вариант для второго случая
15:50:16.345-06.02.2015 | D | received (0) : 6682 10 01 TSTA 2204 0

log[/var/log/file.log,TSTA (\d+) (\d),,,,\1 \2]

на выходе такого item'a будет - 2204 0, дальше уже начинаете с триггерами разбираться..