Не приведете пример ? Вдруг уже есть какие-то готовые решения. Спасибо

null

Отредактировано пользователем 18 марта 2021 г. 23:42:00(UTC)  | Причина: Не указана

null

Отредактировано пользователем 18 марта 2021 г. 23:42:15(UTC)  | Причина: Не указана

Если что я не сотрудник, но я вижу что здесь на форуме хотя бы отвечают, в отличие от поддержки многих других программ. И сам стараюсь отвечать.Как бы слишком оптимистично надеяться, что Вы только поставили свежее обновление и сразу со скоростью света уже известны все проблемы, которые принесло обновление и найдены пути их решения. Майкрософт начхать что какие-то программы не работают после их обновлений и предварительно обновления ни с кем не согласуют.

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

Да как бы с классификацией событий не спорим и про еще одну сущность речь не идет, просто на новых версиях Windows в EventLog целое дерево журналов. Речь о возможности корректировки пути в дереве EventLog, чтобы события определенной программы EventLog отправлял в отдельный файл журнала. Никто не спорит, что создать фильтр системного журнала достаточно легко, но для этого надо: 1) знать коды событий которые искать; 2) надо чтобы на момент просмотра события все еще были в журнале. К сожалению, это далеко не всегда верно.

Причина проста - размер файлов журнала ограничен и когда одна программа за секунду регистрирует 20 однотипных сообщений, сообщения о других события тупо могут вытесняться из системного журнала. Увеличить журнал также временное решение потому что а) никогда неизвестно заранее насколько интенсивным будет потом событий и б) увеличение размера не вернет уже вытесненные события. Поэтому даже если согласно документации просматривать еженедельно системный журнал может "внезапно" оказаться что за неделю какая-то другая программа нафлудила так, что сообщений криптопровайдера криптопро просто не сохранилось. Или наоборот криптопро нафлудил так, что невозможно допустим понять какие были ошибки в репликации.

Обычно EventLog подавляет такой флуд сообщений Майкрософт и пишет потом сводку, что за сутки произошло столько-то одинаковых ошибок (синхронизации времени, например). Однако криптопро почему-то в такую фильтрацию не попадает и временами "дух захватывает" сколько сообщений за неделю записано в системный журнал. Поэтому речь скорее о том чтобы разные программы "не перебивали" друг друга записывая события в один журнал и с этим как раз справится вариант "поправки пути в дереве EventLog", чтобы события попадали в отдельный файл с отдельным ограничением размера.