Как рассчитать SLA на примере Nginx-сервера

Соглашение об уровне обслуживания (SLA) – это соглашение с клиентами или пользователями, где описывается уровень обслуживания, который поставщик обещает предоставить клиенту. SLA можно представить в виде измеряемой метрики, например, как время безотказной работы или суммарное количество ошибок. Перевели статью, где рассматривается простой способ расчета SLA на примере Nginx-сервера.

SLA по времени доступности

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

Например, веб-приложение с доступностью 99,95% может не работать максимум 4,38 часа в год.

В следующей таблице приведена максимальная продолжительность допустимого времени простоя в год/месяц/неделю/день/час.

SLA по количеству ошибок

Представим себе Backend с API, обслуживающий 250 млн. запросов в день, и SLA по количеству ошибок 99,99%, который не может превышать 25 тыс. ошибок в день.

Обратите внимание, что засчитываются только внутренние ошибки сервера HTTP 5XX.

Что такое SLO?

SLO, или Service-Level Objective — это соглашение SLA, определяющее ожидания и цели, которых компания должна достичь в течение определенного периода времени.

Пример:

Представьте себе компанию, у которой текущее SLA по времени безотказной работы составляет 95%, что означает, что она допускает максимум 1,5 дня простоя в месяц, что очень плохо.

Определим наши цели таким образом, чтобы SLA соответствовал 99%. Для этого мы должны предпринять несколько действий, вот некоторые примеры:

• Пересмотреть аппаратную инфраструктуру

• Добавить профилактический мониторинг

• Поиск основных причин простоев

• Проанализировать конфигурацию сети

• Проверка на наличие единой точки отказа

Рассчитаем SLA на основе логов веб-сервера

В этом примере мы будем собирать логи Nginx и отправлять их в Elasticsearch, чтобы затем визуализировать их в Kibana для создания панели SLA дашборда.

Почему именно Vector в качестве сборщика логов? Потому что это легкий и сверхбыстрый инструмент для построения конвейеров наблюдаемости, в которых мы будем собирать, преобразовывать и направлять логи Nginx в Elasticsearch.

Шаг 1: Настройте Nginx для получения более подробных логов.

Отредактируйте файл /etc/nginx/nginx.confg в http и блоке добавьте следующее :

log_format apm '"$time_local" client=$remote_addr '
               'method=$request_method request="$request" '
               'request_length=$request_length '
               'status=$status bytes_sent=$bytes_sent '
               'body_bytes_sent=$body_bytes_sent '
               'referer=$http_referer '
               'user_agent="$http_user_agent" '
               'upstream_addr=$upstream_addr '
               'upstream_status=$upstream_status '
               'request_time=$request_time '
               'upstream_response_time=$upstream_response_time '
               'upstream_connect_time=$upstream_connect_time '
               'upstream_header_time=$upstream_header_time';

В определении сервера Nginx отредактируйте конфигурацию логов следующим образом:

server {
		....
        access_log /var/log/nginx/access.log apm;
        error_log /var/log/nginx/error.log;
		....
}

Шаг 2: Установите Vector для сбора, анализа и отправки логов Nginx.

curl --proto '=https' --tlsv1.2 -sSf https://sh.vector.dev | bash

Дополнительную документацию по установке можно найти здесь.

Использование VRL (Vector Remap Langage) для разбора логов Nginx:

