Операционный мониторинг: подходы и инструменты

Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті.

Меня зовут Анна Каплун, я Test Engineering Lead в Intellias. В этой статье мы рассмотрим типичные инструменты для операционного мониторинга, примеры их настройки для отправки уведомлений и сравнение установки таких систем локально, либо использования готовых облачных решений.

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

В двух словах — это регулярная проверка доступности сервисов и уведомлений в случае каких-либо проблем. Но это не единственное возможное преимущество операционного мониторинга. С помощью инструментов, которые проверяют состояние сервис-компонентов проекта, можно собрать много интересной статистики. Конечно, для того, чтобы это стало возможным, такая информация должна содержаться в сообщениях, которые отправляются системой. Если речь идет о веб-приложениях, то типичным решением является добавление информации в параметр заголовка User-Agent (например, версии приложения, благодаря чему можно оценить, какая версия самая популярная среди пользователей). Можно изучить тенденции нагрузки на систему, типичные запросы и т.д. Кроме мониторинга собственно приложения, можно также отслеживать состояние оборудования, его нагрузку, тем самым предотвращая аппаратные проблемы.

Итак, типичные инструменты операционного мониторинга — это:

  • Prometheus — система с открытым кодом для мониторинга, визуализации и передачи уведомлений;
  • Grafana — визуализатор, также с открытым кодом, для сбора логов, метрик, создания дашбордов; преимуществом является возможность получать данные от различных систем в одном месте;
  • Splunk — мониторинговая платформа со значительными возможностями в применении, начиная с мониторинга инфраструктуры, «умных» уведомлений и заканчивая безопасностью;
  • Kibana — система для визуализации данных ElasticSearch и мониторинг Elastic стека (ElasticSearch, APM, Logstash и т.д.);
  • PagerDuty — система, которая поможет разумно подойти к прогнозированию периодов недоступности системы, тем самым позволяя быстро и эффективно реагировать на такие вызовы; полезна также для определения графика работы команды поддержки;
  • Zabbix — бесплатная универсальная система мониторинга приложений, программной и аппаратной инфраструктуры с поддержкой ІоТ проектов;
  • Solarwinds — сложная система мониторинга серверных приложений и аппаратного обеспечения;
  • Datadog — облачная мониторинг-система в реальном времени и оценка производительности сети, приложения, действий пользователей;
  • ManageEngine OpManager — инструмент мониторинга сетевой нагрузки;
  • PRTG Network Monitor — мониторинг CPU, RAM, жесткого диска, принтеров, сети и т.п;
  • Newrelic — облачный мониторинг CPU, RAM, жесткого диска и других аппаратных ресурсов.

Облачное решение или локальная инсталляция?

В обоих подходах есть определенные преимущества и недостатки (как правило, взаимно противоположные). Рассмотрим оба в виде таблицы.

Облачное решение Локальная инсталляция
Преимущества:
  • Ежемесячный платеж покрывает стоимость разработки и поддержки;
  • Вообще нет необходимости поддержки;
  • Легко масштабировать;
  • Системы специально создаются для мониторинга с учетом опыта, преимуществ и недостатков других подобных систем.
Недостатки:
  • Интеграционные и операционные расходы достаточно велики, перед тем, как — покупать такую систему, следует сначала попробовать ее в использовании;
  • На ознакомление с системой команде разработки потребуется определенное время;
  • Не всегда имеет возможность добавления кастомных метрик для мониторинга.
Преимущества:
  • Время на ознакомление с системой почти нулевое, поскольку она создается, устанавливается и используется, собственно, будущими пользователями;
  • Относительно небольшое время на устранение проблем, поскольку система является локальной;
  • Легкая интеграция с другими инструментами, которые используются в команде разработки, поскольку система специально создается для нужд команды;
  • Настраивается в точном соответствии с потребностями команды и проекта.
Недостатки:
  • Стоимость разработки значительно выше по сравнению с облачными решениями;
  • Поддержка и масштабирование могут быть дорогими.

Уведомления

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

  • доступности сервиса;
  • количестве неуспешных запросов;
  • времени получения ответа от сервера;
  • количестве или просто наличии серверных ошибок.

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

Уведомления в Azure DevOps

