Очередная ситуация с заканчивающимся местом на диске на одном из веб-серверов (по причине расплодившихся логов IIS) заставила задуматься о том, что не лишним будет провести хотя бы поверхностный анализ размера каталога логов IIS на всех серверах. Помимо такого анализа желательно автоматизировать процедуру удаления старых лог-файлов IIS на тех веб-серверах, где это возможно.
По ранее используемому примеру, создаём скрипт удаления старых файлов. В качестве основных переменных задаём количество времени (в днях), за которое нужно хранить логи IIS, а также локальный путь на веб-сервере, где эти самые логи хранятся.
Param ( #период в днях, старше которого файл считается пригодным к удалению [int]$Period = 10 , #каталог для просмотра [String]$PATH = "C:\inetpub\logs\LogFiles" , #включать ли вложенные каталоги [bool]$recurse = $true ) filter Get-OldFiles { if (($_.Attributes -ne "Directory") ` -and ` (([DateTime]::Now.Subtract($_.CreationTime)).Days -gt $Period)) {return $_ } } if ($recurse) {dir -path $PATH -recurse | Get-OldFiles -Period $Period | Remove-Item -recurse -force} else {dir -path $PATH | Get-OldFiles -Period $Period | Remove-Item -force}
Скрипт сохраняем на веб-сервере по полному пути, например
C:\Tools\Scripts\Delete-Old-IIS-Log-Files.ps1
В Планировщике заданий Windows (Task Scheduler) создаём задание на периодический запуск данного скрипта командой:
powershell.exe -NoProfile -command "C:\Tools\Scripts\Delete-Old-IIS-Log-Files.ps1"
В сети может быть большое количество серверов, на которых работают сайты на базе IIS, однако на всех таких серверах интенсивность записи в логи разная. Чтобы понять, на какие веб-серверы имеет смысл “прикручивать” скрипт удаления старых логов IIS, а на какие нет, воспользуемся ещё одним PS-скриптом. С помощью этого скрипта мы получим список серверных системы из каталога Active Directory и проверим на каждом из серверов размер каталога логов IIS (по умолчанию расположен в C:\inetpub\logs) при условии его наличия.
Import-Module ActiveDirectory $TestFolder = "\C$\inetpub\logs" $OU = "OU=AllComputers,DC=holding,DC=com" $Filter = "(&(objectClass=computer)(!description=*cluster*)(operatingSystem=*Windows Server*)(!userAccountControl:1.2.840.113556.1.4.803:=2))" $Servers = Get-ADComputer -SearchBase $OU -ResultSetSize $null -LDAPFilter $Filter ForEach ($Server in $Servers){ $ServerName = $Server.DNSHostName ping.exe $ServerName -n 1 | out-null; If ($LASTEXITCODE -eq 0){ # Сервер доступен, проверяем наличие папки... $RemotePath = "\\" + $ServerName + $TestFolder If(Test-Path -Path $RemotePath){ $size = (Get-ChildItem $RemotePath -recurse | Measure-Object -property length -sum) "$ServerName - " + "{0:N2}" -f ($size.sum / 1MB) + " MB" } } Else{ Write-Host "Сервер $ServerName недоступен" -ForegroundColor Red } }
Архив со скриптами и готовым экспортированным заданием Планировщика заданий (импорт задания проверялся на системах Windows Server 2012 R2) можно загрузить по ссылке.
RSS - Записи
ping.exe $ServerName -n 1 | out-null; можно наверняка заменить на Test-Connection -Quiet -ComputerName $ServerName
Можно и так :)
не понял, как работает конструкция filter :-(
Что именно не понятно?
Сделал примерно то же самое, только старые логи пакуются в архивы, которые в свою очередь тоже удаляются через какое-то время.
Разумеется это хорошо и правильно. Такой сценарий больше подойдёт для веб-серверов, где логи IIS играют какое-то важно значение, например с точки зрения безопасности (для возможности последующего анализа логов). У меня же речь идёт о безжалостном удалении старых логов.
А задания планировщика под аккаунтом с какими правами выполняются? Domain admin?
Вопрос - провокация? Ответ на него напрямую зависит от степени Вашей испорченности. Если Вы "настоящий танкист", то можно выполнять подобные задания шедулера и от имени энтерпрайз-админа и ещё в добавок папку со скриптом расшарить и сделать доступной на запись всем пользователям домена %)))
хыхы :) Но нужен же доступ до объектов AD, так что сначала надо делегировать его какой-то учетке, да. Но это уже другой вопрос, да :)
Не пойму о чём Вы говорите. Шедулим только первый скрипт. Его в задании шедулера можно выполнять как от имени LocalSystem (самый простой вариант), так и от отдельно созданной учетной записи, у которой есть права исключительно на полный доступ к $PATH (более сложный вариант, но и более безопасный...для параноиков). Второй скрипт выполняется разово и только для того, чтобы оценить то, на каких серверах имеет смысл настраивать удаление логов, а на каких нет. Его разумеется нужно выполнять в контексте безопасности учетной записи администратора всех этих серверов, так как идёт попытка доступа к административной шаре С$ на этих серверах. Вопрос доступа к объектам AD тут вообще второстепенный, так как в данном случае используется простое перечисление компьютеров, как объектов, доступных на чтение любому рядовому пользователю домена.
Спасибо за статью и скрипты, а то недавно начались проблемы с реверс прокси, первым делом залез на консоль IIS и попытался добавить/редактировать правила ARR, вылезла ошибка записи файла - посмотрел на свободное место - 0 байт! Логи IIS под 90Гб :)
Странным стечением обстоятельств, данный сервер не был добавлен в Zabbix для мониторинга состояния дисковой подсистемы) Настроили Job, запустили, освободили 59Гб)))