Автоматическая настройка

Я пытался настроить ведение журнала трассировки на некоторое время, и я просто не могу заставить его работать правильно. Это не помогает им так много неправильных/устаревших статей по этой теме. Но, пожалуйста, кто-нибудь даст мне хорошую и практичную настройку для отслеживания трассировки и просмотра Azure (1.6)

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

Я начал со стандартного DiagnosticMonitorTraceListener, но это заканчивается в хранилище таблиц. Я не могу для жизни понять, как я должен взаимодействовать с журналами в хранилище таблиц. В Visual Studio я могу "просматривать" его, но это очень громоздко, чтобы использовать его, это практично бесполезно. Нет сортировки, приходится писать громоздкие фильтры даты, которые в половину времени не работают.

Пользовательские журналы кажутся подходящими. Я много работал с log4net, поэтому я выбрал его. Вы можете перенаправить log4net на трассировку, но затем вы получите то же дерьмовое хранилище таблиц. Пользовательский файл журнала это. Теперь я уже смущен, если это поддерживается или нет. В некоторых статьях упоминаются диагностические блокировки файлов, вызывающие всевозможные проблемы. Не уверен, что это все еще проблема, независимо от того, что это странно, зачем предоставлять возможность передачи пользовательских журналов, когда вы не можете читать/записывать журналы? Во всяком случае, у меня не было проблем с записью в журнал (что я заметил).

Настройка выполняется в соответствии с статьями MSDN (с лишним расплывчатым и очень распространенным образом). Определите элемент LocalStorage в ServiceDefinition (128Mb). Добавить передачу журнала каталога при запуске роли. Идти. Кажется, это работает. До тех пор, пока какое-то время роль во время перезапуска с помощью generalQuota не будет достаточно большой, а роль просто умирает и отказывается подниматься. Внутри 4080Mb есть много свободного места, это просто не имеет смысла.

Снова последовали статьи об увеличении квоты, но это, казалось, еще хуже. Установите для параметра "Диагностический магазин" значение 8 ГБ в ServiceDefinition. Не работает. Все еще дерьмо, только с большим числом. Кроме того, не рекомендуется использовать значение CommonQuota равным 8 ГБ. По какой-то причине установка на чистом изображении работает нормально, но когда есть перезапуск или обновление, он решает вычислить квоту по-разному. Независимо от размера хранилища DiagnosticsStore, "вычисленное" значение всегда имеет значение CommonQuota + Log4Net LocalStorage. Я ничего не делаю, это меняет. Чрезвычайно расстраивает, как кажется, работает, только чтобы умереть через некоторое время.

Я также пробовал диагностику .wadcfg, но не смог заставить Azure забрать их. Я убедился, что они были скопированы в корневую папку вывода и удалены любые изменения на мониторе из моего кода. Nada, zip... просмотрел все файлы журналов, которые я мог найти в экземпляре. Ни одного упоминания или ошибки нигде.

Почему так сложно на Azure? Журналы трассировки - это самый базовый инструмент ведения журнала для любого приложения. Это действительно убивает опыт Azure.

Ответ 1

Мы также используем Log4Net на Azure

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

Как настроить его... Легко как.

в Global.asax в соответствии с обычной конфигурацией log4net

protected void Application_Start()
{
    log4net.Config.XmlConfigurator.Configure();
}

в вашей точке ввода роли... запустите также конфигурацию. F # * ^ знает почему, но если вы не сделаете это в обоих местах, это не сработает (ну, в любом случае, не в моем случае)

public override void Run()
{
    log4net.Config.XmlConfigurator.Configure();
}

Затем в ваших конфигурационных файлах

<log4net>
    <appender name="TraceAppender" type="log4net.Appender.TraceAppender">
        <layout type="log4net.Layout.PatternLayout">
            <conversionPattern value="%date [%thread] %-5level %logger [%property{NDC}] - %message%newline" />
        </layout>
    </appender>
    <root>
        <level value="ALL" />
        <appender-ref ref="TraceAppender" />
    </root>
</log4net>

Убедитесь, что включена трассировка Azure

<system.diagnostics>
     <trace>
          <listeners>
              <add type="Microsoft.WindowsAzure.Diagnostics.DiagnosticMonitorTraceListener, Microsoft.WindowsAzure.Diagnostics, Version=1.7.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" name="AzureDiagnostics">
                  <filter type="" />
             </add>
          </listeners>
     </trace>

Мы решили отказаться от использования причины Storage Studio, любые данные, выходящие из Azure, за которые вы платите... транзакции данных в Azure бесплатны, подключение к хранилищу таблиц легко, как пирог, поэтому мы создали экран для отображения журналов, занял 2/3 часа, как бомба

Ответ 2

Мы успешно используем log4net с Azure, однако мы собираем данные в Azure Table Storage. Это, безусловно, более масштабируемое решение. Я настоятельно рекомендую вам приобрести лицензию на Cerebrata (теперь RedGates) Storage Studio, чтобы облегчить боль при работе с хранилищем таблиц Azure и их Диагностический менеджер, чтобы облегчить боль при просмотре журналов трассировки.

Ответ 3

В сценариях, где имеется большое количество данных журнала, мы попытались передать данные в Blobs - частично используя EtwTraceListener как отправьте важные фрагменты информации, которые нам нужно использовать для хранения таблиц. Мы используем как AzureStorageTraceListener, так и создали пользовательский TraceListener, который направляет данные в нашу собственную таблицу Azure, поскольку схема OOB не соответствует нашим требованиям. Поскольку WADLogsTable может быстро развиваться, и нам нужен способ обрезать его, не прибегая к огромной стоимости Txn Storage или при отключении Tracing в автономном режиме, пока мы заканчиваем удаление/воссоздание таблицы, мы используем нашу пользовательскую таблицу, которая создает другую таблицу для каждого месяца.

Ranjith
http://www/opstera.com

Ответ 4

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

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