Метрики

Метрика — це вимірювання сервісу, зафіксоване під час виконання. Момент фіксації вимірювання відомий як подія метрики, яка складається не тільки з самого вимірювання, але й часу, коли воно було зафіксоване, та повʼязаних метаданих.

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

Щоб зрозуміти, як працюють метрики в OpenTelemetry, розгляньмо список компонентів, які будуть брати участь в інструментуванні нашого коду.

Постачальник лічильників

Постачальник лічильників (іноді називається MeterProvider) є фабрикою для Meter. У більшості застосунків постачальник лічильників ініціалізується один раз, і його життєвий цикл відповідає життєвому циклу застосунку. Ініціалізація постачальника лічильників також включає ініціалізацію ресурсів та експортерів. Це зазвичай перший крок у вимірюванні з OpenTelemetry. У деяких мовних SDK глобальний постачальник лічильників вже ініціалізований для вас.

Лічильник

Лічильник створює інструменти метрик, фіксуючи вимірювання сервісу під час виконання. Лічильники створюються з постачальників лічильників.

Експортер метрик

Експортери метрик надсилають дані метрик споживачу. Цим споживачем може бути стандартний вивід для налагодження під час розробки, колектор OpenTelemetry або будь-який відкритий або комерційний бекенд на ваш вибір.

Інструменти метрик

В OpenTelemetry вимірювання фіксуються інструментами метрик. Інструмент метрики визначається:

• Назвою
• Типом
• Одиниця виміру (необовʼязково)
• Опис (необовʼязково)

Назва, одиниця виміру та опис обираються розробником або визначаються через семантичні домовленості для загальних, таких як метрики запитів та процесів.

Тип інструменту є одним з наступних:

• Counter: Значення, яке накопичується з часом — ви можете уявити це як одометр в автомобілі; воно тільки збільшується.
• Asynchronous Counter: Те ж саме, що і Counter, але збирається один раз для кожного експорту. Може використовуватися, якщо у вас немає доступу до безперервних приростів, а тільки до агрегованого значення.
• UpDownCounter: Значення, яке накопичується з часом, але також може зменшуватися. Прикладом може бути довжина черги, яка буде збільшуватися і зменшуватися з кількістю робочих елементів у черзі.
• Asynchronous UpDownCounter: Те ж саме, що і UpDownCounter, але збирається один раз для кожного експорту. Може використовуватися, якщо у вас немає доступу до безперервних змін, а тільки до агрегованого значення (наприклад, поточний розмір черги).
• Gauge: Вимірює поточне значення на момент читання. Прикладом може бути показник палива у транспортному засобі. Gauge є синхронними.
• Asynchronous Gauge: Те ж саме, що і Gauge, але збирається один раз для кожного експорту. Може використовуватися, якщо у вас немає доступу до безперервних змін, а тільки до агрегованого значення.
• Histogram: Агрегація значень на стороні клієнта, таких як затримки запитів. Гістограма є хорошим вибором, якщо вас цікавить статистика значень. Наприклад: Скільки запитів займають менш як 1 секунда?

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

Агрегація

Крім інструментів метрик, важливо розуміти концепцію агрегацій. Агрегація — це техніка, за допомогою якої велика кількість вимірювань обʼєднується в точні або оцінені статистичні дані про події метрик, що відбулися протягом певного часового вікна. Протокол OTLP транспортує такі агреговані метрики. API OpenTelemetry надає стандартну агрегацію для кожного інструменту, яку можна перевизначити за допомогою Views. Проєкт OpenTelemetry прагне надавати стандартні агрегації, які підтримуються візуалізаторами та бекендами телеметрії.

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

• Звіт про загальну кількість байтів, прочитаних сервісом, за типом протоколу.
• Звіт про загальну кількість прочитаних байтів та байтів на запит.
• Звіт про тривалість системного виклику.
• Звіт про розміри запитів для визначення тенденції.
• Звіт про використання CPU або памʼяті процесом.
• Звіт про середні значення балансу з рахунку.
• Звіт про поточні активні запити, що обробляються.

Представлення

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

Обмеження кардинальності

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

Щоб захистити застосунки від цього, SDK метрик OpenTelemetry застосовує ліміт кардинальності: максимальну кількість унікальних комбінацій атрибутів, що відстежуються на потік метрики. Стандартне значення — 2000, і його можна змінити за допомогою Представлення.

Коли ліміт досягнуто, додаткові комбінації атрибутів не відкидаються повністю. Натомість їхні вимірювання агрегуються в одну точку даних переповнення, ідентифіковану атрибутом otel.metric.overflow=true. Ця конструкція має три важливі властивості:

• Жодні вимірювання не втрачаються. Відкидаються лише атрибути; записані значення включаються в точку даних переповнення, тому загальний підсумок метрики залишається правильним.
• Памʼять обмежена. SDK ніколи не відстежує більше ніж налаштовану кількість комбінацій.
• Переповнення спостережуване. Кожен SDK використовує той самий маркер otel.metric.overflow=true, тому один запит може виявити переповнення в різних сервісах, мовах та бекендах.

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

Це легко недооцінити, оскільки переповнення замінює всю комбінацію атрибутів, а не лише її висококардинальну частину. Припустимо, лічильник запитів записує url.path (висока кардинальність) разом із success (булеве значення). Після переповнення потоку вимірювання для {url.path=/checkout, success=false} включається в єдину точку даних переповнення {otel.metric.overflow=true}, втрачаючи success разом із url.path. Запит для success=false тоді пропустить це вимірювання, навіть якщо success сам по собі має низьку кардинальність. Сповіщення про рівень помилок, побудоване на success=false, може перестати спрацьовувати, хоча загальний підсумок метрики залишається правильним.

На що ліміт не поширюється

Ліміт кардинальності застосовується лише до атрибутів, наданих під час запису вимірювань через API метрик. Він не поширюється на:

• Атрибути Ресурсу, такі як service.name або service.instance.id.
• Атрибути області інструментування, встановлені під час створення Лічильника.

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

Темпоральність та обмеження кардинальності

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

• З дельта темпоральністю SDK скидає стан після кожного циклу, тому ліміт обмежує лише комбінації, активні в межах одного циклу.

Підтримка мов

Метрики є стабільним сигналом у специфікації OpenTelemetry. Для окремих мовних реалізацій API та SDK метрик статус наступний:

Специфікація

Щоб дізнатися більше про метрики в OpenTelemetry, дивіться специфікацію метрик.