BiTel

Всем привет.

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

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

параллельном выполнении двух заданий шлюза не всегда в логе будет верным последний статус.

хм.. а как часто у вас это происходит ? и какие задания выполняются параллельно ? оба - это задача проверки шлюзов IPN ?

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

а чем вас спасет предыдущий статус ? ..он так же будет неправильным

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

А если скрипт отработал , но связи не было . Но статус изменился . Обычно сркипт сам должен делать проверку на оборудовании - менять или не менять . Обычно он считывает статус всех абоннато на шлюзе однйо командой ( show access_list ) и потом уже шлет команды только если нужно .

Надо делать по другому , в случае удачной отработки шлюза , нудно ставить флаг , что все нормально . В случае смены статуса IPN, флаг сбрасывать . Так же сбрасывать флаг если поменялся ip, тип правила и или какая-то другая информация влияющая на шлюз . При этом нужно учитывать обратную свзязь как-то. Т.е если шлюз удавленный перезагрузился и сбросил все правила , то нужно это как-то отлавливать( по snmp или периодически пинговать, проверять uptime ). И это еще сделать как-то универсально.. Теоретически это уже сейчас можно реализовать с помощью скриптового шлюза . Кажется один из наших клиентов так и сделал себе сам , пишет в некторую таблицу флаг. Uptime можно так же сохранять в таблицу

Подробнее можете пояснить. Для какого типа шлюза это актуально ?

У нас шлюз сделан на Java.
Логика - перебираются все statusList и отправляется на оборудование соответствующая команда.
Не всегда реально по snmp запросить состояние.
Поэтому чтобы лишних команд не слать на оборудование, появилось предложение писать прошлый статус для шлюза.

Для шлюзов работающих по telnet/ssh. Потоу вы уже перебираете статусы и шлете команды толк в ом случае , если что-то не так . В случае snmp так не получится скорее всего