Спостережуваність в Azure за допомогою OpenTelemetry: практичний посібник

Спостережуваність — це здатність пояснити внутрішній стан системи за доказами, які вона сама створює. Її мета полягає не в тому, щоб збирати все підряд. Вона має допомагати команді помічати шкоду для клієнтів, знаходити відповідальну залежність, розуміти, що змінилося, безпечно відновлювати роботу й робити висновки до наступного інциденту. Azure Monitor, Application Insights і Log Analytics надають технічні можливості, а OpenTelemetry — переносні правила та засоби вимірювання. Жоден із них не замінює належної організації експлуатації.

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

Почніть зі шляхів користувача, а потім добирайте журнали, показники й відстеження

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

Рухайтеся від шляху користувача у зворотному напрямку. Для мети оформлення замовлення можуть знадобитися частка завершення, затримка p95 і помилки платежів; відстеження через API, чергу й постачальника; а також упорядковані журнали для звіряння. Саме завантаження процесора не скаже, чи досягли клієнти мети. Водночас запис кожного вмісту створює ризики для приватності й вартості, не поліпшуючи діагностику.

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

Зробіть OpenTelemetry сталим шаром вимірювання

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

OpenTelemetry Collector може поза застосунком приймати, збагачувати, відсіювати, вибирати й надсилати телеметрію. Залишайте його обробники простими та придатними до спостереження. Розміщення збирачів — на кожному вузлі, у скупченні чи централізовано — визначайте за вимогами доступності, мережі та відповідальності. Накопичуйте дані лише в безпечних межах, захищайте кінцеві точки й вимірюйте втрачені ділянки, тиск черги, затримку передавання та версію налаштувань.

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

Досліджуйте поведінку застосунку через Application Insights

Application Insights може показувати запити й залежності, винятки, результати перевірки доступності, швидкодію браузера та розподілені шляхи в Azure Monitor. Визначте будову ресурсів до підключення служб: межі середовищ і відповідальності, регіони, використання робочих областей, доступ, строки зберігання й потребу спільно запитувати кілька служб. Не створюйте один нерозділений ресурс, у якому права, витрати й межі інциденту стають неясними.

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

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

Плануйте Log Analytics від потреби в запитах і строках зберігання

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

Проєктуйте таблиці Log Analytics, доступ і строки зберігання на основі вимог до розслідування, перевірки, розташування даних і вартості. Коли доречно, відокремлюйте часто потрібні робочі запити від довгострокових архівів відповідності. Використовуйте доступ за ролями та приватне з’єднання відповідно до моделі загроз. Приховуйте чутливі відомості в джерелі, бо наступні фільтри не здатні надійно повернути дані, які вже було передано.

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

Зберігайте зв’язок подій на кожній асинхронній межі

Застосовуйте контекст відстеження W3C на кожній підтримуваній межі та свідомо передавайте його через HTTP, повідомлення й роботу за розкладом. Ділянка відправника має бути пов’язана з опрацюванням одержувачем, але час очікування в черзі не слід видавати за виконання на сервері. Зберігайте ідентифікатори повідомлень і ділових об’єктів для звіряння, проте не використовуйте значення з величезною кількістю варіантів як виміри показників.

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

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

Нехай кожне сповіщення й панель ведуть до рішення

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

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

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

Керуйте вартістю телеметрії та пов’язуйте її з роботою над інцидентами

Розкладайте вартість телеметрії на приймання, опрацювання, запити, зберігання, архів, передавання назовні та робочий час. Відносьте її до служби, середовища, виду сигналу й власника. До бездумного відкидання даних знайдіть необмежені мітки, повторне приймання, налагоджувальні журнали, надто докладні перевірки стану й зайве тривале зберігання. Обмежуйте витрати бюджетами й відстежуйте незвичне зростання, не вилучаючи відомості, без яких неможливо довести рівень служби, розібрати інцидент або виконати зобов’язання.

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

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

Коли варто запросити незалежних фахівців зі спостережуваності

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

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

GARNO.TECH може оцінити чинне середовище, спроєктувати правила OpenTelemetry, реалізувати наскрізний фрагмент або поліпшити роботу Azure Monitor через послуги з хмарного розроблення в Azure. Налаштування, панелі, запити й регламенти залишаються під контролем клієнта, а передавання знань входить до роботи.

• Шляхи: до вибору сигналів назвіть критичні результати для клієнта, цілі служби, способи відмови та відповідальних власників.
• Угоди: уніфікуйте ознаки служби, операції, версії та безпечного контексту й установіть явні межі кількості значень і приватності.
• Зв’язок: передавайте контекст відстеження через HTTP, черги й завдання; явно описуйте повтори, пакети й розгалуження, не втрачаючи ділової ідентичності.
• Якість сигналів: за реалістичного навантаження перевіряйте відсутні поля, втрачені ділянки, затримку приймання, зміни схеми та накладні витрати вимірювання.
• Дія: спрямовуйте сповіщення від цілей до визначених фахівців, указуючи серйозність, діагностичні посилання, регламенти й перевірений порядок залучення.
• Економіка: плануйте бюджет приймання, запитів, зберігання й передавання; усувайте марнотратство відповідно до мети, зберігаючи докази для інцидентів і вимог.