Я думаю, что вы пытаетесь сравнить яблоки с апельсинами, позвольте мне объяснить, почему.
AI
Application Insights (AI) - это приемник, что означает, что вызарегистрируйте что-нибудь, используя SDK, и оно отправит это AI.ИИ будет буферизовать записанные события и посылать их один раз (я полагаю, по умолчанию 30 с) в облако, используя http-вызовы.
ИИ никогда не предназначен для использования в массовых, масштабных журналах.Если вы посмотрите на цены, вы увидите, что они будут дорого стоить, когда поступают большие объемы данных.
ETW
ETW на самом деле не является потерей,Вы можете регистрировать что угодно в источнике событий, но пока не подключен прослушиватель, ваши события никуда не ведут.Слушатель определяет, куда будут записываться события.
Для ведения журналов с крупномасштабными метриками команда расширила EventSource с поддержкой EventCounters (см. this doc )
ХорошоОсобенность ETW заключается в том, что вы можете подключить прослушиватель к тому же процессу, который также записывает в EventSource, или вы можете создать прослушиватель в отдельном процессе (на том же компьютере), и затем вы можете настроить, куда должно идти ведение журнала.Это может быть файл ETL, который впоследствии анализируется или обрабатывается, или он может отправляться в конечную точку приема больших данных, такую как Azure EventHub, и оттуда, например, в озеро данных или хранилище больших двоичных объектов для дальнейшего анализа.
Вопросы
ETW быстр, но поддерживает ли он все функции ведения журналов, а именно.счетчики производительности журналирования, уровни логирования, а именно.Отладка, информация, предупреждение, ошибка и т. Д.
Да, это так.Вы можете включить ведение журнала по уровню серьезности и / или ключевым словам.
Для моих требований к масштабированию (> 1 миллиона запросов в секунду) Достаточно ли хорошо знакомы приложения?Почему я должен использовать протоколирование ETW, а не анализировать приложения?
Как я уже объяснил, я думаю, что ИИ не предназначен для такого масштаба с точки зрения производительности и цены.Хотя данные собираются / буферизируются в отдельном потоке, они не предназначены для такой нагрузки.Он ограничен 32 КБ событий в секунду ( источник )
Что я не могу получить из информации о приложении, которую я могу получить из журналов ETW?
Производительность и гибкость в том, где заканчиваются зарегистрированные события.
С точки зрения накладных расходов на поток / процесс приложения ETW значительно лучше, чем понимание приложения, или они похожи?
Нет, они не похожи, у ETW гораздо меньше накладных расходов.Его поддержка встроена в операционную систему и работает просто быстро.
Вы можете использовать EventFlow , как это предлагается в комментариях, он поддерживает в процессе и вне процесса прослушиватели EventSource.
Если вы в конечном итоге используете другую среду ведения журналов, выберите такую, которая поддерживает структурированное ведение журнала , как это делает ETW.
Заключительные мысли
Я думаю, что вы должны прежде всего подумать о том, что вы хотите войти и что вы хотите с ним делать.Может быть вполне приемлемо регистрировать исключения и некоторые метрики в AI, чтобы вы могли осуществлять мониторинг своего приложения в реальном времени и записывать другие метрики или сведения об использовании в другое хранилище, например таблицы Azure, для анализа не в реальном времени.Не кладите все свои деньги только на одну раковину, но сначала определите стратегию ведения журнала.
Сила ИИ - это богатая визуализация, но она имеет свою цену.Аналитика Azure Data Lake не поддерживает визуализацию «из коробки», но использование u-sql для петабайтов данных журнала может оказаться полезным для других сценариев.Я надеюсь, что вы видите, куда я иду.