Практический анализ логов Nginx и Apache: готовые команды grep, awk для поиска ошибок и атак

Логи веб-серверов - это не просто архив запросов, а детальная карта состояния вашего сервиса. Они содержат ответы на вопросы о причинах ошибок, источниках тормозов и признаках атак. В этом руководстве вы получите готовые команды для немедленного анализа, научитесь читать ключевые поля и настраивать автоматический мониторинг в Grafana. Инструкции проверены на практике для Nginx и Apache и помогут быстро диагностировать проблемы в production-среде.

С чего начать: понимание структуры логов Nginx и Apache

Эффективный анализ начинается с понимания, какая информация хранится в логах и как к ней обращаться. Формат Combined Log Format - это стандарт, который предоставляет максимум данных для диагностики.

Формат Combined Log Format: что скрывается в каждой колонке

Рассмотрим типичную строку лога Nginx в этом формате:

192.168.1.100 - - [21/Apr/2026:14:32:15 +0300] "GET /api/v1/user/profile HTTP/1.1" 200 2451 "https://example.com/dashboard" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36" 0.156

Каждое поле имеет конкретное значение:

• 192.168.1.100: IP-адрес клиента.
• - -: Идентификатор удаленного пользователя и аутентифицированного пользователя (часто не используется, обозначается дефисом).
• [21/Apr/2026:14:32:15 +0300]: Точная дата и время запроса с часовым поясом.
• "GET /api/v1/user/profile HTTP/1.1": Метод HTTP, URI запроса и версия протокола.
• 200: Код состояния HTTP ответа. 200 - успех, 4xx - ошибка клиента, 5xx - ошибка сервера.
• 2451: Размер тела ответа в байтах, переданный клиенту.
• "https://example.com/dashboard": Заголовок Referer - страница, с которой пришел пользователь.
• "Mozilla/5.0...": Заголовок User-Agent, идентифицирующий браузер, бота или клиентское приложение.
• 0.156: Время обработки запроса в секундах (в Nginx - $request_time, в Apache - %D). Критически важно для анализа производительности.

В Apache аналогичная строка в формате Combined будет выглядеть так: LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" combined. Поле времени ответа %D добавляется отдельно.

Ключевые поля для разных задач: ошибки, производительность, безопасность

В зависимости от цели анализа фокусируйтесь на конкретных полях:

Эта таблица - шпаргалка для первоначальной фокусировки. Например, при жалобах на медленную работу сразу анализируйте $request_time.

Готовый набор команд для быстрого анализа (grep, awk, sed)

Следующие команды выполняются в терминале на сервере, где расположены логи. Путь к файлу лога замените на свой, например, /var/log/nginx/access.log или /var/log/apache2/access.log. Для анализа ротированных логов используйте zcat или gunzip -c.

Поиск ошибок сервера: 5xx, 4xx и проблемные URI

Чтобы быстро найти причины сбоев, выполните эти команды.

1. Все ошибки 5xx за последний час:
grep "$(date -d '1 hour ago' '+%d/%b/%Y:%H')" /var/log/nginx/access.log | grep -E ' 5[0-9]{2} '
Эта команда ищет строки за последний час (по формату даты в логе) с кодом состояния, начинающимся на 5.

2. ТОП-10 самых частых ошибок 404 с URI, на которых они возникают:
awk '$9 == 404 {print $7}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -10
Здесь $9 - поле статус-кода, $7 - URI. Команда подсчитывает и сортирует по убыванию частоты.

3. Все ошибки 500 за конкретную дату:
grep '21/Apr/2026' /var/log/nginx/access.log | grep ' 500 '

Результат покажет, какие endpoint'ы вызывают внутренние сбои приложения. Для комплексной диагностики производительности сервера, когда ошибки связаны с нехваткой ресурсов, используйте готовый алгоритм диагностики узких мест в Linux.

Выявление медленных запросов, тормозящих ваш сервис

Запросы с большим временем отклика создают очередь и ухудшают опыт пользователей.

1. Запросы, обрабатывавшиеся дольше 2 секунд (адаптируйте порог):
awk -F'"' '$(NF-1) > 2' /var/log/nginx/access.log
В этом примере $(NF-1) обращается к предпоследнему полю строки (разделенной по кавычкам), где в Combined формате хранится $request_time.

2. ТОП-10 самых медленных запросов с URI и временем:
awk '{print $(NF-1), $7}' /var/log/nginx/access.log | sort -rn | head -10

3. Анализ времени ответа от бэкенда (upstream_response_time) в Nginx:
Для этого поле $upstream_response_time должно быть добавлено в log_format. Команда для поиска медленных ответов бэкенда:
grep '"upstream_response_time:[0-9]*\.[0-9][0-9][0-9]' /var/log/nginx/access.log

