OpenTelemetry Logging і ви
Якщо ви слідкуєте за OpenTelemetry вже деякий час, ви напевно багато чули про логи. Log bridges, Logs API, events, що б ви не назвали, ми про це говорили. Цей допис у блозі призначено для обговорення обґрунтування та поточного напрямку розвитку логів в OpenTelemetry.
Визначення
Давайте почнемо з базового визначення того, що OpenTelemetry думає про логи. У широкому розумінні, журнали — це будь-яка телеметрія, яка передається через конвеєр журналів, і створюється за допомогою виклику Logs API. Ми передбачаємо два способи, якими користувачі можуть це робити:
- Використовувати Logs API як приймач для наявних логів (надсилаючи наявні логи до OpenTelemetry)
- Використовувати Logs API для надсилання events або записів журналу.
Незалежно від джерела, всі журнали, що надсилаються через Logs API, можуть брати участь у контексті OpenTelemetry Context. Записи журналу поділяють той самий контекст транзакції або потоку, що і метрика або діапазон. Це фундаментальна частина дизайну OpenTelemetry - всі ваші телеметричні сигнали можуть бути зіставлені через контекст.
З огляду на це, яка різниця між журналом і подією? Це досить просто — події це логи, щодо яких OpenTelemetry може надати гарантії. Подія має обовʼязкову назву та структуру, яка визначається схемою, подібно до того, як сьогодні визначаються семантичні домовленості. Хоча всі записи логів у OpenTelemetry структуровані, лише події мають таку визначену схему. Ми використовуємо слово «event», тому що воно найбільш чітко описує, що таке подія - це те, що відбувається, не має тривалості, і може мати імʼя.
Ми вважаємо, що більшість записів журналу повинні бути подіями.
Чим це відрізняється від інших сигналів?
Логи та відрізки часто сприймаються як концептуальні близнюки, особливо коли ви починаєте говорити про події. Зрештою, що таке відрізок, як не подія з особливо детальною схемою? Ключова відмінність між ними полягає в тому, що відрізки мають тривалість. Події не мають чіткої тривалості; вони можуть представляти собою справді миттєву подію або результат хвилин, годин чи днів роботи. Інша велика відмінність полягає в тому, що відрізки мають явну ієрархію. Відрізки мають звʼязки з іншими відрізками, і відрізок без звʼязків все одно є повним трейсом. Події не мають цієї властивості — ви не можете сказати, дивлячись на одну подію, як вона повʼязана з іншими.
Логи і метрики відрізняються більш концептуально — метрика є числовим рядом значень у часі. Хоча можна перетворити логи в метрики, це не стосується визначення самої телеметрії.
По суті, OpenTelemetry побудована на концепції, що всі сигнали інтерпретуються разом, а не окремо. Події можуть розглядатися як частина відрізку часу, протягом якого вони були згенеровані, і можуть бути використані для представлення всього, від помилок до даних безпеки, журналу доступу, інформації про час та багато іншого. Це не означає, що події не є корисними самі по собі, наприклад, розробник інтерфейсу може захотіти генерувати події взаємодії на кожен клік або дотик на екрані, які не є частиною відрізка, але це означає, що якщо подія відбувається «під час» відрізка, її можна вважати «частиною» цього відрізка.
Як ми це називаємо?
Якщо є щось, що я особисто можу сказати, що я дізнався за останні сім років існування OpenTelemetry, то це те, що люди мають дуже чіткі погляди на те, як слід називати речі - особливо, коли мова йде про логування. Ми не можемо задовольнити бажання кожного або певні ментальні очікування, коли мова йде про логування. Тому ми намагатимемося використовувати номенклатуру, наведену в цьому дописі.
Логи — це все, що ви надсилаєте через провайдера логів, а події — це особливий тип логів. Не всі журнали є подіями, але всі події є журналами..
Автори семантичної домовленості та інструментарію повинні використовувати події. Журнали повинні обмежуватися підключенням наявних бібліотек журналювання до OpenTelemetry, або коли жоден інший можливий сигнал не може бути застосований. Для більш детальної інформації, будь ласка, зверніться до Специфікації логів.
Коментарі
Ми відкрили тікет на GitHub для обговорення цього допису і будемо раді вашим відгукам.