У нас есть специальная служба Windows в нашей производственной среде, которая для целей аудита и диагностики создает файлы журналов в файловой системе. Файлы журнала довольно подробны (по необходимости) и производят около 100 Мбайт ежедневно. Содержимое журнала должно храниться в течение 12 месяцев, но его можно легко сжимать.
Мы рассматриваем возможность включения сжатия O / S для этой папки, чтобы сэкономить место, а это уже имеет значение на этом сервере.
Есть ли какие-либо потенциальные ловушки или проблемы, с которыми мы можем столкнуться при этом? Следует ли учитывать какие-либо проблемы с производительностью, совместимостью или стабильностью? Если да, то как мы можем определить, подходит ли это нам?
Я лично сделал это на одном сервере Windows, за который отвечал. Я думаю, это хорошая идея. Как вы упомянули, повторяющийся простой текст в файлах журнала ОЧЕНЬ хорошо сжимается. Накладные расходы, связанные со сжатием, казались довольно небольшими. Я использовал его для журналов брандмауэра и легко выгружал 100 МБ + в день. (хотя я разбил его на файлы размером 20 МБ) Если ваш процессор изначально не привязан, я не думаю, что это будет проблемой. По сути, вы обменяете небольшую мощность процессора на много дискового пространства. Иногда это очень хороший компромисс. В других случаях не так уж много.
Очевидно, что тестирование - хорошая идея. Но особых проблем у меня не было. Просто имейте в виду, что сжатие не подлежит передаче, как старомодный zip-файл. Поэтому, если вы переместите это через FTP / CIFS / и т. Д., Вы переместите несжатую сумму. Если вы копируете их за пределы сжатой папки, вы перемещаете несжатый объем. Если вы используете программное обеспечение для резервного копирования, вы создаете резервную копию несжатого объема. И т.п.
Возможно, стоит отметить, что когда вы фактически устанавливаете флажок для этой папки, происходит начальное сжатие. Таким образом, вы можете сжимать подмножество за раз, чтобы не ставить сервер на колени, пока он сжимает ваши журналы в течение часа. Это может быть значительным в зависимости от того, сколько у вас информации журнала и насколько важно ваше приложение. Но, как уже было сказано, вы всегда можете отменить процесс и так же легко распаковать каталог. Так что, если вы обнаружите, что производительность слишком низкая, вы всегда можете * вернуть ее обратно.
Как уже упоминалось, сжатие только долгосрочных архивных журналов - неплохая идея. Если вы хотите приложить немного больше усилий к решению, вы всегда можете автоматизировать процесс архивирования этих журналов и избавить себя от необходимости делать это через ОС.
** Ничего "всегда" в IT не работает. ;) *
- Кристофер Карел
Лично я бы не стал настраивать «живое» ведение журнала для входа в сжатую или зашифрованную папку. Я бы создал папку архива и переместил файлы журнала из папки журнала приложения в эту папку сжатого архива после того, как приложение закончит запись в них. Я предполагаю, что файлы журнала «катятся» ежедневно, поэтому сегодняшний файл журнала активен и записывается без сжатия в папку журнала приложения, а когда приложение запускает новый файл журнала, предыдущий файл журнала перемещается в сжатый папка.
Если у вас еще нет большой загрузки процессора, вам, вероятно, будет полезно сжать файлы журнала.
Я не вижу никаких предупреждений от MS, когда здесь рекомендуется сжатие: https://docs.microsoft.com/en-us/iis/manage/provisioning-and-managing-iis/managing-iis-log-file-storage