Логи показывают последовательность событий
Когда сервер падает или перестаёт выполнять команду, владелец часто сразу переустанавливает плагин. Это может временно изменить поведение, но не объясняет причину.
Журнал позволяет увидеть, что произошло перед ошибкой: обновление, загрузка карты, подключение плагина, запрос базы или нехватка ресурсов.
Какие журналы существуют
У проекта может быть несколько источников:
- консоль CS2;
- игровые логи;
- CounterStrikeSharp;
- отдельные плагины;
- systemd;
- SteamCMD;
- nginx;
- PHP;
- база данных;
- SSH;
- firewall;
- cron.
Не ищите всё в одном файле. Сначала определите, какая система связана с симптомом.
Начните со времени
Запишите точное время проблемы и часовой пояс. Затем просмотрите журналы за несколько минут до и после события.
Поиск без временной точки создаёт слишком много шума. В длинном логе одинаковая ошибка может встречаться сотни раз.
Если жалобу сообщил игрок, уточните карту, команду и примерное время.
Уровни сообщений
Типичные уровни:
- debug;
- info;
- warning;
- error;
- critical.
Не каждое предупреждение означает неисправность. Некоторые плагины записывают предупреждение о необязательной функции.
Критичнее повторяющиеся ошибки, исключения и сообщения непосредственно перед завершением процесса.
Исключения плагинов
В исключении обычно указаны:
- тип ошибки;
- сообщение;
- файл;
- строка;
- стек вызовов;
- название плагина.
Читайте не только последнюю строку. Первое содержательное сообщение часто находится выше.
Ошибка подключения к базе может проявляться внутри статистического плагина, но причиной будет недоступная база или неверный пароль.
Журнал systemd
Systemd показывает:
- когда служба запустилась;
- какой код завершения получила;
- была ли остановлена вручную;
- выполнялся ли автоматический перезапуск;
- сколько попыток произошло.
Если служба быстро перезапускается, сначала остановите цикл и изучите первый сбой.
Ошибки после обновления
Сравните время первой ошибки с датой обновления игры или плагина. Если проблема появилась сразу после замены файлов, проверьте совместимость.
Не удаляйте старый журнал перед обновлением. Он нужен для сравнения нормального и неисправного запуска.
Поиск повторов
Используйте поиск по словам:
error;failed;exception;missing;timeout;denied;killed;out of memory.
Но оценивайте контекст. Строка no error тоже содержит слово error.
Нехватка памяти
Если Linux завершил процесс из-за памяти, игровая консоль может не успеть записать понятную ошибку. Проверяйте системный журнал и сообщения ядра.
Признаки:
- внезапное завершение;
- рост памяти;
- активный swap;
- запись об OOM;
- падение нескольких сервисов одновременно.
Диск
При заполненном диске перестают записываться логи, базы и конфигурации. Последняя запись может выглядеть старой, потому что новые сообщения физически не сохранились.
Проверяйте свободное место и inode.
Архивирование журналов
Настройте ротацию:
- ограничение размера;
- хранение нескольких файлов;
- сжатие старых журналов;
- удаление по сроку;
- защита от заполнения диска.
Не удаляйте всё ежедневно, если проблему могут заметить только через несколько дней.
Создание отчёта об ошибке
Хороший отчёт содержит:
- дату и время;
- симптом;
- карту;
- онлайн;
- последние изменения;
- версии;
- фрагмент журнала;
- шаги воспроизведения;
- результат теста без плагина.
Не отправляйте специалисту гигабайты файлов без описания.
Внешняя проверка
Сопоставляйте внутренние логи с доступностью на cs2-monitor.com. Если мониторинг зафиксировал офлайн в то же время, проблема затронула внешний ответ сервера.
Если процесс работал, но мониторинг не получал данные, проверяйте сеть и query-порт.
Итог
Анализ логов начинается со времени, источника и последних изменений. Не ищите случайные слова во всех файлах сразу.
Сохраняйте историю, настраивайте ротацию и составляйте короткий отчёт. Это сокращает диагностику с нескольких часов до последовательной проверки конкретных событий.