Ошибка Log Disk Exhaustion on vCenter 7, 100% решение

Добрый день! Уважаемые читатели и гости одного из крупнейших IT блогов по виртуализации и настройке серверов Pyatilistnik.org. В прошлый раз мы с вами успешно устранили две ошибки с оборудованием "Код 28" и "Код 10". Идем дальше и сегодня я вам хочу показать, что делать в ситуации, когда vCenter Server показывает вам предупреждение "Log Disk Exhaustion on vCenter" и "Appliance Management Health Alarm" на главной вкладке Summary. Сразу скажу, что все устраняется очень быстро.

Причины ошибки Log Disk Exhaustion on vCenter

Небольшая предыстория, у меня на работе есть кластер из 26 хостов ESXI 6.5 работающих на серверах Dell R740. Началась массовая работа по их обновлению до ESXI 7.01, а заодно и обновление BIOS. Все это вызывало несколько перезагрузок и кучу миграций DRS при переводе сервера в maintenance mode, а это как следствие куча сообщений в различные логи.

Я использую VCSA 7 Update 2

Ошибки отображаются в vCenter Server в виде сообщений:

[wawrning]"Log Disk Exhaustion on vCenter" и "Appliance Management Health Alarm" [/wawrning]

Еще вы можете увидеть ошибки:

• vSphere UI Health Alarm" - Кончилось место на дисках для логов
• Database Health Alarm" - Исчерпание ресурсов ядра и инвентарного диска на сервере

Данные сообщения начинают появляться на вашем VCSA 7, когда диск заполняется на 80%, об этом написано на сайте вендора.

• Обратите внимание, что в версии vCenter 6.7 диск /storage/и далее может быть заполнен до 100% по замыслу.
• Более ранние версии vCenter 6.7 могут по-прежнему отображать ошибку в графическом интерфейсе. Их можно спокойно игнорировать, но лучше все же выполнить нижеописанные действия

Причины ошибки Log Disk Exhaustion on vCenter

Существует множество возможных причин нехватки места на определенных разделах диска. Некоторые причины включают:

• Блоки имеют неправильный размер
• Большие файлы в разделах, ниже я покажу такой файл
• Таблицы в базе данных, занимающие место
• Службы не могут очистить файлы логов

Для моего VCSA 7 я использовал стандартные размеры разделов, которые идут при новом развертывании. Я думаю, что не вижу проблему со службами, очищающими пространство журналов, поскольку я думаю, что журналы просто накапливаются и становятся достаточно большими, прежде чем они будут удалены. Давайте разбираться в чем дело.

Как найти, где и чем забит диск?

Первое, что бы должны сделать, это произвести подключение по ssh к вашему vCenter Server. Сделать это можно, через Putty. Введите shell, чтобы переключиться на BASH. Далее нужно проверить, в каком разделе возникла проблема, для этого выполните:

У меня полностью забитым оказался раздел /storage/log на 100%.

Затем, чтобы посмотреть, где именно используется дисковое пространство в разделе /​​storage/log, вы можете ввести команду:

Команда выведет 20 самых объемных директорий. Самые толстые:

• /storage/log/wmware-sps
• /storage/log/lookupsvc/tomcat/

Зная теперь эти каталоги можно спокойно посмотреть их содержимое, для своего удобства я буду использовать утилиту WinSCP, как через нее подключаться посмотрите по ссылке. При подключении у вас может возникнуть ошибка:

Как устранять ошибку подключения к vCenter через WinSCP смотрите по ссылке.

Первое куда я пошел, это был каталог:

Тут было очень много 6 мегабайтных файлов формата log, где содержалось много записей "[30/Nov/2020:00:00:07 +0000] [tomcat-http--36] "POST /eam/sdk HTTP/1.1" 200 299 [Processing time 3 msec]". Тут я почистил все старый файлы, которые были старше двух недель.

Следующая папка будет:

Папка содержала много файлов формата localhost_access.2021-04-01.log, с содержимым "[30/Nov/2020:00:00:07 +0000] [tomcat-http--36] "POST /eam/sdk HTTP/1.1" 200 299 [Processing time 3 msec] "Go-http-client/1.1"'

Я так же удалил все, что посчитал для меня не нужным.

Еще я в каталоге /storage/log/vmware/vmware-sps/ есть файл sps-runtime.log.stderr, который весил, аж целых 18 ГБ.

Я не стал удалять данный файл, я его скопировал на всякий случай и потом просто его очистил, через ssh команду:

Мне подсказал старший коллега про (cat /dev/null >), когда вы хотите стереть содержимое файла, при этом гарантируя, что нет абсолютно никакого риска прерывания к фактическому состоянию файла. Содержимое файла будет явно удалено, но сам файл - так как он существует и известен файловой системе, в которой он находится - все равно будет там с тем же номером инода, владельцем и разрешениями. В итоге файл на лету стал 0 мегабайт.

Проверим через пару минут состояние разделов, через команду df -h. Как видим, теперь с дисковым пространством все в порядке.

На этом у меня почти все, если вы не хотите уменьшать ваши логи, то можете попытаться расширить диск и разделы vCenter, но это уже другая история. Мы успешно устранили ошибку Log Disk Exhaustion on vCenter 7. С вами был Иван Семин, автор и создатель IT портала Pyatilistnik.org.