Як вибрати між APM та інструментом моніторингу кінця до кінця

Був час, коли APM був усім, хто був потрібен. Старі монолітні веб-сервіси відстежувалися за допомогою інструментів моніторингу продуктивності додатків (APM). Ці інструменти надають детальну інформацію про те, як працює веб-служба, і можуть попереджати адміністраторів про потенційні проблеми, перш ніж вони стануть широко поширеними. Таким чином, APM вивів нас з епохи того, щоб ваші користувачі були першими людьми, які помітили серйозну проблему. Натомість наші інструменти моніторингу могли б сказати нам, що проблеми назрівали заздалегідь.

Інструменти APM дають уявлення про ключові показники ефективності, такі як час відповіді, обсяг запиту, рівень помилок, використання ресурсів тощо. Ці дані можуть бути використані для виявлення проблем у виконанні коду, виявлення витоків пам'яті або будь-яких інших проблем, які можуть вплинути на продуктивність веб-служби.

І багато команд все ще використовують традиційний моніторинг додатків і дуже задоволені результатами!

Але ось кілька запитань, які слід задати про такі інструменти, як :

1. Чи прагнемо ми до відкритих стандартів?

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

2. Ми замкнені в одному постачальнику?

Нещодавній інцидент, пов'язаний зі спробою DataDog придушити комітацію OpenTelemetry, викликав значне занепокоєння щодо постачальників APM. Коли ці постачальники стверджують, що «приймають» відкриті стандарти, чи справді вони кажуть, що ми будемо споживати будь-які дані, які ви хочете нам надіслати, ви просто не можете забрати свої дані більше ніде».

Ці правила трохи нагадують нам про погані старі часи SaaS, коли видалити ваші дані з CRM або офісного інструменту було майже неможливо. Як компаніям APM так довго це сходило з рук? Ймовірно, тому, що портативність, в даному випадку, насправді не стосується портативності історичних даних. Подумайте про це: при перенесенні моніторингу на інший сервіс, ймовірно, не має значення, чи берете ви з собою дані про продуктивність за 2017 рік.

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

Якщо ви використовуєте інструмент APM, ви дійсно повинні погодитися з тим, що ви будете дотримуватися одного інструменту дуже довго, можливо, роками.

3. Наскільки монолітною є наша архітектура?

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

4. Скільки гнучкості та налаштування вам потрібно?

Однією з оригінальних точок продажу APM був чудовий досвід «з коробки». Встановлюючи на додаток Rails, ви отримуєте чудову карту свого інструменту протягом декількох годин. Але з будь-яким інструментом APM, який «з коробки» може почати відчувати, що ви «боксуєте».

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

За допомогою Open Telemetry, особливо з використанням колектора OpenTelemetry, ви можете надсилати, форматувати та переглядати дані зі своїх служб, незалежно від того, який у вас варіант використання.

Ваша архітектура визначає вашу долю

Вибір (і базовий проект OpenTelemetry, для якого побудований ) набагато простіше, якщо у вас є велика кількість мікросервісів. Скільки коштує велика кількість? На той час, коли у вас є десятки мікросервісів, кратних кількості розробників у вашій команді, настав час подумати про OpenTeleметрії.

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

Ось таблиця ключових відмінностей між і