$subscription = az account show --query "id";$subscription.Trim("`"");$resource="/subscriptions/$subscription/resourcegroups/"+"$(Parameters.AppInsightsResourceGroupName)"+"/providers/microsoft.insights/components/" + "$(Parameters.ApplicationInsightsResourceName)";

az monitor metrics alert create -n 'Availability_$(Release.DefinitionName)' -g $(Parameters.AppInsightsResourceGroupName) --scopes $resource --condition 'avg availabilityResults/availabilityPercentage < 99' --description "created from Azure DevOps";

az monitor metrics alert create -n 'FailedRequests_$(Release.DefinitionName)' -g $(Parameters.AppInsightsResourceGroupName) --scopes $resource --condition 'count requests/failed > 5' --description "created from Azure DevOps";

az monitor metrics alert create -n 'ServerResponseTime_$(Release.DefinitionName)' -g $(Parameters.AppInsightsResourceGroupName) --scopes $resource --condition 'avg requests/duration > 5' --description "created from Azure DevOps";

az monitor metrics alert create -n 'ServerExceptions_$(Release.DefinitionName)' -g $(Parameters.AppInsightsResourceGroupName) --scopes $resource --condition 'count exceptions/server > 5' --description "created from Azure DevOps";

Уведомления в Jenkins для неудачного запуска Job

node {
  try {
    notifyStarted()
    /* ... existing build steps ... */
    notifySuccessful()
  } catch (e) {
    currentBuild.result = "FAILED"
    notifyFailed()
    throw e
  }
}
def notifyStarted() { /* .. */ }
def notifySuccessful() { /* .. */ }
def notifyFailed() {
  slackSend (color: '#FF0000', message: "FAILED: Job '${env.JOB_NAME} [${env.BUILD_NUMBER}]' (${env.BUILD_URL})")
  hipchatSend (color: 'RED', notify: true,
      message: "FAILED: Job '${env.JOB_NAME} [${env.BUILD_NUMBER}]' (${env.BUILD_URL})"
    )
  emailext (
      subject: "FAILED: Job '${env.JOB_NAME} [${env.BUILD_NUMBER}]'",
      body: """<p>FAILED: Job '${env.JOB_NAME} [${env.BUILD_NUMBER}]':</p>
        <p>Check console output at &QUOT;<a href='${env.BUILD_URL}'>${env.JOB_NAME} [${env.BUILD_NUMBER}]</a>&QUOT;</p>""",
      recipientProviders: [[$class: 'DevelopersRecipientProvider']]
    )
}

Мониторинг состояния аппаратной инфраструктуры

Проверять состояние аппаратной инфраструктуры полезно по ряду причин:

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

Chaos Monkey

  • Chaos monkey была предложена компанией Netflix;
  • Случайным образом уничтожает виртуальные машины или контейнеры, работающие в конфигурации, доступной конечным пользователям;
  • Когда инженерам приходится сталкиваться с недоступностью сервисов и другими подобными проблемами, это побуждает их к созданию надежных систем;
  • Благодаря таким «небольшим» тренировочным проблемам можно избежать больших, реальных;
  • Всегда будет в наличии план по предупреждению непредсказуемых последствий неудачных изменений в коде.

Е2Е-тесты инфраструктуры

Как только приложение становится доступным для конечных пользователей, нужно сделать определенные Е2Е-тесты для инфраструктуры, то есть такие, которые используют все элементы конфигурации. Это позволит:

  • убедиться, что вся пользовательская инфраструктура работает;
  • проверить несколько основных сценариев использования приложения;
  • выявить ошибки интеграции компонентов инфраструктуры (при их наличии);
  • составить очень общее впечатление о производительности использования аппаратных ресурсов для отдельных сценариев и экстраполировать при необходимости.

Наконец инструменты!

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

Datadog

NewRelic

Prometheus

Пример задания уведомлений в Prometheus

global:
  slack_api_url: '<slack_webhook_url>'
route:
  receiver: 'slack-notifications'
  group_by: [alertname, datacenter, app]
receivers:
- name: 'slack-notifications'
  slack_configs:
  - channel: '#alerts'
    text: 'https://internal.myorg.net/wiki/alerts/{{ .GroupLabels.app }}/{{ .GroupLabels.alertname }}'
Alert:
groups:
- name: Instances
  rules:
  - alert: InstanceDown
    expr: up == 0
    for: 5m
    labels:
      severity: page
    # Prometheus templates apply here in the annotation and label fields of the alert.
    annotations:
      description: '{{ $labels.instance }} of job {{ $labels.job }} has been down for more than 5 minutes.'
      summary: 'Instance {{ $labels.instance }} down'

Receiver:
- name: 'team-x'
  slack_configs:
  - channel: '#alerts'
    # Alertmanager templates apply here.
    text: "<!channel> \nsummary: {{ .CommonAnnotations.summary }}\ndescription: {{ .CommonAnnotations.description }}"


Splunk




Пример задания уведомлений в Splunk

log_level=ERROR OR log_level=FATAL OR log_level=CRITICAL) | stats count by log_level | 
search count > 10

Grafana

Пример задания уведомлений в Grafana

Zabbix

Пример задания уведомлений в Zabbix

PagerDuty

Пример создания графика работы команды поддержки в PagerDuty

Пример задания уведомлений в PagerDuty

Выводы

Операционный мониторинг — непростая задача, которая предполагает не только отслеживание пользовательской активности, но и предвидение проблем системы до того, как она перестанет работать, и конечный пользователь перестанет получать сервис. Можно также отслеживать подозрительные действия, выделять паттерны в использовании приложения, оценивать нагрузку и подбирать инфраструктуру соответствующим образом и еще много другого. Важную роль играет установление правильных нотификаций, что позволяет предотвращать проблемы как с приложением, так и с инфраструктурой, и минимизировать время недоступности сервиса для пользователей. Кроме того, существуют и процессные подходы для улучшения надежности приложений, например, chaos monkey.

👍НравитсяПонравилось4
В избранноеВ избранном3
LinkedIn
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

О чем эта статья?! Pagerduty стал вдруг мониторинговым тулом и им «удобно менеджить расписание»? Писать про системы мониторинга и не вспомнить про Нагиос/Исингу? Смешались в кучу кони-люди :(...
Проблемы построение ситемы мониторинга продакшена обычно не в выборе тулов, а в определении ключевых сервисов, метрик, правил уведомления и эскалации. А тул и как конфигурить его это уже дело десятое.

Подписаться на комментарии