2024 року я мав можливість працювати над проектом з спостереження, де я створив proof of concept на основі OpenTelemetry. Як SRE, я побачив можливість експериментувати з одним із найпопулярніших проектів CNCF по розподіленому трасуванню і запропонувати відкриту альтернативу для моніторингу продуктивності додатків моїх клієнтів. Мені випала можливість провести більш детальну презентацію цієї теми на KCD Accra Ghana та на OSMC 2024. Ви можете безпосередньо переглянути мої презентації на моєму Github репозиторії.
Архітектура
Ця конкретна архітектура спостереження в основному складалася з метрик Prometheus, Victoria Metrics, Grafana для візуалізацій та сповіщень, ELK для логів та комерційного постачальника APM. Фрагментована архітектура спостереження призводить до заплутаного досвіду для розробників і користувачів. Працюючи в сфері спостереження вже майже 5 років, можна легко сказати, що більшість людей надають перевагу єдиній панелі моніторингу, що дозволяє легше налаштувати та керувати.
Архітектура спостереження, яка пояснює, як K8s кластери відправляють метрики, сліди та логи
Щоб зосередитися на інфраструктурі і з’єднати все разом, я вирішив корелювати наші існуючі розгортання Argo CD з середовищами Kubernetes та OpenTelemetry.
Спостереження SRE
Я використовував офіційну документацію OTEL і репозиторій на GitHub для Helm чартів. Все йшло добре до того моменту, поки я не інтегрував otel collector. Однак додавання otel-collector до решти налаштувань Argo CD не спрацювало як треба з існуючими розгортаннями Kubernetes. Офіційна та неофіційна документація також не допомогли з усуненням несправностей, і щоб уникнути втрати ще більше інженерних годин, кращою альтернативою стало використання Jaeger operator для Kubernetes.
Документація та реалізація були набагато чіткішими, а технічна реалізація — прямолінійною. Однією з важливих деталей, що допомогли в цьому POC, було використання правильного ingress для Jaeger operator.
UI Jaeger
Коли розгортання Argo CD показало зелений статус і синхронізувалося, я інтегрував невеликий додаток з розгортанням Kubernetes і продовжив додавати мій джерело даних Jaeger у Grafana. Як користувачам Grafana OSS, мені було надано автономію для інтеграції, і мені сподобалося, що я міг самостійно розробити свою панель.
Проте кастомізація візуалізацій Grafana для Jaeger є досить складною. Оскільки я не працював у Grafana Cloud, де є багато готових візуалізацій, я в результаті створив дуже базову панель, де не можна об'єднати traceID в одній панелі, що призвело до наявності кількох панелей для кожного traceID.
До того, як досягти того рівня, на який можна було б порівнювати очікування від комерційних рішень для спостереження з відкритими платформами візуалізації, ще потрібно багато працювати.
Візуалізації в Grafana підтримують лише один Trace ID на панель
Спостереження розробників
Другим етапом мого POC було завдання розробникам реалізувати OTEL за допомогою їхніх специфічних SDK. Для цього POC ми використовували 2 додатки з SDK для .NET та PHP. Остаточний зворотний зв'язок зосередився на кількох недоліках:
- Офіційна документація OTEL інколи вводить в оману: функції, позначені як "необов'язкові", насправді дуже важливі й мають бути позначені як "рекомендовані". Наприклад, із вимкненим цією "необов'язковою" функцією ми спостерігали негайне погіршення продуктивності нашого додатку. Увімкнення її повернуло стабільність, однак не покращило ситуацію в порівнянні з тим, що було до додавання інструментації. Додавання інструментації OTEL також додає додаткове навантаження на додаток.
- OTEL досі не забезпечує автоматизоване середовище для розробників з розподіленим трасуванням. Подальша кастомізація та усунення несправностей — це одна з проблем, яку повинен враховувати розробник, і час, витрачений на це, має залежати від типу SDK, який використовується. Сигнали профілювання все ще знаходяться на етапі розробки для OTEL, і необхідна реалізація додаткових плагінів для SDK.
З урахуванням цих спостережень, ухвалення OTEL та Jaeger для виробничого середовища не отримало зелене світло. Однак proof of concept дуже добре продемонстрував, чому прийняття відкритих інструментів для розподіленого трасування є корисним методом для будь-якої архітектури спостереження в компанії.
Особисто для мене, гратися і експериментувати з OpenTelemetry було дуже корисно. Мені справді сподобалася співпраця між SRE та розробниками, відкритість до відкритих альтернатив і розуміння того, що існує цілий світ, окрім комерційних постачальників рішень для спостереження.
Оскільки опитування досвіду розробників OTEL відкрите для загального доступу до кінця січня 2025 року, я скористався можливістю подати свої спостереження. Не має значення, чи успішний буде POC або ні, чи буде він повністю впроваджений у виробничі середовища — є кілька основних висновків, які завжди повинні бути зафіксовані та досягнуті. Користувачі можуть отримати користь від тестування альтернатив відкритих проектів і краще розуміти свої цілі, а також спробувати нові технології та розібратися в поточному стані проектів OSS спільноти.
Оскільки ми всі прагнемо до готових рішень, в технологіях це займає час, а наші зусилля продовжувати рухатися вперед призводять до чудових результатів. OpenTelemetry, поряд з іншими проектами OSS, досягли досконалості завдяки відгукам своїх користувачів, і ми можемо пожинати ці плоди через роки після інвестування в постійні експерименти. Продовжуйте грати з технологіями та підтримувати спільноту OTEL!
Будь ласка, надішліть мені ваші відгуки через LinkedIn або на моєму Github репозиторії.
Перекладено з: I played with OTEL and I liked it