Стандартные журналы диагностики Logic App — потеря данных
Фон
Наша команда активно использует приложения логики (стандарт) при построении корпоративных интеграций. Эти интеграции иногда отправляют важные для бизнеса сообщения, которые мы не можем потерять. А если сообщение было потеряно, что случается время от времени, мы хотим иметь возможность его отследить. Поэтому мы решили настроить параметры диагностики и отправлять отслеживаемые свойства в рабочие процессы, которые затем можно отслеживать с помощью правил оповещений, которые запускают уведомления в группу действий и т. д.
Проблема
Теперь мы начали понимать, что теряется много журналов. Из 22 тысяч ожидаемых точек журнала около 4–6 тысяч теряются и никогда не попадают в рабочую область Log Analytics. И это плохо, поскольку у нас нет возможности легко увидеть, что обработали рабочие процессы; Конечно, мы могли бы рассмотреть отдельные прогоны рабочего процесса, но это заняло бы слишком много времени. Короче говоря, мы хотим предоставить нашей оперативной команде надежные журналы.
В документации указано следующее:
Журналы ресурсов Azure Monitor не на 100% без потерь. Журналы ресурсов на основе архитектуры магазина и пересылки, предназначенной для недорогого перемещения петабайт данных в день в масштабе. Эта возможность включает в себя встроенный избыточность и повторные попытки на всей платформе, но не обеспечивает транзакционные гарантии.
Однако потеря примерно 20 % журналов кажется чрезмерной, особенно с учетом относительно небольшого объема по сравнению с огромным количеством журналов, которые могут быть приняты в Log Analytics.
Действия по устранению неполадок
Мы позаботились о том, чтобы:
- выборка в WorkflowRuntimeLogs не производится.
- Logic Apps не голодает из-за ограниченного плана службы приложений.
- ожидаемые запуски рабочего процесса завершены, и данные достигают конечного пункта назначения. То есть имеем успешные прогоны без логов.
Вопросы
- Кто-нибудь еще сталкивался с подобным поведением, когда настройки диагностики указывали на Log Analytics?
- Есть ли какие-либо предложения по альтернативным решениям для ведения журналов, которые могли бы обеспечить более надежные журналы?
- Какие дополнительные шаги мы можем предпринять, чтобы минимизировать потери журналов?
Будем рады предоставить дополнительную информацию или разъяснения, если это необходимо. Любые идеи или предложения будут с благодарностью приняты.
Привет @ 10p! Запрос ничего не вернул, так что похоже, что это не так. Ведь логи всё равно приходят, просто некоторые из них теряются по пути, но попробовать стоило :)
Ответы 1
Log Analytics не предназначен для использования в качестве основного функционального инструмента отчетности, поскольку по своей сути он работает с концепцией выборки. Выборка — это метод, используемый для уменьшения объема данных, которые необходимо обрабатывать и хранить, путем рассмотрения только подмножества всего набора данных.
Хотя это полезно с точки зрения производительности и стоимости, это может привести к тому, что для отчетов будут доступны неполные данные. Несмотря на то, что функции Azure позволяют некоторый контроль над параметрами выборки (например, InitialSamplingPercentage), они не могут гарантировать 100 % сохранение данных. То же самое относится и к приложениям логики.
Ссылка на функции Azure и выборку согласно статье Microsoft о выборке в Azure Monitor. См.: https://learn.microsoft.com/en-us/azure/azure-monitor/app/sampling-classic-api#how-sampling-works
Как работает выборка
Для приложений, которые не работают со значительным загрузки выборка не требуется, поскольку эти приложения обычно могут отправлять все свою телеметрию, оставаясь в пределах квоты, не вызывая передачи данных потери от дросселирования.
В Microsoft даже есть четкие инструкции, когда настроен высокий процент выборки:
Что произойдет, если я настрою слишком высокий процент выборки?
Настройка слишком высокого процента выборки (недостаточно агрессивно) приводит к недостаточному уменьшению объема собираемого телеметрия. Вы по-прежнему можете столкнуться с потерей данных телеметрии, связанной с регулирование, а стоимость использования Application Insights может быть выше чем вы планировали, из-за расходов на перерасход.
Это означает, что для приложений с низкой нагрузкой выборка может не потребоваться, а потери данных можно свести к минимуму. Однако для приложений с более высокими нагрузками или критическими потребностями в журналировании использование этого механизма все равно может привести к потере данных из-за присущих ограничений и существующих механизмов регулирования. Это объясняет, почему вы видите 20%-ную потерю сообщений, зарегистрированных в журнале аналитики.
Спасибо за ваш вклад, Дитер! Приму ваш ответ, если в ближайшее время не будет представлено что-либо еще. Что касается аналитики журналов; Мы создали PoC, в котором мы принимаем журналы в Log Analytics через REST API вместо настроек диагностики. Уже сейчас мы обнаружили, что все логи подкачиваются без проблем; Видите ли вы какие-либо ограничения в этом подходе?
Я разделяю некоторые сомнения по поводу этого решения. Если клиенты выполняют выборку по умолчанию, это означает, что инфраструктура Microsoft, лежащая в ее основе, не может гарантировать доставку каждого сообщения. Чтобы внести ясность в этот вопрос, я рекомендую открыть заявку в службу поддержки Microsoft, чтобы подтвердить, обеспечивает ли использование REST API полное сохранение данных или все еще существуют потенциальные подводные камни.
Возможно ли, что вы достигли дневного лимита, из-за чего прием пищи прекратился до следующего дня? Вы можете проверить, так ли это, выполнив следующий запрос в Log Analytics:
_LogOperation | where Category =~ "Ingestion" | where Detail contains "OverQuota"