Вибірка

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

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

Терміни

Важливо використовувати послідовну термінологію при обговоренні вибірки. Трейс або відрізок вважають “семпльованими” або “не семпльованими”:

• Семпльовані: Трейс або відрізок обробляються та експортуються. Оскільки вони обрані семплером як представники популяції, вони вважаються “семпльованими”.
• Не семпльовані: Трейс або відрізок не обробляються та не експортуються. Оскільки вони не обрані семплером, вони вважаються “не семпльованими”.

Іноді визначення цих термінів плутають. Ви можете почути, що хтось говорить, що вони “семплюють дані” або що дані, які не обробляються або не експортуються, вважаються “семпльованими”. Це неправильні твердження.

Чому вибірка?

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

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

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

Коли застосовувати вибірку

Розгляньте можливість вибірки, якщо ви відповідаєте будь-якому з наступних критеріїв:

• Ви генеруєте 1000 або більше трейсів на секунду.
• Більшість ваших трейсів представляють здоровий трафік з невеликою варіацією в даних.
• У вас є деякі загальні критерії, такі як помилки або висока затримка, що зазвичай означає що щось не так.
• У вас є специфічні для домену критерії, які ви можете використовувати для визначення релевантних даних крім помилок і затримки.
• Ви можете описати деякі загальні правила, які визначають, чи повинні дані бути вибрані або відкинуті.
• Ви маєте спосіб розрізняти ваші служби, щоб служби з високим і низьким обсягом даних семплювалися по-різному.
• Ви маєте можливість направляти несемпльовані дані (для “про всяк випадок” сценаріїв) до систем з низькою вартістю зберігання.

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

Коли не варто застосовувати вибірку

Вибірка може бути такою, що не підходить вам. Ви можете уникати вибірки, якщо відповідаєте будь-якому з наступних критеріїв:

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

Нарешті, розгляньте наступні три витрати, повʼязані з вибіркою:

1. Прямі витрати на обчислення для ефективної вибірки даних, такі як проксі для відбору останніх записів.
2. Непрямі інженерні витрати на підтримку ефективних методологій вибірки з додаванням нових застосунків, систем і даних.
3. Непрямі витрати на можливості, повʼязані з втратою критичної інформації через неефективні методи відбору.

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

Вибірка на початку

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

Наприклад, найпоширеніша форма вибірки на початку — це Консистентний ймовірнісний семплінг. Це також може називатися детермінованим семплінгом. У цьому випадку рішення про вибірку приймається на основі ідентифікатора трейса та бажаного відсотка трейсів для вибірки. Це забезпечує, що цілі трейси семпльовані, без пропущених відрізків, з постійною частотою, наприклад, 5% всіх трейсів.

Переваги вибірки на початку:

• Легко зрозуміти
• Легко налаштувати
• Ефективна
• Може бути виконана на будь-якому етапі в ланцюжку збору трейсів

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

Вибірка наприкінці

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

Деякі приклади того, як ви можете використовувати вибірку наприкінці, включають:

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

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

Сьогодні існує три основні недоліки вибірки наприкінці:

1. Вибірка наприкінці може бути складною для реалізації. Залежно від типу доступних вам технік семплінгу, це не завжди “налаштуй і забудь”. Як змінюються ваші системи, так само змінюватимуться ваші стратегії семплінгу. Для великої та складної розподіленої системи правила, що реалізують стратегії відбору, також можуть бути великими та складними.
2. Вибірка наприкінці може бути складною для експлуатації. Компонент(и), що реалізують вибірку наприкінці, повинні бути stateful системами, які можуть приймати та зберігати велику кількість даних. Залежно від патернів трафіку, це може вимагати десятків або навіть сотень обчислювальних вузлів, які всі використовують ресурси по-різному. Крім того, вибірка наприкінці може потребувати “повернення” до менш обчислювально інтенсивних технік відбору, якщо він не в змозі впоратися з обсягом даних, які він отримує. Через ці фактори критично важливо моніторити компоненти вибору наприкінці, щоб забезпечити, що вони мають ресурси, необхідні для прийняття правильних рішень про відбір.
3. Вибір наприкінці часто є технологією, специфічною для постачальника сьогодні. Якщо ви використовуєте платного постачальника для спостереження, найефективніші варіанти вибору наприкінці, доступні вам, можуть бути обмежені тим, що пропонує постачальник.

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

Підтримка

Колектор

Колектор OpenTelemetry включає наступні процесори вибірки:

• Процесор ймовірнісного семплінгу
• Процесор вибірки наприкінці

Мовні SDK

Для окремих мовних реалізацій API та SDK OpenTelemetry ви знайдете підтримку семплінгу на відповідних сторінках документації:

• Erlang/Elixir
• Go
• JavaScript
• Ruby

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

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