Мониторинг регенераторов SM-xx

[san]

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

Что нужно от регенераторов:

1. Собственно мониторинг. Периодическое обновление информации о состоянии участков линейного тракта, накопление статистики и т.д..
2. Детализация аварии на линейном тракте. Допустим тракт состоит из N участков (N-1 регенераторов) и в момент аварии пользователи хотят получить детализированное сообщение в программе мониторинга и логах, на каком участке и на какой паре произошла авария.

Сложности текущего варианта:

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

3. Неизвестна актуальность данных, считывая переменные из таблицы программа мониторинга не знает свежие это данные или опрос был год назад

4. Конфликты с совместным доступом, это следствие из п. 1-3, если два пользователя независимо друг от друга будут проводить опрос и считывать таблицу, они могут мешать друг-другу.

Суть конфликтов:

• проблема с SM-01
• другой пользователь запрос

Предлагается:

1. Плата SW-01 сама периодически отправляет команды опроса платам SM-xx и кэширует таблицы регенераторов для мониторинга и отображения в веб-интерфейсе.

2. При возникновении аварии линейного тракта производится немедленный опрос регенераторов для детализации аварии.

с. Пользователь, при необходимости, может через веб-морду нажать кнопку опрос не дожидаясь автоматического обновления таблицы.

Вопросы:

• Критерии конца опроса (таймаут, кол-во регенераторов,...)
• Опрос по разным парам. Для простоты ограничиться опросом по паре А?
• Проблема с отказом EOC канала на платах SM-01, суть: EOC канал может перейти в нерабочее состояние при некоторых условиях(одновременное попадание ЕОС пакетов с разных сторон в регенератор). Подробности у Влада.

[alx]

Replying to san:

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

Это ИМХО немного не по адресу - для исполнения этого желания плата SM-01 должна прислать плате SW-01 соответствующий TRAP. Следовательно, и реализовано это задача для платы SM-01, а не SW-01. В SW-01 все давно реализовано - при получении TRAP'а она аварию и в лог запишет, и в базу данных, и на экране отобразит...

[san]

немного не по адресу

Честно говоря, этот тикет весь не по адресу. Правильно было бы если плата SM сама опрашивала регенераторы и решала описанные выше задачи. Но она не умеет, и с почти 100% вероятностью и не будет уметь.

Если есть возможности решить эти вопросы не трогая плату SM, я бы хотел их использовать.

[alx]

Replying to san:

точного признака окончания опроса нет, есть некоторые критерии, но мы их сами ещё не можем до конца сформулировать

??? Ранее в устной беседе мы пришли к тому, что критерием окончания опроса является:

1. увидели в списке регенераторов плату SM-01 или SM-02 (она отличается от регенератора по типу, который читается из какой-то переменной);
2. таймаут, если плат SM-01/SM-02 в списке нет.

я думаю что перекладывать задачу определения конца опроса не правильно.

? Эту мысль я не понял. Перекладывать куда?

В любом случае это дополнительная сложность

Я бы не назвал это сложностью. :) Так, небольшое неудобство...

3. Неизвестна актуальность данных, считывая переменные из таблицы программа мониторинга не знает свежие это данные или опрос был год назад

Это не так. Если известно, что опрос выполняется не реже чем раз в N секунд, и известно, что опрос выполняется не более чем M секунд, то данные не могут быть старее (N + M) секунд. Разве нет?

Предлагается:

1. Плата SW-01 сама периодически отправляет команды опроса платам SM-xx и кэширует таблицы регенераторов для мониторинга и отображения в веб-интерфейсе.

ИМХО так делать нельзя в силу сложности номер 4. Ибо получится, что две платы, находящиеся на разных концах линии (а то и больше, если линии с ответвлениями), одновременно инициируют опрос. Главная сложность как раз и состоит в том, что новый опрос нельзя инициировать до тех пор, пока не закончился предыдущий. Следовательно, инициировать его можно только из одной точки (логично, если это будет тот же хост, на котором работает мониторинг).

2. При возникновении аварии линейного тракта производится немедленный опрос регенераторов для детализации аварии.

Опять-таки этого делать нельзя исходя из сложности 4. Надо дождаться окончания текущего опроса, и только тогда инициировать новый.

с. Пользователь, при необходимости, может через веб-морду нажать кнопку опрос не дожидаясь автоматического обновления таблицы.

Опять-таки этого делать нельзя исходя из сложности 4.

[alx]

Replying to san:

с почти 100% вероятностью и не будет уметь.

Почему?

Если есть возможности решить эти вопросы не трогая плату SM, я бы хотел их использовать.

