Vector як альтернатива Logstash та Fluentd

💡 Усі статті, обговорення, новини про DevOps — в одному місці. Приєднуйтесь до DevOps спільноти!

Привіт, IT-спільното! Мене звати Дмитро Сірант, вже чотири роки я працюю на позиції СТО компанії OpsWorks Co. Сьогодні хочу поділитися з вами одним інструментом, який ми використовуємо на декількох проєктах. Нещодавно я проводив опитування і зрозумів, що не так багато технічних спеціалістів про нього знають та його використовують.

Мова піде про Vector. До речі, на нашому каналі DevOps Talks At OpsWorks я робив про нього англомовне відео.

Передісторія

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

Раніше для такого ми налаштовували syslog або syslog-ng на одному із серверів, а потім направляли всі інші сервери скидати логи через мережеве зʼєднання на нього. Туди вони потрапляли у вигляді тексту. Далі ми могли їх парсити за допомогою різних інструментів та генерувати алерти, базуючись на regex-правилах.

Залежно від кількості логів, ми налаштовували правила їх ротейту та архівування. До слова, мені в той час не доводилось створювати системи з високою доступністю, тому не можу нічого сказати про стратегію побудови систем active-active або active-passive для збору логів за допомогою syslog.

Обробляти, аналізувати та зберігати логи у вигляді текстових файлів не дуже зручно, тому інженери почали шукати інші шляхи. Відтак, як мінімум, дві системи збору логів стрімко набрали популярності: Graylog та ElasticSearch. Під капотом вони мають відмінності, але надають більш-менш однаковий інструментарій зі збору, аналізу та візуалізації логів.

Graylog використовує MongoDB для зберігання логів, а ElasticSearch використовує розподілену систему document-based з Lucene-індексами. ElasticSearch (та його послідовник OpenSearch) мають набагато більшу кількість користувачів. Це повністю збігається з моїм власним досвідом: наразі на жодному з 20+ активних проєктів в нашій компанії немає Graylog.

Гаразд, ми знаємо, куди ми хочемо складати логи для подальшого аналізу. Але яким чином нам їх підготувати до формату, який зможе використовувати ElasticSearch для індексації?

Проблема в тому, що кожен другий розробник або компанія використовували свій формат логів. Тоді ще не винайшли JSON, і всі логи були одним рядком тексту з різними роздільниками. Кожен з цих форматів мав свою назву, специфікацію та прихильників.

Ось лише кілька прикладів:

Common Event Format (CEF)

NCSA Common Log Format (CLF)

W3C Extended Log File Format (W3C)

JSON (якщо ваші логи лише в цьому форматі, я дуже вам заздрю :))

ElasticSearch побудований таким чином, що для кожного поля в індексі ви маєте завжди використовувати ідентичний тип даних (int, float, text, date, etc.). Тому перед тим, як передавати щось в ElasticSearch, нам треба підготуватися: привести тип даних до очікуваного. А це ще та задачка для неструктурованих або слабкоструктурованих форматів логів.

Для розв’язання цієї проблеми створили такі інструменти, як Logstash та Fluentd. Вони мають вбудовані функції для парсингу загальновідомих форматів логів, їх трансформації та передачі для подальшого зберігання.

Чого нам не вистачало

Оскільки наша компанія спеціалізується на AWS і Kubernetes, ми шукали систему, за допомогою якої можемо збирати логи як з K8s worker nodes, так і зі звичайних EC2-машин.

Однією з проблем, яку не вдалося вирішити свого часу, була можливість конфігурації Logstash або Fluentd для використання IAM Role з EC2-інстансу для авторизації в OpenSearch або Service Account з приєднаною роллю в EKS. Обидві системи створювалися в той час, коли віртуальні сервери лише почали зʼявлятися, і вони, як то кажуть, не були Cloud Native.

Окрім того, нас спіткала ще одна проблема: час від часу ElasticSearch cluster ставав недоступний. Це могло бути повʼязано з оновленням системи, нестачею місця на Data-нодах або проблемами з мережевим зʼєднанням. І оскільки Vector agent у нас міг бути на Spot-ноді, у випадку його ротації ми також втрачали логи.

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

Архітектура та приклади використання Vector

Перш за все, Vector — це сучасний інструмент для збору, трансформації та передачі в інші системи логів та метрик. Він написаний мовою програмування Rust, що робить його невибагливим до памʼяті та ефективним в плані утилізації процесорних ресурсів.

Vector, по своїй суті, це два компоненти:

• Vector agent. Він встановлюється максимально близько до точки генерації логів, наприклад, на віртуальну машину, на кожну EKS Worker Node за допомогою DaemonSet, або як Side Container у Pod.
• Vector aggregator. Він використовується як точка збору логів з agents (або інших джерел), їх трансформації, агрегації та передачі в іншу (інші) систему(-и).

Що цікаво, Vector постачається як єдиний бінарний файл і працює як agent або aggregator залежно від параметрів запуску та конфігурації.

Приклади деяких базових архітектур збору логів за допомогою Vector

На першій діаграмі Vector agent використовується для збору, трансформації та передачі логів в OpenSearch та S3 без використання aggregator.

Переваги такої архітектури:

• Простота, мало рухомих частин.
• Еластичність. Легко масштабується разом із вашим застосунком. Ресурси зростають залежно від масштабування.

