Собственно создается система логирования , требования следующие :
1. система не должна мешать работе других приложений запущенных на машине при обработке не критичных сообщений, допускается возможность сильной загрузки процессора при регистрации критичных сообщений.
2. система должна позволять регистрировать новые типы сообщений
3. система должна предоставлять удаленный просмотр журнала событий
4. система должна предоставлять возможность удаленной регистрации событий от .НЕТ клиентов , а также других приложений для системы Windows не поддерживающих данную технологию.
5. система должна иметь возможность регистрации локальных событий от .НЕТ клиентов , а также других приложений для системы Windows не поддерживающих данную технологию.
6. система должна предоставлять возможность локального и удаленного администрирования.
Основная цель — продемонстрировать возможности среды разработки и платформы и доказать начальству что можно создавать быстрее, надежнее и не намного медленные системы чем на с++ + тfc. Сейчас подобная система уже начала разрабатываться на с++.
К сожалению я не гуру в .нет, читал книжки от МС ПРЕСС но на практике — 0, поэтому в багаже пока только есть определенная вера в то что это должно действительно быть намного быстрее и надежнее...только вот в производительности пока уверенности нет.
Так вот как же я примерно представил реализацию :
п1. — создание низкоприоритетного потока в который складывать входящие сообщения ...а он уж по мере освобождения ресурсов машины будет "неспеша" их складывать в хранилище
п2. — сделать в хранилище таблицу для хранения дерева типов ( один тип может быть подтипом другого ) с соотв. параметрами
п3. — использовать .net remoting
п.4. — для .net клиентов использовать event , delegates , remoting. Для не .нет — слушающий сокет.
п.5. — собственно то же что и п.4. только для не .нет приложений использовать прием через сообщения окна windows вместо сокета
п.6. — клиент на .нет ремоутинг.
В качестве хранилища решил использовать XML , добавление новых записей — дописывание в конец файла. Возможно имеет смысл использовать MS SQL , но опять же подразумевается что система логирования может быть запущена на каждой рабочей машине независимо. Не ставить же на каждую SQL Server. Т.е. основной use-case системы — система ставится на рабочих станциях пользователей предприятия. на ней же работают приложения которые регистрируют свои события в системе. Собственно возникает вопрос — зачем нужны удаленные фичи ? — 1. администрирование системы..администратор должен иметь возможность быстро получить информацию о работе приложений 2 — возможность выноса системы логирования на отдельный защищенный сервер например для ведения аудита финансовых операций.
Прошу покритиковать мое решение , предложить фичи в vs 2005 которые могут действительно ускорить процесс разработки, а также предложить дешевые полезные фичи которые можно добавить в систему при этом не сильно ее усложнив . дабы показать мощь .нет 2.0.. буду очень признателен.
Особенно приглядываюсь к фиче vs 2005.net — application diagram — было бы здорово если на ней можно реально нарисовать скелет системы и затем достаточно быстро закрыть вопрос реализации. Если кто использовал в деле поделитесь ощущениями пожалуйста...
Re: .net fw 2.0 & vs 2005 prof в рамках системы логирования
Я уже писал систему логгирования и до этого долго работал с log4newt, так что в теме. Не твои требования актульны, некоторые решаются не за счёт написания нового кода.
Если интересно что-то пообсуждать по существу — аська в подписи, цифропочта в профиле.
Здравствуйте, BlackTigerAP, Вы писали:
BTA>XML с remote-ингом идут курить всторонку... по причине тормозов и пр.
BTA>БД: SQLExpress.
Вот это интересно, я вот еще подумывал попробовать SQLite.
BTA>Общение (любое): веб-сервисы, т.к. надо работать с недотнетовкими клиентами.
Если я правильно понимаю для веб-сервиса нужна сооветсвующая среда — а именно IIS.
Ставить на все Workstation в организации IIS + SQL Server ощущение — из пушки по воробьям.
Конечно в случае централизованного сервера это очень удобное решение..согласен. Не нужно мутить реализации с сокетами и ремоутинг.
BTA>С "новые типы сообщений" не понятно. Нужна подробная спецификация структуры "сообщения".
BTA>Подписываться на тему не собираюсь, ибо рсдновский флуд.
Почему флуд ? Обоснуй плиз..
Re[2]: .net fw 2.0 & vs 2005 prof в рамках системы логир
От:
Аноним
Дата:
14.06.06 21:56
Оценка:
Удивительно, что это еще флудом не стало, странно... Ладно, подпишусь пока на тему...
Так вот. Насчет БД. C XML поимеешь "геморроя море" ибо этот формат НИКОГДА (ДА! НИКОГДА!) не разрабатывался для хранения данных. Изначально(!) это был формат для инуверсального обмена данными между...всем. Всё, что сейчас "наворочено" — это "крылья для слона". (И фиг меня кто-то переубедит!). SQLite... Слышал не много, и ничего хорошего из того, что слышал. SQLExpress же — полноценный SQLServer с некоторыми ограничениями.
>>Если я правильно понимаю для веб-сервиса нужна сооветсвующая среда — а именно IIS.
Можно хостить WS и самим приложением (не надо мен спрашивать как, не интересовался подробно никогда). Да и с IIS-ом нет проблем никаких на самом деле. Да и чую спинным мозгом, что "установка на клиента" — это больше из "могёт быть" и является больше утопией, чем реалностью. ТАКИЕ системы не ставятся на клиента. А вот remoting — это уж "напалмом по воробьям". Он (не напалм!) самим МСом позиционируется и рекомендуется только для межпроцессорного взаимодействия в рамках ОДНОГО сервера.
>>Почему флуд ? Обоснуй плиз..
Будем, как грится, посмотреть...
Собственно если я правильно понял, у вас там даты нет.. ну т.е. вам дампы памяти хранить не придеться
Если мессага не более 16 кило весит но я бы делал так....
для больших месаг более 256 байт жмем дефлайтом ( можно жать и мелочь, но надо ли ? ) и через UDP на сервер, а что сервер и как будет делать с этим пакетом это его персональное горе.( ну к примеру там будет XML ) Можно конечно свой протоколчик навернуть сверху, но на самом деле это вам не надо. Где мессаги объеденяются в пакеты и т.д. Но смысл тотже клиент нагло в текстовом виде кидает все на UDP сервер.
З.Ы.Одно но UDP не гарантирует доставки, так что посмотрите как это реализовано скадем в VOIP для протоколов типа SIP, MGCP, SIP. Это только звучит страшно, на самом деле все очень просто
Re[3]: .net fw 2.0 & vs 2005 prof в рамках системы логир
>>>Если я правильно понимаю для веб-сервиса нужна сооветсвующая среда — а именно IIS.
BTA> А вот remoting — это уж "напалмом по воробьям". Он (не напалм!) самим МСом позиционируется и рекомендуется только для межпроцессорного взаимодействия в рамках ОДНОГО сервера.
Откуда такая информация ?
.NET remoting enables you to build widely distributed applications easily, whether application components are all on one computer or spread out across the entire world. You can build client applications that use objects in other processes on the same computer or on any other computer that is reachable over its network. You can also use .NET remoting to communicate with other application domains in the same process.
Remoting Perfomance Tuning
The main configuration setting you tune in remoting is the lease time. To determine appropriate lifetime timeouts for your application, you need to strike a balance between resource utilization on the server and the performance implications of frequently destroying and recreating objects. Increasing an object's lifetime increases your server's memory and resource utilization, whereas decreasing the lifetime can lead to objects being destroyed too frequently and prematurely.
Tuning Options The general guidelines are as follows:
-Consider using a longer lease time for objects that are expensive to create.
-Consider shorter lease times for objects that consume lots of shared or important resources.
Re[2]: .net fw 2.0 & vs 2005 prof в рамках системы логирован
Здравствуйте, GSL, Вы писали:
GSL>Здравствуйте, invert, Вы писали:
GSL>Собственно если я правильно понял, у вас там даты нет.. ну т.е. вам дампы памяти хранить не придеться
Дампы памяти необходимы для сообщений типа Critical Errors, я думаю даже больше — можно выгружать и
Call Stack, и может быть что-то еще ( пока System.Diagnostics не прочел полностью ) дабы показать преимущества разработки на дотнет, по сравнению с использованием c++ и дополнительных библиотек типа boost, MFC и прочих.
Вот еще хочу спросить , есть ли возможность подписаться на все exceptions ? Дабы не ставить в коде try catch() и при любом эксепшене чтобы событие проходило через систему логирования.
