Назад | Перейти на главную страницу

Рекомендации по замене базы данных журналов приложений

Наши веб-приложения (около 30) регистрируют специфические для приложений данные в централизованной базе данных журналов (Sql Server 2012) с помощью log4net, поэтому база данных журналов быстро становится огромной. Поэтому мы решили заменять его каждый год, например, переименовав текущую базу данных журналов (например, AppLog в AppLog2015), а затем создав новую базу данных журналов (AppLog) для веб-приложений. Нам необходимо сохранить замененные базы данных для будущего расследования.

Как лучше всего выполнять эту замену? Лучше просто выставить время простоя всех приложений при замене? Или можно заменить базу данных без простоя?

Любой совет будет принят во внимание. Также приветствуются советы совершенно другого подхода.

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

Это не столько решение Microsoft, сколько стек ELK для больших масштабов в мире с открытым исходным кодом. Т.е. Эластичный поиск, Логсташ, Кибана. По крайней мере, должно быть интересно прочитать о том, чтобы получить представление о том, как может выглядеть масштабируемое решение. Интеграция с инструментами Microsoft должна быть выполнимой, поскольку вы можете просто отправлять журналы, используя протокол syslog. Достаточно просто, если приложения являются вашими собственными, но может быть целесообразно, если ваши приложения включают сторонние инструменты, которые не могут сделать это легко.