Медленный статичный файл (например, .css) указывает на проблемы с диском или сетью. Медленный API-вызов (например, /api/report) - на проблему в коде приложения или базе данных.

Базовый анализ трафика: самые активные IP и запрашиваемые файлы

Этот срез помогает понять характер нагрузки.

1. ТОП-10 IP-адресов по количеству запросов:
awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -10
Один IP с аномально высоким числом запросов (например, 10 000 за минуту) может быть ботом или источником атаки.

2. ТОП-10 самых запрашиваемых URL:
awk '{print $7}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -10

3. Подсчет уникальных посетителей (по IP) за сегодня:
grep $(date '+%d/%b/%Y') /var/log/nginx/access.log | awk '{print $1}' | sort -u | wc -l

Эти команды - основа для ручного анализа. Для автоматизации и построения полной картины состояния инфраструктуры ознакомьтесь с практическим руководством по администрированию Linux, где разобраны инструменты мониторинга и автоматизации.

Как обнаружить ботов, сканирование и признаки атак в логах

Автоматизированные сканеры и злоумышленники оставляют характерные следы. Умение их читать позволяет реагировать до нанесения ущерба.

Паттерны сканирования уязвимостей: запросы к wp-admin, phpmyadmin и shell

Сканеры автоматически проверяют тысячи путей на наличие известных уязвимостей.

Поиск попыток сканирования административных панелей:
grep -E '(wp-admin|phpmyadmin|admin/config|/administrator/|/backend/)' /var/log/nginx/access.log | awk '{print $1, $7}'

Поиск запросов к потенциально опасным файлам:
grep -E '(\.env|config\.php|backup\.zip|\.git/|/shell\.php)' /var/log/nginx/access.log

Интерпретация: десятки или сотни 404 ошибок на такие пути с разных IP за короткий промежуток - явный признак автоматического сканирования. Единичный запрос может быть случайностью.

Признаки подбора паролей (Brute Force) и SQL-инъекций

Атаки на логику приложения требуют более внимательного анализа содержимого запросов.

Выявление подбора паролей к endpoint'ам авторизации:
grep 'POST /login' /var/log/nginx/access.log | awk '$9 == 401 || $9 == 403 {print $1, $7}' | uniq -c | sort -rn
Множество POST-запросов к /login или /api/auth с возвратом 401/403 с одного IP указывает на брутфорс.

Поиск потенциальных SQL-инъекций в URI:
grep -E "('|--|UNION|SELECT|INSERT|UPDATE|DELETE)" /var/log/nginx/access.log | grep -v '"Mozilla'
Эта команда ищет SQL-метасимволы и ключевые слова. Фильтр grep -v '"Mozilla' исключает строки с нормальными User-Agent для уменьшения шума, но требует осторожности.

Поток таких запросов - сигнал к немедленной проверке. Для глубокой диагностики и оптимизации проблемного веб-приложения, которое может быть целью атак, используйте пошаговый гайд по диагностике и оптимизации.

Выявление аномалий трафика: первые сигналы DDoS и ботнета

Атаки на доступность часто начинаются с резкого роста определенных метрик.

1. Подсчет запросов в секунду с одного IP (за последние 5 минут):
grep $(date -d '5 min ago' '+%d/%b/%Y:%H:%M') /var/log/nginx/access.log | awk '{print $1}' | sort | uniq -c | sort -rn | head -5
Если один IP показывает >100 запросов/сек, это повод для детального изучения.

2. Мониторинг общего количества 404 ошибок в минуту:
grep $(date '+%d/%b/%Y:%H:%M') /var/log/nginx/access.log | awk '$9 == 404' | wc -l
Резкий всплеск 404 (в 10-100 раз выше базового уровня) может быть признаком сканирования или DDoS, нацеленного на исчерпание ресурсов.

3. Анализ трафика по размеру ответа:
awk '{sum+=$10} END {print sum/1024/1024, "MB transmitted in last hour"}' /var/log/nginx/access.log
Неожиданный рост исходящего трафика может указывать на утечку данных или атаку с большими ответами.

Эвристика: сравнивайте текущие значения с историческим базовым уровнем для вашего сервиса. Для планирования нагрузочного тестирования и понимания пределов вашей системы перед потенциальной атакой используйте практическое руководство по нагрузочному тестированию.

Настройка дашборда в Grafana для постоянного мониторинга

Ручной анализ не масштабируется. Стек Grafana + Loki позволяет визуализировать логи в реальном времени.

Быстрый старт: сбор логов в Loki и настройка Promtail

