Усі проєкти раніше чи пізніше потрапляють у підтримку. Окей, не всі, але це звичайний розвиток подій для успішних проєктів, у яких вже з'явилися свої користувачі. І чим більше стає цих користувачів, тим важливішим є забезпечення працездатності системи. На стадії підтримки з'являються певні процеси, яких, скоріш за все, не було до того, а саме – операційний моніторинг.

Це регулярна перевірка доступності сервісів та нотифікації у випадку якихось проблем. Однак це не єдина можлива перевага операційного моніторингу. За допомогою інструментів, що перевіряють стан сервісів-компонентів проєкту, можна зібрати багато цікавої статистики. Звісно, для того, щоб це стало можливим, така інформація має міститися в повідомленнях, що надсилаються системою. Якщо мова про вебзастосунки, то типовим рішенням є додавання інформації в параметр заголовка User-Agent (наприклад, версії застосунку, завдяки чому можна оцінити, яка версія найпопулярніша серед користувачів). Можна вивчити тенденції навантаження на систему, типові запити тощо. Окрім моніторингу власне застосунку, також можна відслідковувати стан обладнання, його навантаження, тим самим запобігаючи апаратних проблем.

У цій статті я наведу типові інструменти для операційного моніторингу, приклади їх налаштування для надсилання нотифікацій, порівняння встановлення таких систем локально або використання готових хмарних рішень.

Типові інструменти операційного моніторингу

Prometheus – система з відкритим кодом для моніторингу, візуалізації та надсилання нотицікацій
Grafana – візуалізатор (також з відкритим кодом) для збору логів, метрик, створення дашбордів; перевагою є можливість отримувати дані від різних систем в одному місці
Splunk – моніторингова платформа зі значними можливостями в застосуванні, починаючи з моніторингу інфраструктури, «розумних» нотифікацій та закінчуючи безпекою
Kibana – система для візуалізації даних Elasticsearch та моніторинг Elastic стеку (ElasticSearch, APM, Logstash, etc)
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.AppInsi htsResourceGroupName)"+"/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

- Була запропонована в Netflix.
- Випадковим чином знищує віртуальні машини або контейнери, які працюють в конфігурації, доступній кінцевим користувачам.
- Коли інженерам доводиться стикатися з недоступністю сервісів та іншими подібними проблемами, це спонукає їх до створення надійніших систем.
- Завдяки таким «невеликим» тренувальним проблемам, можна уникнути більших, реальних.
- Завжди буде в наявності план по попередженню непередбачуваних наслідків невдалих змін в коді.

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

Як тільки застосунок стає доступним для кінцевих користувачів, потрібно зробити певні Е2Е-тести для інфраструктури, тобто такі, що використовують взагалі всі елементи конфігурації. Це дозволить:
- впевнитися, що вся користувацька інфраструктура працює;
- перевірити декілька основних сценаріїв використання застосунку;
- викрити помилки інтеграції компонентів інфраструктури (за їх наявності);
- скласти дуже загальне враження про продуктивність використання апаратних ресурсів для окремих сценаріїв та екстраполювати за необхідності.

У другій частині цього матеріалу авторка розглядає інструменти для операційного моніторингу.

Оригінал матеріалу

ТОБІ МОЖЕ
БУТИ ЦІКАВО…Передбачення помилки: тестування чорного ящика

Ефективний операційний моніторинг: що для цього потрібно? (Част. 1)