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

Усі статті, обговорення, новини про тестування — в одному місці. Підписуйтеся на DOU | QA!

Меня зовут Анна Каплун, я 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Е-тесты для инфраструктуры, то есть такие, которые используют все элементы конфигурации. Это позволит:

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

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

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

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 }}'

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'

- 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

Выводы

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