Ответ
При инциденте на сервере я сразу смотрю логи, чтобы понять контекст ошибки. Вот мой стандартный набор команд:
1. Основная команда tail:
# Посмотреть последние 50 строк лога приложения
sudo tail -n 50 /var/log/myapp/error.log
# Следить за логом в реальном времени (очень полезно при дебаге)
sudo tail -f /var/log/nginx/access.log
2. Просмотр логов systemd-сервисов через journalctl:
Это мой основной инструмент для сервисов, запущенных через systemd (например, PHP-FPM, бэкенд-сервисы).
# Логи конкретного сервиса за последние 5 минут
sudo journalctl -u php-fpm.service --since "5 minutes ago" --no-pager
# Последние 100 строк с подсветкой ошибок
sudo journalctl -u my-backend-service -n 100 -p err
# Логи с указанием временных меток в UTC
sudo journalctl -u nginx.service -n 50 --utc
3. Поиск по логам с grep:
# Найти все ошибки (ERROR, FATAL) в логе за сегодня
sudo grep -E "(ERROR|FATAL)" /var/log/myapp/app.log | tail -20
# Искать конкретную ошибку по trace-id
sudo journalctl -u app-service | grep "abc123-def"
4. Для контейнеризованных приложений (Docker):
# Логи конкретного контейнера
sudo docker logs --tail 100 my_app_container
# Логи с временными метками и в реальном времени
sudo docker logs -ft my_app_container
Мой типичный workflow при аварии:
- Сначала смотрю последние строки лога приложения:
tail -n 100 /path/to/app.log. - Если ошибка системная, проверяю
journalctlдля соответствующего сервиса. - Использую
-fдля отслеживания поведения после попытки рестарта. - Часто параллельно смотрю логи смежных сервисов (балансировщика, БД) для полной картины.
Ключевые флаги:
-n <число>— количество строк.-f— follow (режим реального времени).-u— фильтр по юниту systemd.--since— логи с определенного времени.
Ответ 18+ 🔞
Да ты посмотри, какой у меня тут стандартный набор команд на случай, когда всё накрывается медным тазом. Первым делом — в логи, конечно, чтобы понять, какого хуя случилось.
1. Основная команда tail:
# Посмотреть последние 50 строк лога приложения
sudo tail -n 50 /var/log/myapp/error.log
# Следить за логом в реальном времени (очень полезно при дебаге)
sudo tail -f /var/log/nginx/access.log
2. Просмотр логов systemd-сервисов через journalctl:
Это, ёпта, мой основной инструмент для сервисов, которые через systemd крутятся. Без него — нихуя не понятно.
# Логи конкретного сервиса за последние 5 минут
sudo journalctl -u php-fpm.service --since "5 minutes ago" --no-pager
# Последние 100 строк с подсветкой ошибок
sudo journalctl -u my-backend-service -n 100 -p err
# Логи с указанием временных меток в UTC
sudo journalctl -u nginx.service -n 50 --utc
3. Поиск по логам с grep:
# Найти все ошибки (ERROR, FATAL) в логе за сегодня
sudo grep -E "(ERROR|FATAL)" /var/log/myapp/app.log | tail -20
# Искать конкретную ошибку по trace-id
sudo journalctl -u app-service | grep "abc123-def"
4. Для контейнеризованных приложений (Docker):
# Логи конкретного контейнера
sudo docker logs --tail 100 my_app_container
# Логи с временными метками и в реальном времени
sudo docker logs -ft my_app_container
Мой типичный workflow при аварии:
- Сначала смотрю последние строки лога приложения:
tail -n 100 /path/to/app.log. Надо же понять, с чего эта пиздопроебибна началась. - Если ошибка системная, проверяю
journalctlдля соответствующего сервиса. Там часто вся подноготная видна. - Использую
-fдля отслеживания поведения после попытки рестарта. Сидишь, смотришь, как оно там, блядь, дышит или нет. - Часто параллельно смотрю логи смежных сервисов (балансировщика, БД) для полной картины. А то бывает, что один сервис — хитрая жопа, а виноватым оказывается соседний.
Ключевые флаги, без которых нихуя:
-n <число>— количество строк.-f— follow (режим реального времени).-u— фильтр по юниту systemd.--since— логи с определенного времени.