Loki - это система агрегации логов, Promtail - агент для их сбора и отправки.

Базовая конфигурация в docker-compose.yml:

version: '3'
services:
  loki:
    image: grafana/loki:latest
    ports:
      - "3100:3100"
    command: -config.file=/etc/loki/local-config.yaml

  promtail:
    image: grafana/promtail:latest
    volumes:
      - /var/log/nginx:/var/log/nginx:ro
      - ./promtail-config.yaml:/etc/promtail/config.yaml
    command: -config.file=/etc/promtail/config.yaml

  grafana:
    image: grafana/grafana:latest
    ports:
      - "3000:3000"
    environment:
      - GF_SECURITY_ADMIN_PASSWORD=admin

Конфигурация Promtail (promtail-config.yaml):

server:
  http_listen_port: 9080
  grpc_listen_port: 0

positions:
  filename: /tmp/positions.yaml

clients:
  - url: http://loki:3100/loki/api/v1/push

scrape_configs:
- job_name: nginx
  static_configs:
  - targets:
      - localhost
    labels:
      job: nginx
      __path__: /var/log/nginx/access.log

Запустите стек: docker-compose up -d. Войдите в Grafana (http://localhost:3000, логин admin, пароль admin), добавьте Loki как источник данных (URL http://loki:3100).

Создание панелей для ключевых метрик: ошибки, время ответа, угрозы

Используйте язык запросов LogQL для создания панелей.

1. График ошибок 5xx и 4xx в реальном времени:
Запрос: sum by (status_code) (rate({job="nginx"} | pattern ` - - <_> \"<_>\" <_> <_> <_> <_>` | status >= 400 [5m]))
Этот запрос использует парсер pattern для структурирования логов и рассчитывает rate (скорость) ошибок за 5-минутные интервалы.

2. Гистограмма 95-го перцентиля времени ответа (p95):
Запрос: quantile_over_time(0.95, {job="nginx"} | pattern ` - - <_> \"<_>\" <_> <_> <_> ` | response_time > 0 | unwrap response_time [5m])

3. ТОП IP-адресов по количеству запросов за последний час:
Запрос для таблицы: topk(10, sum by (ip) (rate({job="nginx"} | pattern ` - - <_> \"<_>\" <_> <_> <_> <_> <_>` [1h])))

4. Счетчик запросов с подозрительными User-Agent:
Запрос: count_over_time({job="nginx"} |~ "(scanner|bot|curl|python-requests|nikto|sqlmap)" [1h])

Соберите эти панели на одном дашборде. Это даст единую точку контроля за здоровьем и безопасностью веб-сервиса.

Чек-лист действий и предостережения

План действий для системного администратора или DevOps инженера:

1. Экстренный анализ: При поступлении жалоб используйте команды из раздела «Поиск ошибок сервера» для быстрого поиска 5xx и частых 4xx ошибок.
2. Плановый аудит производительности: Раз в неделю выполняйте команды для выявления медленных запросов и анализируйте ТОП IP-адресов.
3. Проверка безопасности: Ежедневно или в режиме реального времени через Grafana мониторьте запросы к подозрительным URI и аномальную активность с отдельных IP.
4. Автоматизация: Настройте дашборд Grafana с ключевыми метриками и добавьте алерты на пороговые значения (например, >10 ошибок 500 в минуту).
5. Документирование: Ведите журнал обнаруженных инцидентов и эффективных запросов для анализа - это ускорит реакцию в будущем.

Важно помнить:

• Контекст: Не все сканеры - злоумышленники. Легитимные боты поисковых систем (Googlebot, Yandex) также активно сканируют сайты. Анализируйте частоту и агрессивность.
• Адаптация: Команды grep и awk могут требовать корректировки под ваш точный формат лога (порядок полей, разделители). Всегда проверяйте их на тестовом файле.
• Версии ПО: Синтаксис конфигурации и доступные переменные логов могут отличаться между версиями Nginx (1.18, 1.20) и Apache (2.4, 2.5). Сверяйтесь с официальной документацией.
• Ротация логов: Убедитесь, что анализируете актуальный файл лога. Учитывайте ротацию (например, access.log.1.gz). Используйте zcat для работы со сжатыми архивами.
• Производительность: Анализ больших логов (гигабайты) командами sort и uniq может потребовать значительных ресурсов CPU и памяти. Выполняйте такие задачи в период низкой нагрузки или на выделенной машине для анализа.

Регулярный и осмысленный анализ логов - это не рутина, а ключевой навык, который напрямую влияет на стабильность, производительность и безопасность вашего сервиса. Начните с выполнения нескольких готовых команд из этой статьи, чтобы увидеть ценность данных, которые уже есть в вашем распоряжении.