Недоліки такої архітектури:

• Менш ефективна. Залежно від складності правил обробки ваших логів, вона використовуватиме більше локальних ресурсів, що може порушити роботу інших програм на тому ж хості.
• Не довговічна. Оскільки дані буферизуються на хості, більш ймовірно, що ви втратите буферизовані дані в разі невідновного збою. А часто це корисні, і чи не найважливіші дані.
• Більше навантаження на сервіси, куди відправляються логи. Ці сервіси будуть отримуватимуть більше запитів із меншим корисним навантаженням, що потенційно може порушити стабільність цих служб.

Наступна архітектура має окремий компонент — Vector aggregator.

Переваги такої архітектури:

• Більш ефективна. Централізовані топології зазвичай більш ефективні для клієнтських вузлів і сервісів, куди передаються дані. Vector agents виконують менше роботи, отже, використовують менше ресурсів. Крім того, у цій топології централізована служба Vector буферизує дані, забезпечує краще стиснення та надсилає оптимізовані запити до кінцевого місця зберігання даних.
• Більш надійна. Vector захищає кінцеві сервіси зберігання даних від надмірного обʼєму трафіку шляхом буферизації та очищення даних через згладжені інтервали.
• Має багатохостовий контекст. Оскільки дані централізовані, можна виконувати операції між хостами. Наприклад, зводити журнали до глобальних показників. Це може бути корисним для великих розгортань, у яких метрики, зібрані на багатьох хостах, є більш інформативними, ніж ізольовані для кожного хоста.

Недоліки такої архітектури:

• Складність. Централізована топологія має більше рухомих частин, оскільки вам потрібно запускати не тільки Vector agents, а і Vector aggregator.
• Довговічність. Вузли agent призначені для якнайшвидшого отримання даних з машини. Хоча це добре для деяких випадків використання, зберігається ймовірність втрати даних, оскільки центральна служба Vector може вийти з ладу.

Остання архітектура, яку я хочу навести, найбільш відмовостійка, але немає сенсу її розгортати для невеличких проєктів.

Переваги такої архітектури:

• Найбільш надійна. Потокові служби, такі як Kafka, створені для високої доступності та надійності, що досягається завдяки реплікації даних між кількома вузлами.
• Найбільш ефективна. Agents Vector роблять менше, а aggregator не потрібно турбуватися про доступність та зберігання даних.
• Має можливість повторної трансляції.
• Має чіткіший розподіл обов’язків. Vector використовується виключно як рівень маршрутизації та не несе відповідальності за довговічність.

Недоліки такої архітектури:

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

Ще більше інформації є на офіційному сайті.

Рішення, яке ми використовуємо на своїх проєктах

Тож ми шукали рішення, яке дозволить не втрачати логи, якщо наш кластер ElasticSearch не може їх зараз прийняти. На перший погляд, існує два варіанти:

1. Налаштувати Vector aggregator для проміжного зберігання логів.
2. Використовувати потокові сервіси, як-от Kafka або Kinesis.

Якщо перший варіант не забезпечує необхідної нам надійності (місце відведене під Vector aggregator може закінчитись або aggregator може бути перевантажений кількістю логів, які йому будуть приходити з agents), то в другому випадку додається дорогий сервіс, який ще потрібно обслуговувати та моніторити.

В Amazon найбільш надійним і відмовостійким сервісом є S3 — Simple Storage Service, який до того ж непогано масштабується. Vector agent може відправляти логи напряму в S3 і додавати інформацію про файли в AWS SQS — просту та ефективну чергу, яка ще й досить дешева порівняно з Kafka.

Виходить, що з agent ми можемо відправляти файли в S3, де вони будуть зберігатися якийсь час (наприклад 7 днів), а наш Vector aggregator має читати повідомлення з черги, завантажувати файл з S3, обробляти його і складати в ElasticSearch. Якщо ElasticSearch недоступний, Vector не відмітить повідомлення в черзі як «опрацьовано» і спробує його запроцесити через деякий час. Додатково така архітектура дозволяє нам автоматично збільшувати кількість Vector aggregators, відштовхуючись від розміру черги.

Єдиний мінус такого рішення — логи потрапляють в ElasticSearch із невеличкою затримкою, залежно від налаштувань. Проте, у нашому випадку п’ять-десять секунд затримки не є суттєвими.

Модуль Terraform для встановлення Vector в EKS

Оскільки ми використовуємо рішення на декількох проєктах, то розробили Terraform-модуль, який дозволяє створити всі необхідні компоненти, та встановити Vector agents і Vector aggregator в наявний EKS-кластер. З його допомогою можна швидко розгорнути тестове оточення і перевірити, як це рішення працює саме для вас. Ми також додали приклади з налаштування Vector aggregator із базовими трансформаціями для деяких логів, які збираються в EKS-кластері.

Модуль доступний з ліцензією open source. Якщо будете його використовувати, будь ласка, діліться фідбеком та пропозиціями стосовно функцій та їхньої роботи. Можете писати мені в LinkedIn або створюйте Github Issue.

Підсумки

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

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

Розкажіть у коментарях, що ви використовуєте для збору, обробки та зберігання логів, з якими проблемами стикаєтесь та як їх вирішуєте?