Англійська для розробників Log Pipeline

Сучасні конвеєри журналів (Loki, Fluent Bit, Vector і подібні інструменти) індексують метадані, а не повний текст, що змінює словниковий запас команди навколо вартості запиту і кардинальності в порівнянні зі старими системами повнотекстового пошуку. Команда, яка зловживає “меткою” проти “поля”, або недооцінює кардиналність, в кінцевому підсумку має повільний, дорогий трубопровід і не знає чому. У цьому підручнику описано англійську мову, яку використовують під час обговорення конвеєрів журналів з командою.

Ключовий словник

** Кардинальність ** — кількість різних значень, які може мати мітка або поле; мітки з високою кардинальністю (наприклад, сирий ідентифікатор користувача або ідентифікатор запиту) створюють величезну кількість окремих потоків індексу і можуть уповільнити або зробити дорогим конвеєр журналу.

• “Поставлення сирого ідентифікатора запиту як мітки замість його вставлення всередину рядка журналу є вибухом кількості — кожен унікальний запит створює новий потік, і продуктивність запиту різко знижується.” *

** Мітка (або вміст рядка журналу) ** — індексовані метадані, які додано до потоку журналу (наприклад, service, environment або pod), використовуються для зменшення кількості потоків, у яких слід шукати, відрізняються від неіндексованого тексту самого повідомлення журналу.

• “Пересунути це динамічне значення з міток у рядок журналу — мітки призначені для невеликого, стабільного набору розмірів, а не для будь- чого, що змінюється за запитом.” *

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

• “Ми не усвідомлювали, що розгортання нового модуля створює новий потік журналу кожного разу, оскільки ми мітки за назвою модуля — саме тому наша панель управління фрагментується.” *

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

• “Додати крок редагування PII раніше у конвеєрі поглинання — зараз це відбувається після зберігання, тобто нередактовані дані вже знаходяться в індексі.” *

** Рівень збереження ** — правила, які визначають, наскільки довго зберігати дані журналу перед їх вилученням або зменшенням обсягу вибірки. Ці правила часто діляться на рівень зберігання « гарячих » (швидких, дорогих, короткострокових) і « холодних » (повільних, дешевих, довгострокових) даних. “Нам не потрібно дев’ янотисяч днів у горячому рівні для журналів рівня зневадження — перенесіть їх у холодний рівень збереження після семи днів, щоб зменшити вартість без повної втрати даних.”

** Структуроване ведення журналу ** — запис журналів як структурованих даних (зазвичай JSON) з послідовними назвами полів, а не як тексту вільної форми, щоб інструменти, що виконують послідовний аналіз, могли надійно аналізувати і запитувати поля.

• “Ця рядок журналу є форматованим рядком з ідентифікатором користувача, інтерполованим у вільний текст — переключитися на структурований журнал, щоб ми могли фільтрувати за user_id як за дійсним полем, а не за текстовим пошуком.” *

Звичайні фрази

• Чи є це проблемою кардиналізації — чи є позначка, що приймає занадто багато різних значень?»
• Чи є це ключем до розуміння, чи є це ключем до розуміння?»
• Чи це створює новий поток журналу на кожному розгортанні, і чи це навмисне?»
• «Де в інгаляційному трубопровіді відбувається редакція — до або після зберігання?»
• Чи повинні ці дані бути в горячому рівні зберігання, або вони можуть перейти в холодне зберігання раніше?

Приклади висловлювань

Перегляд запиту на звантаження: “Це додає ідентифікатор трасування як мітку — це створить новий потік для кожного запиту, залишимо ідентифікатор трасування в рядку журналу і скористаємося повнотекстовим пошуком замість цього.”

Пояснення рішення про проектування: “Ми реструктурували наш журнал, щоб використовувати невеликий, фіксований набір міток — служба, середовище і рівень — і пересунули все інше у структуровані поля в рядку журналу, що значно скоротило кількість потоків.”

Опис події:

• “Затримка запиту на панелі управління зменшилася після розгортання, оскільки було введено нове значення мітки для кожного перезапуску підсистеми — це перетворило декілька потоків на тисячі за одну ніч.” *

Професійні поради

• Використовуйте “кардинальність”, коли обговорюєте, чому запит або сам конвеєр є повільним — це стандартний діагноз і перша річ, яку перевіряє досвідчений інженер спостережливості.
• Під час перегляду коду журналювання, запитайте “це мітка або вміст рядка журналу?” — це одне питання запобігає більшості вибухів кардиналізації, перш ніж вони досягнуть виробництва.
• Використовуйте « структуроване ведення журналу » для опису практики виведення оброблюваних полів — це відрізняється від простого « додавання більшої кількості відомостей » до повідомлення журналу.
• Розрізняти “гарячі” і **“холодні” рівні зберігання ** явно, коли пропонується зменшення витрат - об’єднання їх просто з “зменшенням зберігання” пропускає варіант пониження вибірки замість вилучення.

Практичні вправи

1. Поясніть у двох реченнях, чому мітка з високою кардиналістю може зробити конвеєр журналу повільним і дорогим.
2. Написати коментар перегляду коду у одному реченні, у якому рекомендується вилучити значення з міток.
3. Опишемо вашими словами відмінність між рівнями зберігання гарячих і холодних даних.

Науковий ступінь: доктор технічних наук

Як розробник, що працює з конвеєрами спостережливості - чи це за допомогою таких інструментів, як Loki, Fluent Bit, або Vector - ви швидко усвідомите, що чітке спілкування про агрегування журналів і стратегії зберігання вимагає більше, ніж просто технічних знань. Вона вимагає вільності в конкретному англійському словнику і фразування. Часто основні концепції легко розуміються технічно, але при спробі пояснити їх зацікавленим сторонам (менеджерам продукту, командам операцій або навіть іншим розробникам), тонкі нюанси можуть бути втрачені в перекладі. Це не просто про використання більших слів; це про ефективне передання точного значення. Наприклад, заява «ми повинні зменшити логарифмічну значення» миттєво розуміється розробником, але може вимагати подальшого пояснення для когось, хто менш знайомий з технічними наслідками цього висловлювання. Аналогічно, обговорення «рівнів збереження» потребує ретельної артикуляції - чи говоримо ми про дні, тижні або місяці? Який вплив на вартість і можливості аналізу?

Однією з областей, де ця відмінність проявляється, є коментарі перегляду коду. Розробник може просто сказати: « Цей запит неефективний ». Хоча це технічно вірно, це не передає * чому * він неефективний. Краще формулювання - “Запит в даний час сканує весь поток журналу, що призводить до високої кардинальності і потенційних вузлів продуктивності” - надає контекст і дієву інформацію. Аналогічно, при описі запропонованої зміни конфігурації конвеєра у запиті на завантаження, простого вказівок « Оновити біт Fluent » недостатньо. Вам потрібно пояснити * що * ви оновлюєте (наприклад, “Поновити Fluent Bit, щоб налаштувати рівень зберігання журналу для потоку даних до 30 днів”) і * чому * - описуючи переваги цієї зміни з точки зору оптимізації витрат, поліпшення аналізу або зменшення операційних витрат. Це про те, як оформити технічні рішення в ширшому бізнес-контексті.

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

Ось приклад налаштування Fluent Bit для керування зберіганням журналів:

section: "FluentBit"
log_format: gELFv2
filters:
  - pattern: "/error/"
    tag: "errors"
outputters:
  - name: "Elasticsearch"
    url: "http://elasticsearch:9200"
    index: "fluentbit-%Y.%-m"
    retention_days: 30 # This sets the log retention tier to 30 days