Предпочтительный способ входа в систему .Net развернут в Azure

Question

Не могли бы вы сказать , что - самый оптимальный способ ведения простого традиционного ведения журнала в развернутом приложении Azure?

Если вам кажется, что для работы с файлами и т. Д. Требуется много работы...

Что сработало для вас лучше всего?

Answer 1

Мы используем встроенную диагностику, которая записывает данные в хранилище таблиц Azure. Каждый раз, когда нам нужно записать сообщение в журнал, это просто «Trace.WriteLine (...)».

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

http://msdn.microsoft.com/en-us/library/gg433048.aspx

Надеюсь, это поможет!

[Обновить]

public void GetLogs() {
        int cnt = 0;
        bool foundRows = false;
        var entities = context.LogTable;
        while (1 == 1) {
            foreach (var en in entities) {
                processLogRow(en);
                context.DeleteObject(en);
                cnt++;
                try {
                    if (cnt % 100 == 0) {
                        foundRows = true;
                        context.SaveChanges(SaveChangesOptions.Batch);
                    }
                } catch (Exception ex) {
                    Console.WriteLine("Exception deleting batch. {0}", ex.Message);
                }
            }
            if (!foundRows)
                break;
            else {
                context.SaveChanges(SaveChangesOptions.Batch);
            }
            foundRows = false;
        }
        Console.WriteLine("Done! Total Deleted: {0}", cnt);
    }

Answer 2

Добавим немного к ответу Brosto: для настройки диагностики Azure требуется всего несколько строк кода.Вы сами решаете, какой уровень вы хотите захватить (подробный, информационный и т. Д.).и как часто вы хотите отправлять локально кэшированные сообщения журнала в хранилище Azure (обычно я использую интервалы примерно в 15 минут).Сообщения журнала от всех ваших экземпляров затем объединяются в одну и ту же таблицу, легко запрашиваемую (или загружаемую) со свойствами, определяющими роль и экземпляр.

Существуют дополнительные операторы трассировки, такие как Trace.TraceError (), Trace.TraceWarning () и т. Д.

Вы даже можете создать прослушиватель трассировки и наблюдать за выводом вашего журнала практически в реальном времени на локальном компьютере.В архиве Azure AppFabric SDK Samples содержится образец (в папке \ ServiceBus \ Scenarios \ CloudTrace) для этого.

Answer 3

Для регистрации ошибок лучшее решение, которое я видел, это Elmah .Требуется база данных SQL, но это инструмент регистрации ошибок, который на самом деле помогает диагностировать проблемы.На Azure работает нормально.

Answer 4

Для всех своих сайтов Azure я использую настраиваемую регистрацию в таблицах Azure. Хотя немного больше работы, я считаю, что это дает мне больше контроля над информацией, которая хранится. Как прокомментировал Brosto выше, лучше всего иметь локальный процесс, который периодически загружает журналы в вашу локальную систему. Если вы извлекаете класс из TableServiceEntity, вы можете определить структуру, содержащую все поля, которые вы хотите регистрировать, и использовать тот же класс для извлечения данных в вашем локальном приложении, которое извлекает журналы. Я поддерживаю некоторые примеры кода, чтобы сделать это на моем протоколировании, используя страницу хранения таблиц Azure , если это кому-нибудь поможет.

Одна из проблем, с которыми я столкнулся при использовании метода Trace.Writeline, заключается в том, что журналы хранятся в локальном экземпляре и периодически переносятся в хранилище таблиц Azure. Учитывая временный характер экземпляра Azure, все локальное хранилище в лучшем случае следует считать временным. Поэтому всегда есть окно для потери ваших данных журнала, пока они хранятся на локальном диске.

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

Answer 5

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

Библиотека предприятия в Windows Azure

Answer 6

Как уже упоминалось, использование диагностики Windows Azure - это путь.Тем не менее, все записи из всех ваших экземпляров заканчиваются в одном большом списке, который может быть трудно прочитать.Поэтому я стараюсь отправлять только относительно важные сообщения (уровень предупреждения и выше) в диагностические таблицы.Несмотря на это, это трудно читать таблицу напрямую.Есть несколько инструментов, я лично использую Cerebrata Diagnostics Manager.

Хотя использование функций трассировки работает нормально, я бы предложил использовать каркас журналирования, такой как NLog или log4net.Это дает вам большую гибкость при отправке некоторых сообщений Trace / Azure Diagnostics и других в локальное хранилище.

Например, я добавил тонну журналирования трассировки, чтобы отследить проблему с зависанием потока.Я обнаружил, что указание относительного корневого пути к файлу, например "\ ServiceLogs \ MyLog.txt", приведет к выводу на диск F: экземпляра.Поэтому я перенаправил все это на файловую систему экземпляра, а не на таблицы диагностики.Вы должны удаленно войти в каждый экземпляр, чтобы просмотреть эти журналы, но в этом случае это хороший компромисс.

Answer 7

Хотя это не традиционная структура ведения журнала, Story Framework может действительно помочь, когда вы действительно хотите читать свои журналы, она «заставляет» вас писать все журналы (и добавлять другую соответствующую информацию) в контексте, когда вам нужно чтобы прочитать это позже, вы получите все, что вам нужно.

Он также поддерживает сохранение журналов в хранилище таблиц Azure.

Более подробная информация и примеры этого блога .