Всё, конечно, зависит от стоящих перед вами задач (для чего лог), но скорее всего %ETN и его производные не подойдут - это ведь отладочный лог, куда пишутся все переменные, поэтому накладные расходы на его запись довольно велики.

Если инициаторы - "безопасники", то им, возможно, будет достаточно имён вызываемых сервисов и параметров запросов. В некоторых случаях интересуют значения отдельных полей результатов запроса, т.е. "it depends".

Мне приходилось участвовать в подобных разработках, и самый общий совет, который могу дать: работа системы наблюдения не должна влиять на производительность объекта наблюдения. Поэтому на системном уровне, как минимум: отдельная БД в отдельной файловой системе на отдельном контроллере с write-back кэшем, и всё это должно быть быстрым по записи. На прикладном уровне: конечно же, никаких транзакций - журналирования - индексации во время записи лога.

Если планируется серьёзная аналитика по данным лога, лучше сразу подумать об отдельном сервере безопасности. О механизмах передачи надо думать, универсального решения здесь нет. Возможно, кого-то устроит ежесуточное (или ежечасное) восстановление бэкапов БД лога, а кому-то потребуется оперативная передача данных (ECP?).