Вот есть у нас две платы - SM-01 и SW-01. При полном консенсусе, что аварии должна выдавать именно SM-01 ты предлагаешь вместо того чтобы реализовать в ней этот недостающий на данный момент функционал имитировать его наличие (генерируя "синтетические" TRAP'ы и имитируя их получение) другой платой? Зачем такие извращения? Не лучше ли и не проще ли сразу сделать по-уму?

[andrei]

Replying to san:

с. Пользователь, при необходимости, может через веб-морду нажать кнопку опрос не дожидаясь автоматического обновления таблицы.

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

[alx]

Replying to andrei:

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

Данные на веб-странице и так постоянно обновляются (раз в секунду), без всякого нажатия. А вот нажимать кнопку "Опрос" в то время как опрос уже инициирован, нельзя. Можно игнорировать новые команды опроса до завершения текущего платой SW-01, но это возможно только при условии, что текущий опрос инициирован именно с той же платы SW-01, которая открыта браузером. Проблема в том, что браузером может быть открыта одна плата SW-01, а опрос инициирован совсем с другого блока, на другом конце линии. Тогда та плата, которая получит запрос пользователя, ничего не будет знать о том опросе, который уже инициирован. Как решить эту проблему, я не знаю.

[alx]

Replying to alx:

Как решить эту проблему, я не знаю.

Мне наиболее безопасным кажется такой вариант: вообще запретить "ручной" опрос регенераторов, убрать эту кнопку из веб-интерфейса. Опрос инициировать только автоматически, из одной точки сети. Если надо посмотреть состояние регенераторов - оператор подождет (N + M) секунд, о которых говорилось выше, как-нибудь не помрет он от нетерпения, я думаю... :)

[san]

критерием окончания опроса является: увидели в списке регенераторов плату SM-01 или SM-02 (она отличается от регенератора по типу, который читается из какой-то переменной);

да... но есть некоторые(редкие) случаи когда тракт заканчивается не платой SM, а устройством из прошлых линеек, и я не уверен что во всех из них есть признаки отличающие их от регенераторов, нужно уточнять

я думаю что перекладывать задачу определения конца опроса не правильно.

? Эту мысль я не понял. Перекладывать куда?

на пользователя (пропустил слово)

Если известно, что опрос выполняется не реже чем раз в N секунд, и известно, что опрос выполняется не более чем M секунд, то данные не могут быть старее (N + M) секунд. Разве нет?

Это в том случае если программа мониторинга контролирует отправку опроса. А если опрос производится "третьей стороной" то программа мониторинга может не знать о времени опроса и кроме того есть ещё вариант "команда не прошла". Ну как минимум нужно учитывать это при настройке мониторинга, что создаёт дополнительные "небольшие неудобства" :)

нельзя исходя из сложности 4. Надо дождаться окончания текущего опроса, и только тогда инициировать новый.

Если таблица будет закэширована(не будет очищаться), то конфилкт будет только в "перебивании" опроса до его завершения. Для такого случая можно ввести понятие приоритетного опроса, который может быть отправлен до окончания не приоритетного.

Как быть с ручным опросом, я пока не знаю, пока я склоняюсь к мысли оставить его без ограничений(конфликтный). Я надеюсь что с появлением НОРМАЛЬНОГО опроса, ручным будут пользоваться в очень редких случаях.

не помрет он от нетерпения

Ещё как помрёт. Представь у тебя УАЗик с бригадой ждёт, а ты ждёшь пока опросится 10-й регенератор, когда тебе нужна инфа по второму.
Нужно бывает в некоторых случаях "именно сейчас" провести опрос, я бы эту возможность не стал убирать.

[alx]

Replying to san:

да... но есть некоторые(редкие) случаи когда тракт заканчивается не платой SM,

Обрати внимание, что приведенный мной критерий состоял из двух частей - a и b. Если линия кончается платой SM-0x, то работает условие a. Если нет - работает условие b.

на пользователя (пропустил слово)

С этой мыслью согласен.

Если известно, что опрос выполняется не реже чем раз в N секунд, и известно, что опрос выполняется не более чем M секунд, то данные не могут быть старее (N + M) секунд. Разве нет?

Это в том случае если программа мониторинга контролирует отправку опроса. А если опрос производится "третьей стороной"

Какая разница, как называется программа, отправляющая команду "Опрос"? Будь это программа мониторинга, или cron - все равно ведь указание о том, куда и с какой периодичностью отправлять эту команду, дает человек (назовем его оператором). Следовательно, он знает, с каким периодом производится опрос. Случай безумного оператора мы, я думаю, рассматривать не будем. :)

то программа мониторинга может не знать о времени опроса

А зачем программе мониторинга это знать? ИМХО ей этого знать не надо. Ее дело - получать данные регенераторов.

и кроме того есть ещё вариант "команда не прошла".

Не понял... Почему не прошла? Связь с аппаратурой пропала? Но если с аппаратурой нет связи, то и система мониторинга не сможет получить параметры регенераторов! А если она их не может получить, то какая разница, опрашиваются регенераторы или нет? Появится связь с оборудованием - возобновится и опрос регенераторов, и система мониторинга возобновит получение данных...

Ну как минимум нужно учитывать это при настройке мониторинга, что создаёт дополнительные "небольшие неудобства" :)

Не понял... Как и зачем это надо учитывать, и какие такие неудобства создает учет? :)

нельзя исходя из сложности 4. Надо дождаться окончания текущего опроса, и только тогда инициировать новый.

Если таблица будет закэширована(не будет очищаться), то конфилкт будет только в "перебивании" опроса до его завершения. Для такого случая можно ввести понятие приоритетного опроса, который может быть отправлен до окончания не приоритетного.

