На nginx есть 3 location'а (cash, static, backend). Пишутся логи в access log. Как по логам понять, каким образом мы дали пользователю тот или иной контент (из какого location)

Анализ location'ов Nginx через access логи

Чтобы определить, из какого location (cash, static или backend) был отдан контент пользователю, необходимо анализировать access логи Nginx с учётом структуры конфигурации и дополнительных меток. Вот основные подходы:

1. Добавление кастомных переменных в логи

Самый надёжный способ — модифицировать конфигурацию Nginx, добавив в формат лога переменную, которая указывает на обработанный location. Например, в каждом location можно установить переменную $location_name и включить её в log_format.

Пример конфигурации Nginx:

http {
    log_format main '$remote_addr - $remote_user [$time_local] "$request" '
                    '$status $body_bytes_sent "$http_referer" '
                    '"$http_user_agent" "$location_name"';

    server {
        listen 80;
        server_name example.com;

        set $location_name "default";

        location /cash {
            set $location_name "cash";
            # Конфигурация кэша...
            access_log /var/log/nginx/access.log main;
        }

        location /static {
            set $location_name "static";
            # Конфигурация статики...
            access_log /var/log/nginx/access.log main;
        }

        location /backend {
            set $location_name "backend";
            # Конфигурация бэкенда...
            access_log /var/log/nginx/access.log main;
        }
    }
}

В логах появится последнее поле с именем location, например: "cash".

2. Анализ по URI и шаблонам путей

Если модификация конфигурации невозможна, можно анализировать логи, сопоставляя URI запросов с шаблонами location. Например, используя grep или awk:

# Пример анализа логов за последний час
cat /var/log/nginx/access.log | grep "$(date -d '1 hour ago' '+%d/%b/%Y:%H')" | awk '
{
    if ($7 ~ /^\/cash/) print "cash: " $0;
    else if ($7 ~ /^\/static/) print "static: " $0;
    else if ($7 ~ /^\/backend/) print "backend: " $0;
    else print "other: " $0;
}'

Здесь $7 — это URI запроса (поле может отличаться в зависимости от log_format).

3. Использование upstream или proxy меток

Если location backend проксирует запросы на upstream-серверы, можно добавить в логи переменную $upstream_addr или $proxy_host, чтобы отличать их от статики и кэша.

Пример log_format с upstream:

log_format detailed '$remote_addr - $location_name - $upstream_addr';

Для static и cash location'ов $upstream_addr будет пустым, а для backend — содержать адрес бэкенда.

4. Инструменты для анализа логов

Для автоматизации анализа используйте:

• GoAccess — инструмент реального времени с поддержкой группировки по URI.
• ELK Stack (Elasticsearch, Logstash, Kibana) — для сложных запросов и визуализации.
• Grafana + Loki — лёгкое решение для мониторинга и фильтрации логов.

Пример запроса в Kibana для фильтрации по location:

{
  "query": {
    "bool": {
      "should": [
        { "match": { "uri.keyword": "/cash/*" } },
        { "match": { "uri.keyword": "/static/*" } },
        { "match": { "uri.keyword": "/backend/*" } }
      ]
    }
  }
}

5. Рекомендации по внедрению

• Единый log_format: Используйте единый формат логов во всех location для упрощения анализа.
• Мониторинг: Настройте алерты на аномалии (например, рост ошибок 5xx в backend).
• Документация: Документируйте mapping между URI и location для команды.

Таким образом, оптимальный подход — модификация log_format с добавлением переменной location. Это даст точные данные без необходимости постобработки. Если изменения в конфигурации невозможны, используйте анализ URI через скрипты или инструменты вроде GoAccess.