Можливість спостерігати (Observability) стала модним трендом, в тому числі у світі API. Але будьте обережні, шукаючи інформацію про спостережуваність API, адже існує багато застарілих практик і нерелевантної інформації, повідомляє DevOps.
Наводимо сім пасток API, яких слід уникати.
Антишаблон: забути про користувачів
API – це не просто технічний інтерфейс. Це міст, який об’єднує цифровий досвід і дозволяє людям ефективно виконувати завдання.
Є два різні типи користувачів:
- Розробники, які інтегрують ваш API у свою систему.
- Користувачі, які зрештою взаємодіятимуть із програмами чи службами, які покладаються на ваш API.
Якщо ви не можете зрозуміти, як вони взаємодіють із вашими API, ви втрачаєте половину картини.
Коли розробники інтегруються з вашими API, скільки часу їм потрібно, щоб зробити свій перший успішний виклик API? Які типові помилки сповільнюють їх? Спостережливість відіграє важливу роль у висвітленні інформації для покращення роботи розробника.
Чи можете ви відстежити, як ваші випуски вплинули на їхні запити, коли програми чи служби ваших клієнтів, що покладаються на ваші API, будуть у виробництві? Яку версію ваших API вони використовують? Які кінцеві точки найпопулярніші? Чи всі клієнти отримують однакову продуктивність? Однакові показники помилок?
Антишаблон: покладатися лише на моніторинг API
Моніторинг API зазвичай передбачає надсилання автоматизованих тестових запитів до кінцевих точок API та перевірку відповідей. Це допомагає відстежувати справність ваших API, навіть якщо клієнтська діяльність взагалі відсутня, і може використовуватися для звітування про безвідмовну роботу.
Але моніторинг API – це тестування «чорної скриньки», адже ви не бачите, що відбувається всередині. Ви просто знаєте, що ваші запити досягають API та отримують відповіді, але можете створювати та підтримувати тести лише для деяких можливих випадків використання.
Антишаблон: використовувати журнали доступу до API для усунення несправностей
Журнали доступу до API – це записи запитів і відповідей, надісланих до API, які фіксують такі деталі, як IP-адреса запитувача, метод HTTP, запитана кінцева точка, коди стану та інша відповідна інформація для моніторингу, налагодження й безпеки.
Використання журналів доступу для усунення проблем API схоже на пошук голки в стозі сіна мікросервісів. Один із користувачів мав проблеми з продуктивністю API. Вони витратили дні на пошук першопричини за допомогою журналів доступу. Це шлюз? Чи потрібно більше ЦП? Це проблема конфігурації? Вони увімкнули розподілене трасування й за кілька секунд змогли побачити, що відбувається. Весь час було витрачено на сервер автентифікації, який видає токени JWT.
Щоб справді зрозуміти, що відбувається у вашій системі, необхідно мати можливість відстежувати окремий запит користувача від шлюзу API до вищих служб і їхніх залежностей для ефективного усунення несправностей.
Антишаблон: різні команди, різні інструменти, різні дані
У різних команд різні потреби. Інструмент, який працює для вашої команди DevOps, може не найкраще підходити вашій команді продукту. Змушуючи всіх використовувати той самий інструмент, ви сприяєте не єдності, а неефективності.
Однак, хоча сприяння різноманітності інструментів може бути правильним кроком для вашої організації, має бути певна координація та інтеграція між різними інструментами та джерелами даних.
Відкриті стандарти, такі як OpenTelemetry, допомагають забезпечити спільний доступ до інформації та її використання між командами й інструментами.
Команди DevOps і продукту повинні покладатися на однаковий рівень помилок під час оцінки продуктивності та надійності найновішого запущеного продукту API.
Антишаблон: один розмір підходить усім
Різні стилі архітектури API мають різні потреби, коли йдеться про спостережуваність.
API REST вже широко використовується, але й нові стилі, такі як GraphQL і gRPC, набувають популярності. Кожен із цих стилів має відмінні характеристики та вимоги щодо спостережливості. Вебсокет та API-інтерфейси, керовані подіями, також мають свої унікальні проблеми з можливістю спостереження.
Різні архітектури API мають різні потреби. Ваша стратегія спостереження повинна відображати це, щоб підвищити загальну надійність вашої програми.
Антишаблон: можливість спостереження лише для виробництва
Чому ви не використовуєте спостережливість у підготовчому виробництві?
Використовуючи розподілене трасування протягом життєвих циклів розробки API, розробники можуть відстежувати потік запитів і відповідей у різних службах, забезпечуючи повне уявлення про те, як API поводиться в різних сценаріях.
Завдяки спостережливості вони можуть визначати вузькі місця продуктивності та навіть виявляти архітектурні проблеми, такі як проблеми N+1 у запитах GraphQL.
Для команд, які використовують практики APIOps, дані спостережуваності можуть використовуватися як додаткова перевірка перед просуванням API до стадії виробництва.
Антишаблон: запуск трасування на шлюзі API переоцінений
Посібники про спостережуваність зазвичай починають процес інструментування на рівні мікросервісу. Чудово мати детальну інформацію про ваші мікросервіси. Але під час роботи з API на рівні шлюзу API багато чого станеться.
Ви хочете зафіксувати всі свої транзакції користувача, включно з тими, які ніколи не досягають ваших мікросервісів через правила обмеження швидкості, проблеми автентифікації або механізм кешування?
Початок трасування на шлюзі API дає вам чітку точку входу та повну картину шляху всіх ваших користувачів. Ось чому важливо використовувати сучасний API-шлюз із вбудованою підтримкою OpenTelemetry.
Нагадаємо, що API Threads стане доступним для творців і розробників вже у червні.
Підписуйтеся на ProIT у Telegram, щоб не пропустити жодної публікації!
