рабочая настройка ведения журнала Azure

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

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

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

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

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

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

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

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