Вы используете Nginx? А как у вас организован мониторинг логов Nginx?

Знаете ли вы, что мониторя логи nginx, вы можете значительно повысить стабильность и надежность своего веб-приложения?

В этой статье я покажу вам, как организовать мониторинг логов Nginx, использовать их в качестве метрик и что вообще можно из них выжать.

Зачем мониторить логи Nginx?

Чтобы обеспечить доступность нашей системы — Система считается доступной при отсутствии сбоев или когда количество сбоев не превышает определенный порог. Анализируя статус-коды HTTP, мы можем определить допустимый процент сбоев и следить за доступностью нашей системы.

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

Чтобы своевременно удалять устаревшие конечные точки  — В идеале мы бы хотели сразу удалять устаревшие конечные точки. Но мы не можем просто взять и сделать это, так как некоторые из наших клиентов могут еще использовать их. Мы могли бы проанализировать использование интересующих нас конечных точек, просмотрев историю, и принимать решение об их удалении, опираясь на реальные данные.

Базовый рабочий процесс

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

1. Мы собираем метрики Nginx с помощью модуля filebeat [1].

2. Filebeat публикует собранные метрики в elasticsearch.

3. Мы можем визуализировать собранные метрики с помощью Kibana.

4. Мы можем информировать нашу команду с помощью наблюдателей (watchers) [2].

Реализация решения

Весь код можно найти здесь: monitor-nginx-logs

Сбор метрик Nginx

Мы собираем метрики Nginx, используя следующий код:

filebeat.modules:  
- module: nginx  
  access:  
    var.paths: ["/var/log/nginx/host.access.log"]

Метрики публикуются в elasticsearch с помощью следующего кода:

output.elasticsearch:  
  hosts: ["http://elasticsearch:9200"]

Вы можете просмотреть собранные метрики, используя Discover в Kibana по адресу localhost:5601. http.response.status_code — интересующая вас метрика.

Визуализация статус-кодов HTTP в Kibana

Выберите Visualize Library и создайте визуализацию

Выберите TSVB.

Сгруппируйте статус-коды HTTP, как показано на следующей диаграмме.

Сразу приношу свои извинения за слабую читабельность текста на изображении. Я попытался увеличить масштаб, но он все равно не читался. Поэтому я выпишу текст ниже:

Часть слева: http.response.status_code>= 200 and http.response.status_code<= 299

Часть справа: 200

По аналогии прописываем это для всех остальных статус-кодов

Наконец, мы можем посмотреть красивую инфографику со статус-кодами HTTP за все время.

Информирование команды о неудачных запросах

Информирование нашей команды мы можем реализовать с помощью специального API наблюдателя [3]. Наблюдатель будет регулярно извлекать данные через определенные промежутки времени и информировать нашу команду, если будет выполняться заданное нами условие. Своевременное получение уведомлений позволит нашей команде действовать наиболее эффективным образом.

Предположим, мы хотим запускать наблюдателя каждый час:

"trigger": {  
  "schedule": {  
    "interval": "1h"  
  }  
}

Так как мы храним метрики в индексе filebeat:

"indices": [  
  "<filebeat-*-{now/d}>"  
]

мы можем определить неудачные запросы, используя следующую конфигурацию:

{
 "size": 0,
 "query": {
  "bool": {
   "must": [
    {
     "range": {
      "@timestamp": {
       "gte": "now-1h"
      }
     }
    },
    {
     "exists": {
      "field": "http.response.status_code"
     }
    }
   ]
  }
 },
 "aggs": {
  "response_code_ranges": {
   "range": {
    "field": "http.response.status_code",
    "keyed": true,
    "ranges": [
     {
      "key": "server_errors",
      "from": 500,
      "to": 599
     }
    ]
   }
  }
 }
}

Следующее условие триггерит наш наблюдатель и сообщит нашей команде, когда процент неудачных запросов превысит 0,3%. Вы можете настроить этот порог в соответствии с вашими соображениями:

"condition": {  
  "script": {  
    "source": "(double) ctx.payload.aggregations.response_code_ranges.buckets.server_errors.doc_count/(double) ctx.payload.hits.total > params.threshold",  
    "lang": "painless",  
    "params": {  
      "threshold": 0.003  
    }  
  }  
}

Мы можем информировать команду через slack:

-- copied from https://www.elastic.co/guide/en/elasticsearch/reference/7.17/actions-slack.html

"actions" : {  
  "notify-slack" : {  
    "transform" : { ... },  
    "throttle_period" : "5m",  
    "slack" : {  
      "message" : {  
        "to" : [ "#admins", "@chief-admin" ],   
        "text" : "..."   
      }  
    }  
  }  
}

Спасибо за внимание.

Ресурсы:

[1] filebeat-module-nginx.html
[2] watcher-ui.html
[3] watcher-api-put-watch.html

Материал подготовлен в преддверии старта курса «Observability: мониторинг, логирование, трейсинг». Ознакомиться подробнее с программой обучения и пройти вступительный тест для определения уровня знаний можно по ссылке.