Якою має бути сфера перевірки стану здоров’я для системи, яка використовує веб-сайт?

Сьогодні у мене було завдання «написати перевірку стану здоров’я» для тривалої роботи, яка є системою оркестрації для розгортання веб-програми.

Я намагаюся визначити, якою буде сфера такої перевірки здоров’я, і підійшов до цих питань, що стосуються сфери медичної перевірки:

1. Чи достатньо добре вважати послугу здоровою, якщо система оркестрації повідомляє, що завдання виконується?
2. Або ми повинні вручну підписувати кожну послугу?
3. Або варто піти далі і намагатися забезпечити, щоб веб-додаток робив те, що належить робити, як показати веб-сторінку?
4. Чи має також перевірка здоров’я перевірити, чи працюють також деякі залежні служби? Як і база даних, або сама система оркестрації. Або це відповідальність чергової перевірки здоров’я?
5. І, нарешті, якщо одна із залежних служб померла, а веб-додаток згодом вийшов з ладу, чи повинен веб-додаток повідомляти про погане здоров’я, чи це добре здоров’я, оскільки це не вина веб-додатків?

Я знаю, що це 5 окремих запитань, але всі вони стосуються сфери перевірки стану здоров’я для довготривалої послуги, яка розгортає веб-додаток, тому я вважав, що було б більше сенсу згрупувати їх в одному запитанні.

Це важко реалізувати для мене, тому що я не впевнений у визначенні того, що таке здорове або як має виглядати стандартна перевірка здоров’я на щось подібне.

Що має містити перевірка здоров’я для цієї конкретної послуги?

Це важко здійснити через визначення того, що є здоровим

Ви відповіли на власне запитання тут. Визначення медичної перевірки буде різним, оскільки те, що є здоровим, змінюється. Це також залежить від того, що видає перевірку здоров’я.

Хороше запитання, яке потрібно задати собі, "з точки зору запитувача, чи перевірена служба працює так, як очікувалося?" Якщо це ти, ти можеш це визначити. Якщо це інша команда / служба, вам потрібно визначити, що таке стандарт / специфікація для перевірок здоров'я.

Ймовірно, у великій організації у вас з’явиться якийсь стандарт для того, що слід робити. Виясніть це.

Зокрема, ваш приклад webapp означає, що він не повинен повертатися здоровим, оскільки webapp не здоровий. Але, можливо, ваше визначення поняття "здоровий" буде включати це як "добре". Це частина обговорення вимог вище (знову ж таки, навіть якщо це лише ваш власний код).

Моя рекомендація, припускаючи, що вона не вказана в іншому місці, полягала б у тому, щоб мати якийсь код статусу, пов'язаний з різними відмовами. Коли ви запитуєте веб-сервер, він може повернути помилку, яка говорить про те, що "залежна послуга мертва", і тому ваш клієнт (або що завгодно виконує перевірку здоров'я) може знати причину того, що клієнт мертвий.

Для відредагованих питань:

Чи достатньо добре вважати послугу здоровою, якщо система оркестрації повідомляє, що завдання виконується?

Ні, тільки те, що процес запущений, не означає, що він не вичерпаний, абсолютно нефункціональний або велика кількість інших можливостей.

Або ми повинні вручну підписувати кожну послугу?

Це може працювати, залежно від обсягу функціональних можливостей вашої програми. Якщо перевірка служби відповідає на "Ви живі?" ping, то це може бути все, що потрібно. Але якщо служба легко може бути "живою та чуйною, але насправді не працює", то, можливо, вам потрібно перевірити й інші речі.

Або варто піти далі і намагатися забезпечити, щоб веб-додаток робив те, що належить робити, як показати веб-сторінку?

Ваша перевірка здоров'я повинна гарантувати, що потрібна функціональність, яка очікується, працює так, як очікувалося.

Якщо ваш додаток повертає «здоровий» і не може робити те , що йому потрібно зробити, ви можете також позбутися від усього Healthcheck , оскільки це дає помилкові спрацьовування (не кажучи вже про заплутати риси з людей , які намагаються налагодити цю проблему - «агов наш веб-сервер показує здоровий, чому ми не можемо побачити сторінку? ').

Чи має також перевірка здоров’я перевірити, чи працюють також деякі залежні служби? Як і база даних, або сама система оркестрації. Або це відповідальність чергової перевірки здоров’я?

Це дещо залежить. Якщо ваша послуга залежить від іншої послуги, характер цієї взаємодії повинен відображатися в API / мережевих дзвінках, надісланих їй у вашому додатку, та включених у перевірку здоров'я.

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

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

В основному, якщо вашій службі потрібно поговорити з іншими службами і перевірити їх здоров'я в будь-якому разі, має сенс принаймні встановити базовий рівень перевірки на предмет перевірки здоров'я вашої служби. Це має мати сенс концептуально з огляду на те, що я щойно сказав, оскільки ваша програма вже буде вирішувати цю проблему (або, напевно, виходить з ладу).

І, нарешті, якщо одна із залежних служб померла, а веб-додаток згодом вийшов з ладу, чи повинен веб-додаток повідомляти про погане здоров’я, чи це добре здоров’я, оскільки це не вина веб-додатків?

На це в основному відповіді вище. Я рекомендую, щоб ваша медична перевірка повернула код / ​​повідомлення / все, що дає цю інформацію. Обидві відомості важливі: що залежна від вашої послуги послуга мертва та що ваша послуга не працюватиме так, як очікувалося.

Як правило, перевірка здоров’я просто означає "чи живе вона і чи відповідає". Подальші перевірки, ніж ті, є вузькоспеціалізованими і повністю залежать від використання системи. Незалежно від того, чи будете ви проходити додаткову милю, щоб перевірити, чи система обробляє запити правильно, вам належить, але спершу слід виконати основи - перевірте це, перевірити, чи може він отримувати запити та поверне відповідь.

Найпростіший спосіб здійснити перевірку стану здоров’я - це просто написати команду, яку сервіс обробляє за тим самим механізмом, що і інші команди, що не робить нічого, окрім повернення підтвердження. Це покаже активність і що система отримує та обробляє відповіді.

Перевірка залежних систем не є частиною перевірки стану здоров’я, потрібно робити її простою та самодостатньою. По черзі додайте перевірку стану здоров’я до кожної залежної служби. Таким чином ви зможете отримати список працюючих, здорових систем і легко сказати, коли в когось погано, яка саме!

На мій досвід, критичні служби мають такі характеристики:

Серцебиття

Якщо служба запускається регулярно, це просто записує рядок у файл журналу чи подібний разом із часовою позначкою, щоб вказати, що орган служби запускався в даний момент часу.

Панірувальні сухарі

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

Це може бути заманливо додати багато інших речей, таких як стан різних серверів, служб та баз даних тощо. Хоча це, без сумніву, цінне, я б радив не писати щось занадто обширне. Вони можуть бути корисними для вашого душевного спокою, але такі гарантії, як правило, зловживають, як тільки сторони, відповідальні за різні точки дотику, знають, що вони є. Перш ніж це знати, ви можете написати програму для діагностики для всієї компанії.