Анализ логов NGINX с помощью Elasticsearch, Logstash и Kibana

По данным последнего опроса на сайте Netcraft, проведенного в прошлом месяце, NGINX является вторым по распространенности веб-сервером (после Apache) среди миллиона самых загруженных сайтов по всему миру.

NGINX популярен из-за своего параллелизма, высокой производительности и низкого использования памяти. Он был просто создан сайтов с динамическим HTTP-контентом и используется для обработки запросов, кеширования и балансировки нагрузки.

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

Вы спросите а зачем это все нужно? Зачем нужно следить за логами?

Если внимательно за ними следить, то логи NGINX могут помочь вам найти проблемы как в самом сервере, так и в другой части вашей веб-инфраструктуры.

Эти очень крутые штуки помогут вам понять где и когда ваши сервера “падают”(если такое конечно имеет место быть). Кроме того, NGINX не забывает  создавать журналы доступа, а в них записывать количество активных клиентских подключений и общее количество клиентских запросов. Подробнее об этом вы можете прочитать здесь.

С помощью Elasticsearch, Logstash и Kibana этот огромный объем данных журнала можно собирать, анализировать и хранить. Ну а все эти данные затем могут быть преобразованы в идеи, которые помогут вам сделать так, чтобы пользователи могли получать немедленные уведомления и быстро находить и устранять основные проблемы.

Как анализировать логи NGINX с помощью Logstash

Ну сначала нам конечно нужно получить доступ к логам, и только потом начать применять кое-какие фильтры с помощью logstash.

Чуть ниже приведен пример строки журнала NGINX, а еще ниже пример конфигурации Logstash, которую мы и будем использовать для разбора этой строки в Logz.io.

Пример записи в журнале доступа NGINX:

109.65.122.142 – – [10/Nov/2015:07:06:59 +0000] “POST /kibana/elasticsearch/_msearch?timeout=30000&ignore_unavailable=true&preference=1447070343481 HTTP/1.1” 200 8352 “https://app.logz.io/kibana/index.html” “Mozilla/5.0 (X11; Linux armv7l) AppleWebKit/537.36 (KHTML, like Gecko) Ubuntu Chromium/45.0.2454.101 Chrome/45.0.2454.101 Safari/537.36” 0.465 0.454

Конфигурация Logstash для анализа этой записи журнала доступа NGINX:

grok {
match => [ “message” , “%{COMBINEDAPACHELOG}+%{GREEDYDATA:extra_fields}”]
overwrite => [ “message” ]
}
mutate {
convert => [“response”, “integer“]
convert => [“bytes”, “integer”]
convert => [“responsetime”, “float”]
}
geoip {
source => “clientip”
target => “geoip”
add_tag => [ “nginx-geoip” ]
}
date {
match => [ “timestamp” , “dd/MMM/YYYY:HH:mm:ss Z” ]
remove_field => [ “timestamp” ]
}
useragent {
source => “agent”
}

Пример лога ошибок(error_log) NGINX:

2015/11/10 06:49:59 [warn] 10#0: *557119 an upstream response is buffered to a temporary file /var/lib/nginx/proxy/4/80/0000003804 while reading upstream, client: 66.249.88.173, server: 0.0.0.0, request: “GET /kibana/index.js?_b=1273 HTTP/1.1”, upstream: “http://172.17.0.30:9000/kibana/index.js?_b=1273”, host: “app.logz.io”, referrer: “https://app.logz.io/kibana/index.html”

Конфигурация Logstash для анализа журнала ошибок NGINX:

 

