Встречаются приложения, которые генерируют определённое количество текстовых логов, но при этом не имеют встроенной функциональности для их ротации. Могут возникнуть проблемы с производительностью файловой системы и/или нехваткой свободного места если запись в лог-файл ведётся достаточно интенсивно и его размер вырастает до неприличных величин. Здесь я опишу пример создания рабочего процесса (Runbook) в System Center 2012 Orchestrator (SCO) для систематической ротации логов на удалённом сервере.
В качестве входных параметров задачи имеем следующие условия:
- Ротации должны подвергаться файлы DBLog.txt, AppLog.txt, ErrorLog.txt
- Процесс ротации должен выполняться 1 раз в сутки в 07:00
- При условии что любой из указанных файлов становиться больше 100 MB, он должен быть переименован и заархивирован в отдельный каталог (подразумевается что приложение способно самостоятельно создавать свежий лог файл)
- Архивы логов не должны накапливаться и храниться более года
Результативный рабочий процесс будет выглядеть следующим образом:
Далее опишем свойства каждого этапа, то есть каждой активности рабочего процесса.
1. Monitor Date/Time
Создана из стандартной активности (Activity) Scheduling - Monitor Date/Time. Из настроек имеет лишь время суток в которое запускается рабочий процесс
2. Log File Paths
Создана из стандартной активности System - Run .Net Script. В этой активности с помощью PowerShell мы задаём локальные переменные отвечающие входным параметрам нашей задачи. В нашем примере вводится три переменные:
- $ArchiveNameSuffix – суффикс (с текущей датой и временем) который будет добавляться к имени лог-файла при переименовании
- $ArchiveFolderPath – путь к каталогу в котором будут сохраняться заархивированные логи
- $FullPathLogFilesArray – массив строк состоящий из полных имён лог-файлов которые мы будем подвергать ротации.
Дополнительно создаём в этой активности три соответствующих выходных параметра, которые будут использоваться в следующих этапах рабочего процесса
Все последующие активности будут выполняться для каждого файла прописанного в массиве $FullPathLogFilesArray
3. Get Log File
Создана из стандартной активности File Management – Get File Status. В свойствах этой активности мы получаем подробные сведения о лог-файлах (размер, атрибуты). В качестве входного параметра File используем созданный нами ранее выходной параметр Full path log files array из предыдущей активности. Как я уже сказал, этот параметр будет содержать массив строк с полными путями к лог-файлам.
4. Log Size more than 100 MB
Создана из стандартной активности Utilities – Compare Values. В свойствах этой активности на закладке General указываем тип сравнения – Compare Numeric Values
На закладке Details указываем, что значение входящего параметра File size (bytes) из активности Get Log File должно быть больше 104857600 байт.
То есть дальнейшая обработка рабочего процесса заканчивается, если не удалось найти ни одного файла размером более 100 MB
5. Rename Log
Создана из стандартной активности File Management – Rename File.
Если по результатам предыдущей активности найден хоть один файл больше указанного размера, то в этой активности мы переименовываем этот файл, добавляя к концу его имени суффикс который мы задали ранее. В поле Folder (папка в которой будут переименовываться файлы) используем значение выходного параметра File folder из активности Get Log File
В таблицу правил переименования добавляем одно правило, которое значит то, что будет искаться файл с именем File name из активности Get Log File и переименовываться с добавлением суффикса. То есть например файл DBLog.txt будет переименован в DBLog.txt.2012-08-17_15-01-15.log
6.Compress Renamed Log
Создана из стандартной активности File Management – Compress File. Активность предназначена для создания архива из переименованного лог-файла в предыдущей активности.
В нижнем поле в разделе опций указываем тип сжатия. Как ни странно, опыты показали что уровень Medium жмёт текстовые логи лучше чем High. Также определяем тип поведения если архив с указанным именем уже существует.
В поле Folder (полный путь к файлу который будет архивироваться) указываем параметр Name and path of the destination file из предыдущей активности Rename Log
В поле File (полный путь к создаваемому архиву) указываем значение, сложенное из двух параметров разных предыдущих активностей:
В результате этой активности файл вида DBLog.txt.2012-08-17_15-01-15.log будет заархивирован в файл DBLog.txt.2012-08-17_15-01-15.log.zip
7. Delete Renamed Log
Создана из стандартной активности File Management – Delete File. Активность удаляет переименованный лог-файл после его успешной архивации на предыдущем этапе.
В свойствах этой активности в поле Path (полный путь к удаляемому файлу) указываем ссылку на параметр Name and path of the destination file из предыдущей активности Rename Log
8. Delete Old Log Archives
Создана из стандартной активности File Management – Delete File. Активность отвечает за удаление устаревших архивов.
Указываем то что удалению подвергаются файлы с датой создания старше 365 дней.
В поле Path (полный путь к удаляемому файлу) используем два параметра из разных активностей для того чтобы составить маску имени удаляемых файлов в следующем виде:
Запускаем Runbook и проверяем результат.
Такой Runbook можно считать универсальным, так как он подойдёт для ротации любых текстовых логов расположенных на разных серверах. Для адаптации к конкретной среде достаточно изменить значения входных переменных в активности Log File Paths.
Только когда дописал заметку до конца, подумал, что значение максимального размера лог-файла и количество дней хранения тоже можно включить в список входных переменных PowerShell 
RSS - Записи
Добавить комментарий