[sources.nginx_source]
type = "file"
ignore_older_secs = 600
include = [ "/var/log/nginx/error.log" ]
read_from = "beginning"
max_line_bytes = 102_400
max_read_bytes = 2_048
[transforms.modify_logs]
type = "remap"
inputs = ["nginx_source"]
#parse each line with VRL regex
source = """
. = parse_regex!(.message, r'^\"(?P<timestamp>.*)\" client=(?P<client>.*) method=(?P<method>.*) request=\"(?P<method_type>.*) (?P<request_path>.*) (?P<http_version>.*)\" request_length=(?P<request_length>.*) status=(?P<status>.*) bytes_sent=(?P<bytes_sent>.*) body_bytes_sent=(?P<body_bytes_sent>.*) referer=(?P<referer>.*) user_agent=\"(?P<user_agent>.*)\" upstream_addr=(?P<upstream_addr>.*) upstream_status=(?P<upstream_status>.*) request_time=(?P<request_time>.*) upstream_response_time=(?P<upstream_response_time>.*) upstream_connect_time=(?P<upstream_connect_time>.*) upstream_header_time=(?P<upstream_header_time>.*)$')
#covnert metrics to proper types
.timestamp = to_timestamp!(.timestamp)
.request_length = to_int!(.request_length)
.status = to_int!(.status)
.bytes_sent = to_int!(.bytes_sent)
.body_bytes_sent = to_int!(.body_bytes_sent)
.upstream_status = to_int!(.upstream_status)
.request_time = to_float!(.request_time)
.upstream_response_time = to_float!(.upstream_response_time)
.upstream_connect_time = to_float!(.upstream_connect_time)
.upstream_header_time = to_float!(.upstream_header_time)
.host = "YOUR_HOSTNAME_HERE"
"""
#for debug mode only - output to console
#[sinks.debug_sink]
#type = "console"
#inputs = ["modify_logs"]
#target = "stdout"
#encoding = "json"
#OUPUT 1 : Elasticsearch
[sinks.send_to_elastic]
type = "elasticsearch"
inputs = [ "modify" ]
endpoint = "https://elasticsearch-endpoint.com"
index = "websitelogs-%F"
mode = "bulk"
auth.user="xxxxxxxxxxxxxxxxxxxxxxx"
auth.password="xxxxxxxxxxxxxxxxxxx"
auth.strategy="basic"
systemctl restart vector.service

Посмотрите логи работы блока vector systemd :

journalctl -u vector.service

Он должен выглядеть следующим образом:

Для демонстрационных целей я развернул экземпляр Elasticsearch в Elastic cloud.

Определите текущий SLA перед определением SLO

В Kibana нам необходимо создать Index Pattern для чтения из индексов Elasticsearch.

Примечание: Временную метку нужно брать из логов, а не из Time of Ingest (по умолчанию в Elasticsearch).

Наши логи успешно отправляются в Elasticsearch, поэтому следующим шагом будет создание дашборда в Kibana с некоторыми графиками для расчета нашего текущего SLA.

Давайте откроем логи:

Похоже, что за последние 15 минут мы получили около 8300. И каждый hit log хорошо подготовлен и выглядит следующим образом:

Создадим счетчик Hits:

Рассчитаем количество ошибок

В формуле выше мы определили, что учитываем только 5XX. Остальные коды состояния будем считать успешными (4XX считаются поведением клиента).

Таким образом, наш SLA, основанный на агрегированных данных за последние 15 минут, составляет 87,04%, а за последние 30 дней — 98,56%:

Такой разрыв в разнице между последними 15 минутами и последними 30 днями говорит, что происходит инцидент.

Наша дашборд начнет выглядеть следующим образом:

Использование метрик вместо логов

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

Здесь мы использовали логи Nginx и Elasticsearch в качестве базы данных хранилища документов.

Однако для повышения производительности и получения информационных панелей в реальном времени я настоятельно рекомендую использовать метрики вместо логов.

Для этого мы можем использовать базы данных временных рядов, такие как InfluxDB или Warp10, для хранения метрик и использовать Grafana в качестве инструмента визуализации.

На векторе настроим выходной сток на InfluxDB, добавив следующий блок:

#OUPUT 2 : InfluxDB Database
[sinks.influxdb_output]
type = "influxdb_logs"
inputs = [ "modify_logs" ]
bucket = "vector-bucket"
consistency = "any"
database = "xxxxxxxxxxx"
endpoint = "https://your-endpoint.com"
password = "your-password-here"
username = "username"
batch.max_events=1000
batch.timeout_secs=60
namespace = "service"

Затем перезапустим Vector.

Заключение

Итак, мы разобрали, что такое SLA и SLO и как можно рассчитать SLA по количеству ошибок из логов Nginx.

Если вы хотите научиться разбираться в метриках, правильно собирать их и использовать, приходите в Слёрм на курс «SRE: data-driven подход к управлению надежностью систем».

На курсе вы получите представление о задачах специалиста по SRE в компании, изучите практики повышения надежности и сможете:

• Настроить мониторинг SRE-метрик (SLO, SLI, error budget) для своего сервиса.

• Настроить мониторинг SRE-инфраструктурных сервисов. Научитесь опознавать и решать проблемы с инфраструктурой.

• Настроите alerting и healthcheck.

• Освоите разные методы деплоймента.

Ознакомиться с программой и записаться на курс можно на нашем сайте.