grok {
match => [ “message” , “(?%{YEAR}[./-]%{MONTHNUM}[./-]%{MONTHDAY}[- ]%{TIME}) \[%{LOGLEVEL:severity}\] %{POSINT:pid}#%{NUMBER}: %{GREEDYDATA:errormessage}(?:, client: (?%{IP}|%{HOSTNAME}))(?:, server: %{IPORHOST:server})(?:, request: %{QS:request})?(?:, upstream: \”%{URI:upstream}\”)?(?:, host: %{QS:host})?(?:, referrer: \”%{URI:referrer}\”)”]
overwrite => [ “message” ]
}
geoip {
source => “client”
target => “geoip”
add_tag => [ “nginx-geoip” ]
}
date {
match => [ “timestamp” , “YYYY/MM/dd HH:mm:ss” ]
remove_field => [ “timestamp” ]
}

Эти две конфигурации в настоящий момент мы используем сами. И очень успешно. Но есть еще много полей в логах NGINX, которые можно  проанализировать и использовать  полученную информацию в своих целях.

Дальше я покажу вам как пользоваться ELK и извлекать из этого выгоду.

 

Анализ использования NGINX

Вариант использования №1: оперативный анализ

nginx operational analysis

Это один из наиболее частых вариантов использования. DevOps  инженеры и инженеры надежности сайта могут получать уведомления о событии когда трафик значительно выше обычного или частота ошибок NGINX превышает определенный уровень. В результате этих проблем скорость ответов на страницах сайта может снижаться до неприемлемых уровней и создавать неудобства для пользователей.

Используя управление журналами ELK для анализа журналов ошибок NGINX, можно быстро увидеть, например, значительное уменьшение числа пользователей, обращающимся к серверам, или беспрецедентный пик трафика, который перегружает сервер и приводит к сбою. Если например вы увидели все признаки  DDoS-атаки, то с помощью ELK Stack можете развернуть быстрый поиск подозрительного источника IP-адреса(который генерирует подозрительный трафик)  и заблокировать его.

Одним из наиболее полезных визуализаций и оповещений ELK Stack является количество строк логов записанных  в кэше. Если вы хотите узнать об этом больше, то читайте здесь.

Вариант использования №2: Технический SEO

nginx technical seo analysis

Создание качественного контента сейчас чрезвычайно важно , но в принципе бесполезно, если Google не сканирует, не анализирует и не индексирует контент. Отслеживание и мониторинг вашего журнала доступа NGINX при помощи ELK может предоставить вам последнюю дату сканирования Google, чтобы вы были уверены, что роботы Google вас не забыли.

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

Вариант использования №3: бизнес-аналитика

Анализ журналов доступа будет вам очень полезен, если вы хотите узнать какими приложениями пользуются ваши клиенты, их географическое положение и опыт, который они получают.  Преимущество использования ELK для мониторинга логов NGINX состоит в том, что вы можете связать их с логами уровня инфраструктуры. Так вы можете лучше понять опыт использования ваших сайтов аудиторией(тоесть все минусы и плюсы со стороны пользователей).

Например вы можете анализировать время отклика и коррелировать его с работой процессоров и нагрузкой памяти, чтобы увидеть могут ли более мощные машины обеспечить лучший UX(User Experience – опыт пользователя).

Визуализация логов NGINX

Как уже упоминалось выше, одно из самых больших преимуществ использования ELK Stack для анализа логов NGINX, является возможность визуализации этих самых анализов и корреляций. Kibana позволит вам создать подробные визуализации и информационные панели, которые помогут вам следить за NGINX и выявлять аномалии. Конфигурировать и создавать эти визуализации не всегда легко, но оно того стоит ).

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

Чтобы помочь вам начать работу, мы предоставляем бесплатную библиотеку уже готовых поисков, визуализаций и информационных панелей для NGINX – ELK Apps.

Библиотека включает в себя 11 визуализаций для формата логов NGINX, включая полную панель мониторинга в режиме реального времени.

NGINX monitoring dashboard

Анализ логов NGINX  для последующего оперативного анализа, бизнес-аналитики и  и технического SEO – это всего лишь три примера того, почему пользователи NGINX должны отслеживать логи.  Существует много других вариантов использования, например  разработка журналов и мониторинг приложений.

Пишите в комментариях как вы используете ELK  для  анализа лог-файлов NGINX.