Очень интересно... Раскрой, пожалуйста, свою мысль. Что это за приоритетный опрос, и почему его, в отличие от неприоритетного, можно выполнять, не дожидаясь завершения уже выполняющегося опроса? Может это решит все наши "опросные" проблемы?

Ещё как помрёт. Представь у тебя УАЗик с бригадой ждёт, а ты ждёшь пока опросится 10-й регенератор, когда тебе нужна инфа по второму.

Не понял, что ты имел в виду, упоминая 10-й и 2-й. Но общий смысл я понял. В свою очередь, предлагаю тебе представить ту же ситуацию, когда ты нажимаешь "Опросить" чтобы получить состояние 2-го регенератора, так как не хочешь подождать лишние 30 секунд, в результате все опросы "ломаются" из-за конфликта, и тебе с бригадой вместо того чтобы ехать домой придется ехать чинить ставший недоступным регенератор...

[alx]

Случайно убрал изменение. Возвращаю.

[san]

опросы "ломаются"

Если это про проблему с EOC в SM-01, то да.
Стоит учесть, что вероятность появления такой проблемы достаточно низкая (Влад ты где?), и "ручным опросом" создать её практически невозможно(мне неизвестны случаи отказа EOC в аппаратуре 3U). Отчасти (или даже в основном) поэтому плата SM и не имеет авто-опроса, так автор "решил" проблему c EOC

[san]

Зачем такие извращения? Не лучше ли и не проще ли сразу сделать по-уму?

Я попробую ещё раз поднять этот вопрос на "верхнем" уровне, но надежд на плату SM у меня почти не осталось :).

[alx]

Replying to san:

опросы "ломаются"

Если это про проблему с EOC в SM-01, то да.

Что такое ЕОС?

Стоит учесть, что вероятность появления такой проблемы достаточно низкая (Влад ты где?), и "ручным опросом" создать её практически невозможно

Логика подсказывает, что плата SM-0X, получив команду опроса, не знает, и не может знать, "вручную" посылка этой команды была инициирована или автоматически. Следовательно, если возможно сломать мониторинг автоматической отправкой команды, то можно сломать и вручную.

(мне неизвестны случаи отказа EOC в аппаратуре 3U).

Может они тебе неизвестны, потому что так (отправка команды опроса вручную на фоне периодических автоматических опросов) просто никто никогда не делает? Я предполагаю, что в руководстве по эксплуатации этот момент (о необходимости посылки команды для обновления данных) либо вообще не освещен, либо освещен плохо, без заострения на нем внимания. В результате в практике эксплуатации, на которую ты ссылаешься, мониторят регенераторы без их реального опроса, по незнанию видя устаревшие данные, как долгое время не знал я, что, мониторя SM-01 в "Демо доступе", получал состояние регенераторов двухмесячной давности... :) :) :)

Отчасти (или даже в основном) поэтому плата SM и не имеет авто-опроса, так автор "решил" проблему c EOC

Вот именно что "решил". :) Проблема: при мониторинге аппаратура может взорваться. Решение: записать в РЭ: "Запрещается мониторить аппаратуру!". :) :) :)

[san]

...

А зачем программе мониторинга это знать? ИМХО ей этого знать не надо. Ее дело - получать данные регенераторов.

Согласен, убираю п.3 из "сложностей".

По критериям окончания опроса: бывают ещё всякие "ведроиды"(регенераторы c выделением предыдущих линеек), переприём мониторинга через RS-232 и может ещё какие-то рудименты и что они там выдают в переменные я не знаю, нужно уточнять, возможно всё это стоит внести в "не поддерживаемое", но я пока не готов окончательно это решить.

Что такое ЕОС?

Служебный канал внутри DSL через который опрашиваются регенераторы и удаленный конец (Embedded Operations Channel кажется)

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

Не совсем так. Практически все пользователи знают что состояние таблицы обновляется только после команды опрос, т.к. параметры DSL тракта одни из важнейших при запуске аппаратуры в работу. Но в большинстве случаев регенераторы никто НЕ МОНИТОРИТ(потому что не понятно как а если и понятно, то неудобно/сложно), но их ОПРАШИВАЮТ вручную через веб-морду по факту происшествия, или при необходимости получить данные для статистики. Так вот в результате ручного опроса пока никто не пострадал :) не смотря на то что жмут кнопку не дождавшись конца опроса

[san]

если возможно сломать мониторинг автоматической отправкой команды, то можно сломать и вручную

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

[alx]

Replying to san:

Что такое ЕОС?

Служебный канал внутри DSL через который опрашиваются регенераторы

Тогда да, это я про проблему с ЕОС.

Не совсем так. Практически все пользователи знают ... Но ... регенераторы никто НЕ МОНИТОРИТ

Ну так это то же самое. Это не тот случай, который мы рассматриваем, поэтому и ссылаться на практику нельзя. Мы ведь рассматриваем случай, когда опросы регенераторов все время производятся благодаря периодическим автоматически отправляемым командам "Опрос", и на фоне этого оператор дает "вручную" внеочередную команду опроса...