Как отслеживать SLO/ErrorBudget вашего продукта: Простой инструмент для отслеживания вещей!

Сегодня большая часть организации отслеживает свои продукты SLO, чтобы не нести ответственность за нарушение SLA (соглашения об уровне обслуживания). В случае любого нарушения SLO они будут обязаны заплатить что -то в обмен на нарушение договора. Как только SLO для их продукта будет определен, соответствующий бюджет ошибок будет рассчитан на основе этого числа. Например, если 99,99% — SLO, то бюджет ошибок составит 52,56 мин в год. Это количество простоя, которое продукт может иметь через год без нарушения SLO.

Как только компании согласятся с SLO, им необходимо выбрать наиболее соответствующие SLI (показатели уровня обслуживания). Любое нарушение этих SLI будет рассматриваться как простоя, а продолжительность простоя будет вычтена из бюджета ошибок. Например, продукт платежного шлюза может иметь следующие SLI.

Задержка на P95 для запросов
Errorrates
Платежные сбои и т. Д.

Дополнительное чтение:

https://sre.google/workbook/implementing-slos/ https://sre.google/workbook/error-budget-policy/

Почему многим компаниям сложно отслеживать бюджеты ошибок в настоящее время?

Обычно организации используют сочетание инструментов для мониторинга/отслеживания этих SLI (например, EG: связанные с задержкой SLI, как правило, отслеживается в APM, таких как Newrelic, в то время как другие SLI отслеживают в инструментах мониторинга, таких как Prometheus/Datadog и т. Д.). Это затрудняет отслеживание бюджета ошибок в одном централизованном месте.

Иногда компании имеют очень низкий период хранения (<6 месяцев) для своих метрик в Прометее. Сохранение показателей в течение более длительного периода может потребовать настройки Thanos/Cortex, правил федерации и планирования мощности для хранения метрик.

Затем возникает проблема ложных срабатываний — даже если вы отслеживаете что -то в Prometheus, трудно пометить событие как ложное положительное, когда инцидент не является подлинным нарушением SLO. Создание эффективной и проверенной на боевой мониторинге требуется время. Первоначально команды могут в конечном итоге получить много ложных срабатываний. И вы можете отметить некоторые старые нарушения как ложные позитивы, чтобы вернуть минуты в свой бюджет ошибок

Что делает SLO Tracker?

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

Пользователи сначала должны настроить свой целевой SLO и бюджет ошибок будет выделен на основе этого.
В настоящее время он поддерживает интеграцию Webhook с небольшим количеством инструментов мониторинга (Prometheus, Pingdom и Newrelic), и всякий раз, когда он получает инцидент из этих инструментов, это уменьшит некоторые ошибки.
Если нарушение не попадает в ваш инструмент мониторинга или если этот инструмент не имеет интеграции с вашим инструментом мониторинга, то инцидент можно сообщить вручную через пользовательский интерфейс.
Обеспечивает некоторую аналитику в распределении нарушения SLO. (График распределения SLI)
Этот инструмент не требует большого места для хранения, поскольку он только хранит нарушения, но не каждый показатель.

Как это настроить?

Клон репо
Repo уже имеет докеров, так что просто запустите Docker -Compose -u -d и ваша установка сделана!
Кредит по умолчанию Админ: администратор . Это можно изменить в Docker-Compose.yaml Анкет
Теперь установите некоторую цель SLO в пользовательском интерфейсе.
Чтобы интегрировать этот инструмент с другими инструментами мониторинга, вы можете использовать следующие URL -адреса Webhook.
- Для Prometheus: Serverip: 8080/webhook/prometheus
- Для новости: serverip: 8080/webhook/newrelic
- Для Pingdom: Serverip: 8080/Webhook/Pingdomd
Теперь установите правила для мониторинга SLI в вашем инструменте мониторинга (давайте посмотрим, как это можно сделать в Prometheus). Правило менеджера оповещения о мониторинге примера SLI ==> Nginx P99 задержка

  - alert: NginxLatencyHigh
    expr: histogram_quantile(0.99, sum(rate(nginx_http_request_duration_seconds_bucket[2m])) by (host, node)) > 3
    for: 2m
    labels:
      severity: critical
    annotations:
      summary: Nginx latency high (instance )
      description: Nginx p99 latency is higher than 3 seconds\n  VALUE = \n  LABELS:

Предупреждение маршрутизации на основе тегов, установленных в чеках

          global:
            resolve_timeout: 10m
          route:
            routes:
            - receiver: blackhole
            - receiver: slo-tracker
              group_wait: 10s
              match_re:
                severity: critical
              continue: true
          receivers:
          - name: 'slo-tracker'
            webhook_config: 
              url: 
'http://ENTERIP:8080/webhook/prometheus'
              send_resolved: true

Добавьте разные теги, если вы не хотите маршрутизировать запросы на основе тегов серьезности.

Что дальше:

Добавить еще несколько интеграции инструмента мониторинга
Отслеживание нескольких продуктов SLO
Добавить больше графиков для аналитики
Лучшие инструменты визуализации для определения проблемных услуг

Этот проект с открытым исходным кодом. Не стесняйтесь открывать проблему PR или поднять проблему:)

Если вы хотите увидеть приборную панель, пожалуйста, проверьте это вне! ( admin: admin это кредиты. Также, пожалуйста, используйте ноутбук, чтобы открыть это веб -приложение. Это еще не мобильное дружеское)

Оригинал: «https://dev.to/roshan8/how-to-track-your-product-slo-errorbudget-5a4a»