Ви, напевно, чули цей термін Спостережливість останнім часом. У просторі моніторингу відбуваються фундаментальні зміни, і за цим стоїть спостережливість. Спостережливість сама по собі є широкою темою, тому в цій публікації ми поговоримо про те, що означає перейти від моніторингу продуктивності додатків до спостережливості продуктивності додатків .
МОНІТОРИНГ
ПРОДУКТИВНОСТІ ДОДАТКІВ Якщо ви використовували традиційну службу APM, імовірно, ви встановили бібліотеку у свою програму від цього постачальника APM. Ця бібліотека або агент потім збиратиме показники та сліди додатків, поки ваша програма працює у виробництві.
Трасування та метрики в APM Традиційні агенти APM
збирають детальні сліди про те, що відбувається під капотом, щоб ваш додаток обслуговував транзакції кінцевим користувачам. Але вони також значною мірою базуються на метриках. Вони генерують заздалегідь визначені, сукупні показники про ефективність програми в цілому. Такі показники, як пропускна здатність, середні значення часу відгуку та процентиль тощо. Мертвою роздачею щодо того, чи орієнтована послуга на моніторинг чи спостережливість, є переважна присутність інформаційних панелей для показників. Це не означає, що інформаційним панелям немає місця в інструменті спостережливості, але вони не повинні бути головною функцією. Ви не повинні витрачати значну кількість часу на налаштування або обслуговування інформаційних панелей.
Відсутність контексту Оскільки традиційні служби APM все ще значною мірою базуються на метриках, у даних бракує величезної кількості контексту
. Без контекстної інформації з кожного трасування програми неможливо задати важливі питання на кшталт «Що змінилося? Чому? На кого вплине?". Детальні сліди, зібрані за допомогою інструментів APM, вибираються на основі простої стратегії вибірки.
Питання
з довгим хвостомТрадиційний моніторинг додатків вміло вирішує проблеми продуктивності, які впливають на більшість користувачів. Проблеми з великою картиною, такі як «Сайт працює?» або «Чи 95% часу відповіді в межах нашої SLA?» можна відповісти за допомогою моніторингу. Питання з довгим хвостом можна вирішити лише за допомогою рішення спостережливості . "Покажіть мені всіх користувачів, які мали час відгуку понад наш поріг SLA в будь-який час цього місяця", "Час відповіді на 95% збільшився протягом останньої години. Відображати всі служби, які беруть участь в обслуговуванні цих запитів, і на яких впливають користувачі", "Користувач X має тривалий час завантаження на кінцевій точці Y. Покажіть мені всі сліди користувача X на кінцевій точці Y". Спостережливість дозволяє задавати ці питання та багато іншого про ваші програми.
Дубльовані зусилля
Провайдери APM написали агентів для динамічного введення коду в фреймворки додатків і бібліотеки, такі як Rails, Redis і MongoDB. Це дозволило збирати телеметричні дані з запущених додатків. Контрольно-вимірювальні прилади були складним, виснажливим і делікатним процесом, і кожен постачальник APM повинен був написати свій власний. Це призвело до марних зусиль у створенні інструментальних фреймворків та бібліотек.
Прилаштуйтеся на неякісну однопанельну панель
Підтримуються певні мови, надійність API, узгодженість угод про іменування та безліч факторів перешкоджають обміну або інтеграції даних моніторингу. Ops, Developers, SRE, DevOps мають свої улюблені інструменти. Кожен відповідно вибирав найкращий інструмент для задоволення своїх потреб у минулому, що призвело до поширення інструментів та послуг. Збираєтеся придбати цю єдину скляну шибку? Будьте готові до деяких серйозних компромісів принаймні для кількох із цих команд, щоб залучити всіх до одного сервісу.
СПОСТЕРЕЖЛИВІСТЬ ЗА ПРОДУКТИВНІСТЮ
ПРОГРАМИ Контекст з'єднує всіх
Замість того, щоб агент APM визначав, які агреговані показники збирати заздалегідь, збирайте кожен слід програми. Якщо потрібно, отримуйте показники з відстеження на вимогу. Наріжте кубики на грані контекстної інформації, що міститься в слідах на вимогу. Контекстні дані є наріжним каменем, щоб мати можливість задавати важливі питання спостережливості та відповідати на ці проблеми довгого хвоста.
Впровадження стандартів, крос-мови та кросплатформності є величезним заходом. Ви повинні мати можливість надіслати запит, щоб відповісти на свої запитання щодо спостережливості всіма мовами, які ви виконуєте у робочій версії. А також знайте, що контекст застосовується та розташовується в одному місці у ваших програмах. Структура, яка визначає ці стандарти, є обов'язковою для спостережливості.
Формування ландшафту
Obs Стандартизований пункт специфікації має тут величезний вплив. Ось список деяких типів портів зовнішнього інтерфейсу, які я пам'ятаю, що мені доводилося використовувати на комп'ютерах протягом багатьох років: Parallel, RS232, DB9, VGA, S-Video, DVI, DisplayPort, HDMI, MIDI, RCA, Component, Toslink, RJ11, RJ45, PCMCIA, SCSI, eSATA, AT, PS/2, Firewire. Так, у мене є коробка, повна кабелів для підключення до будь-якого з них, без PCMCIA...
Ви помітили, чого не вистачало в списку? Вірно, USB! Звичайно, у мене є мільйон USB-кабелів. Тому що все, що підключається до мого комп'ютера, тепер USB . Звичайно, різні форм-фактори, але протокол чарівним чином зворотно сумісний. Якщо ви можете зробити його придатним або перевернути його догори дном один-два рази - або більше - це просто працює! Це такий стандарт, за яким стояв кожен виробник периферійних пристроїв, тому що він так добре розроблений. Це величезна частина того, що формує ландшафт спостережливості і, нарешті, змушує переважну кількість постачальників і розробників підтримувати єдину специфікацію: OpenTelemetry .
Кореляції
Зупинюся тут на темі: стандартизація . Завдяки універсальному та послідовному розумінню того, що представляють дані, ми можемо встановити глибокі кореляції між додатками, мовами та стеком інфраструктури. Цей багатий контекст дозволяє машині допомагати в продуктивності та оперативному налагодженні, а не тільки в межах однієї програми.
Культура розвитку Зрушення
Спостережливість - це більше, ніж просто інструмент. Це не може дати вам всезнаючих сил, як у фільмі «Безмежний». Спостережливість повинна бути навмисно додана до вашого коду і стека. Розробники повинні не забути додати його під час написання та перегляду коду. Вони повинні ставити такі запитання, як "Чи потрібно це вимірювати?" або "Звідки я знаю, що це буде працювати належним чином?" Власні рішення APM можуть стати чудовим початком, але вам потрібно зробити спостережливість регулярною думкою у вашому коді. Не забудьте додати контекстну інформацію для подальшого перегляду трасування ефективності.
FACTORS ENABLING СПОСТЕРЕЖЛИВІСТЬ ЗА ПРОДУКТИВНІСТЮ
ПРОДУКТИВНОСТІ ДОДАТКІВ Економічно ефективні рішення для обчислень та зберігання даних для високої кардинальностіСпостережливість великих даних - це все про високу кардинальність та великі набори даних
. Вартість хмарних обчислень і зберігання досягла точки перегину. Тепер ми можемо використовувати ці хмарні сервіси для обробки на вимогу, щоб відповісти на запитання, які вимагає спостережливість, і надати їх за розумною ціною нашим користувачам.
API / SDK спостережливості з відкритим вихідним кодом.
Нарешті ми бачимо конвергенцію кількох конкуруючих стандартів, об'єднаних в один, з величезною підтримкою спільноти та галузі: OpenTelemetry ! Специфікація OpenTelemetry визначає специфікації міжмовних даних, включаючи API, SDK та транспортні протоколи. Вони формують нову «лінгва франка» для спостережливості, дозволяючи повному стеку говорити однією мовою, збирати дані в тому ж форматі і, в кінцевому рахунку, транспортувати ці дані для обробки. Щоб зробити спостережливість справді повсюдною, нам потрібна ця важлива частина головоломки.
СПОСТЕРЕЖЛИВІСТЬ ЗА ПРОДУКТИВНІСТЮ
ПРОДУКТИВНОСТІ ПРОГРАМИ OpenTelemetry вирівнює поле для збору, обробки та передачі телеметричних даних з багатим контекстом. Він робить це рівномірно для популярних мов і системних стеків. Це зосереджує цінність постачальників спостережливості, таких як TelemetryHub, на тому, яку інформацію та цінність ви можете отримати з цих нещодавно уніфікованих даних. Це переломний момент у ландшафті моніторингу та спостережливості, і наступні кілька років обіцяють бути надзвичайно цікавими.
При TelemetryHub , ми будуємо нову платформу Observability на основі OpenTelemetry. Наша увага зосереджена на наданні практичної інформації, яка швидко виявляє проблеми, надаючи вашим розробникам впевненість у вирішенні проблем продуктивності у все більш складних програмах та інфраструктурі.
