Дано:
Аппаратно-программный комплекс: входная подсистема, сервера обработки, БД, рабочие места и пр.
Короче довольно много разнокалиберных машин, с работающим на них ПО. ОС — Windwos XP.
Вопрос:
Как можно реализовать единую систему извещения об ошибках в работе этого ПО? То есть хотелось бы чтобы в любой момент можно было видеть общую картину по комплексу (не в realtime). Все ли нормально работает, если были какие-нибудь crt, err, wrn, то где. Конечно хотелось бы еще чтобы это не влияло на производительность.
Решение, которое я вижу:
1. Ведение логов каждым из приложений (на производительность не сильно влияет в данном конкр. случае)
2. Клиентская утилитка "шерститель логов и находитель crt, err, wrn..."
3. Серверная утилитка "получатель сообщений и известитель хоть и на мыло"
Возможно это еще один велосипед? : ) Может есть готовые средства для всего этого? Может использовать журнал Windows? Вообще любые мысли по этому поводу. Как бы сделали Вы?
Re: Глобальное извещение об ошибках в программном комплексе
Здравствуйте, Super_Star, Вы писали:
S_S>Может использовать журнал Windows?
Имею негативный опыт Если это не является требование заказчика, имхо, лучше избежать. Хотя и плюсы есть — стандартный механизм просмотра, стандартный механизм чтения/записи логов с другой машины (хотя там с безопасностью траблы будут), стандартный механизм локализации. Есть, опять же, стандартные (только дорогие, вроде) системы обработки таких логов, которые интеллектуально отобразят админу текущую картину. Как-то их можно научить понимать свои сообщения. Ни разу не сталкивался, только слышал.
Но минусы — негибкий, неудобный.
S_S>Вообще любые мысли по этому поводу. Как бы сделали Вы?
Ещё мысли — можно не просто писать логи, а сделать серверок для логов. Которому все части комплекса посылают информацию о событиях. В результате упрощается анализ и настройка. Минусы — результат, возможно, будет довольно неудобно смотреть в обычном текстовом редакторе. Хотя, если специально постараться, то можно сделать и удобно.
Делай что должно, и будь что будет
Re[2]: Глобальное извещение об ошибках в программном комплек
Здравствуйте, SergH, Вы писали:
S_S>>Вообще любые мысли по этому поводу. Как бы сделали Вы?
SH>Ещё мысли — можно не просто писать логи, а сделать серверок для логов. Которому все части комплекса посылают информацию о событиях.
А если сеть пропала? ИМХО писать в файл проще в реализации. Приложение просто ведет лог, клиент просто пересылает когда может, сервер получает и извещает.
Re[3]: Глобальное извещение об ошибках в программном комплек
Здравствуйте, NoPainNoFear, Вы писали:
NPN>А если сеть пропала?
Мы делали следующее извращение:
— подсистема логирования состоит из серверов (несколько штук) и клиентов (стоят на каждом компьютере, который может быть источником события).
— приложение, генерирующее событие отдаёт его локальному клиенту
— а он — серверу (какому или каким — настраивается)
— пока нет сети, или если лог-сервер в дауне, сообщения копятся. Потом они всё-таки доставляются с пометкой out-of-time
а в конце всё это валилось в EventLog И вот тут были основные проблемы. Во-первых, не гибко оно... Во-вторых, первоначально на сервера логирования никакого софта ставить было не нужно — в лог можно без проблем писать удалённо. А потом вышел WS2003 SP1 и полезли проблемы с безопасностью, и стандартные настройки почему-то работать не захотели. Пришлось на сервера ставить маленькую программульку, которая просто получала сообщение и кидала его в локальный EventLog.
Использование распределённых EventLog-ов было требованием заказчика.
NPN>ИМХО писать в файл проще в реализации. Приложение просто ведет лог, клиент просто пересылает когда может, сервер получает и извещает.
Соглашусь.
Делай что должно, и будь что будет
Re[4]: Глобальное извещение об ошибках в программном комплек
Здравствуйте, rsn81, Вы писали:
R>Делали аналогично, по-моему, достаточно гибко.
От предложенной схемы с файлом это отличается только способом, которым лог-клиент получает сообщение. В одном случае — прямой вызов через IPC (у нас был RPC), в другом — чтение файла.
Решение с файлами лучше. Точнее, его можно сделать лучше, если договориться, где эти файлы лежат
— более четко отделены процессы, они практически не взаимодействуют.
— в случае падения/зависания лог-клиента ничего плохого не происходит. Сообщения не теряются, приложения не виснут (в напрасной попытке дождаться возврата управления из RPC)
Делай что должно, и будь что будет
Re[6]: Глобальное извещение об ошибках в программном комплек
Здравствуйте, SergH, Вы писали:
SH>От предложенной схемы с файлом это отличается только способом, которым лог-клиент получает сообщение. В одном случае — прямой вызов через IPC (у нас был RPC), в другом — чтение файла.
Точно уже не помню, кажется, вначале вообще делали через сокеты, потом перетащили на CORBA или SOAP — давно было.
SH>Решение с файлами лучше.
Спорно.
SH>Точнее, его можно сделать лучше, если договориться, где эти файлы лежат
Вот, здесь мы теряем гибкость. И потом лог-клиент тоже может быть удаленным, не знаю, насколько это сильное и востребованное преимущество, но нам тогда показалось это востребованным.
SH>- более четко отделены процессы, они практически не взаимодействуют.
Именно по этому критерию (а не указанному ниже) не вижу, чем как один из видов ресурсов TCP-порт хуже файла.
SH>- в случае падения/зависания лог-клиента ничего плохого не происходит. Сообщения не теряются, приложения не виснут (в напрасной попытке дождаться возврата управления из RPC)
Встроенная легкая БД решит проблему потери сообщений.
Про зависание согласен, это действительно минус, из-за которого пришлось кривоту ввести: приложение при ненахождении лог-клиента перестартовывало (или стартовало) его самостоятельно. Но ведь логика у лог-клиента донельзя тупая, мы тогда решили, что это малое зло: максимально упростили лог-клиент, чтобы уменьшить вероятность его зависания по возможному максимуму.
... << RSDN@Home 1.2.0 alpha rev. 679>>
Re[7]: Глобальное извещение об ошибках в программном комплек
Здравствуйте, wildwind, Вы писали:
W>Господа, не пытайтесь заново изобрести SNMP.
SNMP немного сложнее. Там и обмен двусторонний (команды) и вообще.. А отказоустойчивость (накопление сообщений при потери сети), по-моему, вообще не заложена в протокол, хотя могу и врать.
Делай что должно, и будь что будет
Re[8]: Глобальное извещение об ошибках в программном комплек
Здравствуйте, wildwind, Вы писали:
W>Господа, не пытайтесь заново изобрести SNMP. Действительно, на кой все это надо, есть ведь ICMP! Да и языки высокого уровня на кой, есть ведь ассемблер?
Re[7]: Глобальное извещение об ошибках в программном комплек
Здравствуйте, rsn81, Вы писали:
SH>>Точнее, его можно сделать лучше, если договориться, где эти файлы лежат R>Вот, здесь мы теряем гибкость.
— Согласен. Но, а так нам нужно договориться о лог-клиенте
— зато приобретаем бонус — файлы простого формата может читать и разбирать кто угодно. Для этого не нужно как-то специально "интегрироваться" в приложение и т.п.
R>И потом лог-клиент тоже может быть удаленным, не знаю, насколько это сильное и востребованное преимущество, но нам тогда показалось это востребованным.
Не имеет смысла делать его удалённым, если именно в нём реализована логика накопления сообщений при обрыве сети
R>Именно по этому критерию (а не указанному ниже) не вижу, чем как один из видов ресурсов TCP-порт хуже файла.
Файлы сами себя хранят на диске и доступны для многоразового прочтения. А так нужно хранить очередь не отправленных сообщений, желательно — на диске, чтобы не зависеть от сбоев ОС...
R>Встроенная легкая БД решит проблему потери сообщений.
Ну, пожалуй. А почему бы тогда просто не файл? Не, я не спорю, что есть свои преимущества у такой модели. Централизация часто упрощает всякий анализ и т.п.
R>Про зависание согласен, это действительно минус, из-за которого пришлось кривоту ввести: приложение при ненахождении лог-клиента перестартовывало (или стартовало) его самостоятельно. Но ведь логика у лог-клиента донельзя тупая, мы тогда решили, что это малое зло: максимально упростили лог-клиент, чтобы уменьшить вероятность его зависания по возможному максимуму.
Может повиснуть удалённый сервер
Делай что должно, и будь что будет
Re[7]: Глобальное извещение об ошибках в программном комплек
Здравствуйте, SergH, Вы писали:
SH>- Согласен. Но, а так нам нужно договориться о лог-клиенте SH>- зато приобретаем бонус — файлы простого формата может читать и разбирать кто угодно. Для этого не нужно как-то специально "интегрироваться" в приложение и т.п.
Минимальная интеграция в программный комплекс (соблюдение некоторых правил — интерфейса) как необходимое условие доступа к протоколам работы системы — плохо? Очень спорно. К примеру, по мне так "может читать и разбирать кто угодно" — больше минус, чем плюс.
SH>Не имеет смысла делать его удалённым, если именно в нём реализована логика накопления сообщений при обрыве сети
У нас были более честолюбивые замыслы.
Идея в том, чтобы лог-клиент и лог-сервер можно было комбинировать, в первом приближении, к примеру, чтобы логгер при необходимости (соответствующей настройке) мог быть одновременно и клиентом, и сервером, т.о. накопление сообщений идет в каждом таком логгере, а если в настройках указан родительский логгер, то идет передача данных туда. Т.о. можно создать иерархическую сеть сбора сообщений, каждый уровень которой видит только свои и сообщения подчиненных уровней, а при необходимости передает все информацию выше.
Re[8]: Глобальное извещение об ошибках в программном комплек
Здравствуйте, Super_Star, Вы писали:
S_S>А как на счет производительности? Не дешевле ли писать в файл?
Производительность чего? То есть какую критическую ко времени выполнения операцию может замедлить БД и спасти обычный файл?
Re[9]: Глобальное извещение об ошибках в программном комплек
Здравствуйте, rsn81, Вы писали:
R>Минимальная интеграция в программный комплекс (соблюдение некоторых правил — интерфейса) как необходимое условие доступа к протоколам работы системы — плохо? Очень спорно.
Ну, нужно не только интерфейс соблюсти, нужно ещё чтобы именно тебя вызвали. А если хочется, чтобы несколько разных систем логи обрабатывали? Нам вот хотелось Мы сделали c плагинами Криииво было
SH>>Не имеет смысла делать его удалённым, если именно в нём реализована логика накопления сообщений при обрыве сети R>У нас были более честолюбивые замыслы.
Это не про то немного, я имел ввиду, что сообщения должны копиться локально, потому что если сеть порвётся на отрезке до удалённого лог-клиента, всё будет потеряно.
R>Идея в том, чтобы лог-клиент и лог-сервер можно было комбинировать, в первом приближении, к примеру, чтобы логгер при необходимости (соответствующей настройке) мог быть одновременно и клиентом, и сервером, т.о. накопление сообщений идет в каждом таком логгере, а если в настройках указан родительский логгер, то идет передача данных туда. Т.о. можно создать иерархическую сеть сбора сообщений, каждый уровень которой видит только свои и сообщения подчиненных уровней, а при необходимости передает все информацию выше.
Круто. Только тут лучше общее описывать — не иерархия (дерево) а граф. Если ещё можно настраивать правила, и вообще всё сделано грамоно, то такую систему уже саму по себе можно продавать.
Делай что должно, и будь что будет
Re[9]: Глобальное извещение об ошибках в программном комплек
Здравствуйте, rsn81, Вы писали:
S_S>>А как на счет производительности? Не дешевле ли писать в файл? R>Производительность чего? То есть какую критическую ко времени выполнения операцию может замедлить БД и спасти обычный файл?
WriteToLog()
Re[10]: Глобальное извещение об ошибках в программном компле
Здравствуйте, rsn81, Вы писали:
R>Здравствуйте, Super_Star, Вы писали:
S_S>>WriteToLog() R>А если отправка сообщения логгеру асинхронная?
Нет, ну можно что угодно сделать, просто это же еще делать надо : ) В первом прибижении я могу допустить некоторы затраты на отправку сообщений ради быстроты реализации. Потому и спросил может ли работа с легкой БД оказаться менее ресурсоемкой чем простая запись в файл.
Re[12]: Глобальное извещение об ошибках в программном компле
Здравствуйте, NoPainNoFear, Вы писали:
S_S>>>WriteToLog() R>>А если отправка сообщения логгеру асинхронная? NPN>Нет, ну можно что угодно сделать, просто это же еще делать надо : ) В первом прибижении я могу допустить некоторы затраты на отправку сообщений ради быстроты реализации. Потому и спросил может ли работа с легкой БД оказаться менее ресурсоемкой чем простая запись в файл.
Здравствуйте, SergH, Вы писали:
SH>Это не про то немного, я имел ввиду, что сообщения должны копиться локально, потому что если сеть порвётся на отрезке до удалённого лог-клиента, всё будет потеряно.
Ага, если критично, запускать локально.
SH>Круто. Только тут лучше общее описывать — не иерархия (дерево) а граф. Если ещё можно настраивать правила, и вообще всё сделано грамоно, то такую систему уже саму по себе можно продавать.
Есть у меня такое подозрение, что все это уже реализовано.
Начал изучать сейчас бесплатную ESB (Enterprise Service Bus) — Mule. Частично, подобное "осел" позволяет сделать, правда, несколько сложно.
Если это не является требование заказчика, имхо, лучше избежать. Хотя и плюсы есть — стандартный механизм просмотра, стандартный механизм чтения/записи логов с другой машины (хотя там с безопасностью траблы будут), стандартный механизм локализации. Есть, опять же, стандартные (только дорогие, вроде) системы обработки таких логов, которые интеллектуально отобразят админу текущую картину. Как-то их можно научить понимать свои сообщения. Ни разу не сталкивался, только слышал.
