Какъв е чистият начин за получаване на унифицирано регистриране?

Ето го проблемът с регистрирането.

Има уебсайт asp.net. Основната характеристика на уебсайта е списък с имейли (запазени в db). Всеки път, когато има грешка, данните се записват от nlog във файл. Сайтът разполага с админ панел. Списъците на административния панел четат регистъра за грешки на уебсайта.

Има работник. Работникът се свързва с Exchange Server и проверява за имейли със съвпадаща тема. Имейлите, които съответстват на шаблон, се записват в базата данни. Всеки път, когато има грешка, данните се записват от nlog в различен файл.

И уебсайтът, и работникът използват един и същ клас регистратор. Настройките в web.config на уебсайта и application.config на работника просто сочат към различен целеви файл.

Ето я новата функция. Административният панел трябва да изброява и грешките на работника. Сега имам няколко начина да направя това.

Вариант 1: Уебсайтът ще разбере къде е работният регистрационен файл, след което ще го прочете.

Вариант 2: Направете нов работник/партия. Това ще обработва регистриране както за уебсайта, така и за работника. Той може да запише и двата набора от грешки в един дневник или може би дори нова таблица в базата данни.

Опция 3: Конфигурирайте както уебсайта, така и работния файл, за да сочат към един и същ целеви файл, въпреки че не знам структурата на директорията на файловата система Azure.

Какъв би бил най-чистият начин да го направите?


person user513788    schedule 24.09.2013    source източник


Отговори (2)


Това, което можете да направите, е да използвате функционалността на персонализирани журнали на Windows Azure Diagnostics. Накарайте вашата уеб роля и работна роля да пишат до различни или едни и същи цели с помощта на NLog. Тези файлове ще бъдат записани в локалното хранилище на всяка виртуална машина. След това с помощта на Windows Azure Diagnostics прехвърляте тези файлове периодично в Windows Azure Blob хранилище и имате трета работна роля, която периодично обработва тези петна.

Разгледайте Cloud Service Fundamentals проект тук: http://code.msdn.microsoft.com/windowsazure/Cloud-Service-Fundamentals-4ca72649. Това е от екипа на Windows Azure CAT. Той използва NLog за събиране на регистрационни данни и след това запазване на тези регистрирани данни в контейнер, наречен телеметрични регистрационни файлове. След като данните са в този контейнер, той периодично проверява данните и ги изпраща в база данни на SQL Azure.

person Gaurav Mantri    schedule 24.09.2013
comment
Имаме ограничен бюджет. Това ще доведе ли до допълнителни такси? - person user513788; 24.09.2013
comment
Ще има такси за прехвърляне на тези данни в blob хранилище и такси за съхранение, но те ще бъдат незначителни. Друга такса ще бъде за тази трета работна роля за обработка на данните в регистрационния файл, но можете да изпълните тази задача с работната роля, която вече имате във вашето решение. - person Gaurav Mantri; 25.09.2013

Изпратете nlog записи към база данни вместо локален файл.
https://github.com/nlog/NLog/wiki/Database-target
Ако имате твърде много записи, просто изпратете FATAL или ERROR към базата данни.

person Fabrizio Accatino    schedule 24.09.2013
comment
Да, но какво се случва, ако има преходен проблем с връзката между NLog и базата данни, което е проблем, който открих, но не успях да го реша ... stackoverflow.com/questions/37588791/ - person SteveC; 02.08.2016