Ситуация, когда графики загрузки процессора, памяти и диска выглядят зелеными, но пользователи жалуются на недоступность сервиса, встречается часто. Стандартный мониторинг отслеживает лишь основные ресурсы, однако сервер может столкнуться с исчерпанием других критических параметров: inode, файловых дескрипторов, времени, DNS или валидности сертификатов. Ниже рассмотрены пять таких причин, их симптомы, методы диагностики и способы устранения.
Первая проблема — исчерпание inode. В отличие от места на диске, измеряемого в байтах, каждый файл, даже пустой, требует записи inode в таблице файловой системы. На файловых системах типа ext4 количество inode фиксировано при создании и не растет автоматически. Если все inode заняты мелкими файлами (кэшем, сессиями), диск может показывать свободное место, но создание новых файлов станет невозможным. Для диагностики используют команды df -i для проверки процента использования inode и find для поиска каталогов с наибольшим количеством файлов. Решение заключается в очистке старых файлов через find с фильтрацией по времени создания, а не через rm, который может вызвать ошибку из-за длины аргументов. В долгосрочной перспективе помогает создание отдельного раздела с большим количеством inode или переход на файловую систему XFS.
Вторая причина — превышение лимита открытых файлов (Too many open files). Каждый сетевое подключение и открытый файл занимают файловый дескриптор, и у процесса есть жесткий лимит на их количество. Если этот лимит исчерпан, сервер перестает принимать новые подключения, хотя работающие сессии продолжают функционировать. Стандартный мониторинг не видит этой проблемы, так как нагрузка на CPU и память может быть низкой. Лимит часто определяется настройками systemd, а не ulimit в консоли администратора. Для проверки нужно узнать PID процесса и посмотреть количество занятых дескрипторов в /proc/$PID/fd. Если нагрузка честная, лимит следует увеличить через systemd (LimitNOFILE), а если есть утечка (например, код открывает файлы и не закрывает их), необходимо найти и исправить причину утечки.
Третья причина — рассинхронизация времени на сервере. Ошибки в работе сервисов, таких как авторизация, работа с токенами или обновление пакетов, могут быть вызваны тем, что системное время отстает или опережает эталон. Сервер может отвечать на пинги и отдавать метрики, но из-за расхождения времени в несколько часов или дней транзакции будут считаться недействительными. Мониторинг часто не фиксирует эту проблему, так как метрики собираются с учетом времени самого агента мониторинга. Для диагностики используют timedatectl для проверки статуса синхронизации и chronyc для анализа расхождения с эталоном. Решение зависит от причины: включение службы chrony, исправление конфигурации серверов NTP или принудительная коррекция времени командой makestep, после чего необходимо перезапустить зависимые сервисы.
Четвертая проблема — неисправности DNS-разрешения. Сервис может работать локально, но не уметь находить адреса внешних зависимостей. Ошибки могут проявляться как полный отказ в разрешении имен или задержки ровно на 5–10 секунд, что указывает на таймаут резолвера. Мониторинг может показывать зеленые графики, так как процесс ожидания DNS не потребляет ресурсы CPU и памяти. Проблема может лежать на разных уровнях: в настройках nsswitch, в файле /etc/hosts, в конфигурации /etc/resolv.conf или в локальном кэше DNS. Для диагностики следует сравнивать ответы команд getent (проверяет nsswitch и hosts) и dig (проверяет DNS напрямую). Если ответы расходятся, нужно сбросить кэш или исправить конфигурацию. Важно также учитывать, что nginx может кэшировать IP-адреса при загрузке конфига и продолжать использовать старые данные после переезда сервиса.
Пятая причина — истечение срока действия SSL-сертификата. Сервер может работать корректно, но браузеры и клиенты будут выдавать ошибку безопасности. Сертификат не деградирует постепенно, а становится недействительным мгновенно после истечения срока. Стандартные проверки доступности часто игнорируют ошибки TLS, а автоматические уведомления от Let's Encrypt с июня 2025 года прекращены. Продление сертификата может не сработать из-за отсутствия таймера в cron, закрытия порта 80 для проверки HTTP-01 или того, что nginx продолжает отдавать старый сертификат из памяти после перезагрузки. Для диагностики нужно сравнить сертификат, который отдает сервер сейчас, с тем, что физически лежит на диске, используя openssl s_client. Если на диске новый сертификат, но сервер отдает старый, требуется перезапуск nginx или принудительное перечтение конфига.
