Моніторинг став дуже важливим компонентом зростаючих хмарних рішень із зростанням складності розподілених систем. Він необхідний розуміння їх поведінки. Потрібні інструменти, що масштабуються, які зможуть зібрати дані з усіх сервісів — і надати фахівцям єдиний інтерфейс з аналізом продуктивності, демонстрацією помилок, доступністю і журналами.
Ці ж інструменти мають бути ефективними та продуктивними. У цій статті ми розглянемо два популярні стеки технологій: EFK (Elasticsearch) та PLG (Loki) та розберемо їх архітектури та відмінності.
Стек EFK
Можливо, ви вже чули про дуже популярний ELK або EFK. Стек складається з декількох окремих частин: Elasticsearch (об'єктне сховище), Logstash або FluentD (збір та агрегація журналів) та Kibana для візуалізації.
Типова схема роботи виглядає так:
Elasticsearch - розподілене об'єктне сховище з пошуком та аналітикою в реальному часі. Чудове рішення для частково структурованих даних, наприклад, журналів. Інформація зберігається у вигляді документів JSON, індексується в режимі реального часу та розподіляється на вузлах кластера. Застосовується інвертований індекс, що містить усі унікальні слова та пов'язані з ними документи для повнотекстого пошуку, який у свою чергу ґрунтується на пошуковому движку Apache Lucene.
FluentD - Це збирач даних, що виконує уніфікацію даних при їх збиранні та споживанні. Він намагається впорядкувати дані в JSON наскільки це можливо. Його архітектура розширюється, існує більше , що підтримуються спільнотою, на всі випадки життя.
Кібана - Засіб візуалізації даних для Elasticsearch з різними додатковими можливостями, наприклад, аналізом тимчасових рядів, графів, машинним навчанням та іншим.
Архітектура Elasticsearch
Дані кластера Elasticsearch зберігаються розмазаними по всіх його вузлах. Кластер складається з кількох вузлів для покращення доступності та стійкості. Будь-який вузол може виконувати всі ролі кластера, але у великих розгортаннях, що масштабуються, вузлам зазвичай призначають окремі завдання.
Типи вузлів кластера:
- мaster node — керує кластером, потрібно щонайменше три, одна активна завжди;
- data node - зберігає індексовані дані та здійснює з ними різні завдання;
- ingest node – організує конвеєри для перетворення даних перед індексацією;
- coordinating node - маршрутизація запитів, скорочення фази обробки пошуку, координація масової індексації;
- alerting node - запуск завдань щодо оповіщення;
- machine learning node – обробка завдань машинного навчання.
На діаграмі нижче показано, як дані зберігаються і реплікуються вузлами для досягнення більш високої доступності даних.
Дані кожної репліки зберігаються в інвертованому індексі, нижче схема показує, як це відбувається:
Встановлення
Деталі можна переглянути я буду використовувати helm chart:
$ helm install efk-stack stable/elastic-stack --set logstash.enabled=false --set fluentd.enabled=true --set fluentd-elasticsСтек PLG
Не варто дивуватись, якщо не можете знайти цей акронім, адже його більше знають як Grafana Loki. У будь-якому випадку цей стек набирає популярності, оскільки застосовує вивірені технічні рішення. Ви, можливо, вже чули про Grafana, популярний інструмент для візуалізації. Її творці, надихаючись Prometheus, розробили Loki, що горизонтально масштабується високопродуктивну систему агрегації журналів. Loki індексує лише метадані, але не самі журнали, це технічне рішення дозволило йому стати простим в експлуатації та економічно вигідним.
Promtail - Агент для відправки журналів з операційної системи в кластер Loki. Grafana інструмент візуалізації на основі даних з Loki.
Loki побудований на тих же принципах, що і Prometheus, тому він добре підходить для зберігання та аналізу журналів Kubernetes.
Архітектура Loki
Loki може бути запущений як у режимі одного процесу, так і у вигляді кількох процесів, що забезпечує горизонтальне масштабування.
Також він може працювати як у вигляді монолітного додатка, так і у вигляді мікросервісу. Запуск у вигляді одного процесу може стати в нагоді для локальної розробки або для дрібного моніторингу. Для промислового застосування та масштабованого навантаження рекомендується використовувати мікросервісний варіант. Шляхи запису та читання даних розділені, так що його можна досить тонко налаштувати та масштабувати за потребою.
Погляньмо на архітектуру системи збору журналів без деталізації:
А тут опис (мікросервісна архітектура):
Складові частини:
Promtail - Агент, що встановлюється на вузли (у вигляді набору сервісів), він знімає журнали із завдань і звертається до API Kubernetes для отримання метаданих, якими будуть позначені журнали. Потім він надсилає журнал до основного сервісу Loki. Для порівняння метаданих підтримуються самі правила маркування, як і в Prometheus.
Дистриб'ютор - сервіс-розподільник, що працює як буфер. Для обробки мільйонів записів він здійснює упаковку вхідних даних, стискаючи їх блоками в міру їх надходження. Одночасно працює декілька приймачів даних, але журнали, що належать одному потоку вхідних даних, повинні виявитися тільки в одному з них для всіх його блоків. Це організовано у вигляді кільця приймачів та послідовного хешування. Для стійкості до відмов і надмірності воно робиться n разів (3, якщо не налаштовувати).
Ingester - Сервіс-приймач. Блоки даних надходять стиснутими з доданими журналами. Як тільки блок виявляється достатнього розміру, проводиться скидання блоку до бази даних. Метадані йдуть в індекс, а дані від блоку з журналом потрапляють до Chunks (зазвичай це об'єктне сховище). Після скидання приймач створює новий блок, куди додаватимуться нові записи.
індекс - база даних, DynamoDB, Cassandra, Google BigTable та інше.
Шматки — блоки журналів у стислому вигляді, зазвичай, зберігаються в об'єктному сховищі, наприклад, S3.
Querier - Шлях читання, що робить всю чорну роботу. Він дивиться діапазон часу та мітки, після чого дивиться індекс для пошуку збігів. Далі читає блоки даних та фільтрує їх для отримання результату.
А тепер давайте подивимося все у роботі.
Встановлення
Для встановлення в Kubernetes найпростіше скористатися helm. Вважаємо, що ви вже його поставили та налаштували ( прим. перекладача)
Додаємо репозиторій та ставимо стек.
$ helm repo add loki https://grafana.github.io/loki/charts
$ helm repo update
$ helm upgrade --install loki loki/loki-stack --set grafana.enabled=true,prometheus.enabled=true,prometheus.alertmanager.persistentVolume.enabled=false,prometheus.server.persistentVolume.enabled=falseНижче наведено приклад панелі інструментів, де показані дані з Prometheus для метрик Etcd і Loki для журналів подов Etcd.
А тепер обговоримо архітектуру обох систем, а також порівняємо їхні можливості між собою.
Порівняння
Мова запитів
У Elasticsearch використовують Query DSL і Lucene query language, які забезпечують можливість повнотекстового пошуку. Це потужний пошуковий двигун з широкою підтримкою операторів. З його допомогою можна шукати за контекстом та сортувати за релевантністю.
З іншого боку рингу — LogQL, застосовуваний в Loki, спадкоємець PromQL (Prometheus query language). Він використовує мітки журналів для фільтрації та вибірки даних журналів. Є можливість використовувати деякі оператори та арифметику, як описано Але за можливостями він відстає від Elastic language.
Оскільки запити Loki пов'язані з мітками — їх легко співвіднести з метриками, в результаті з ними простіше організувати оперативний моніторинг.
масштабованість
Обидва стеки горизонтально масштабуються, але з Loki це простіше, оскільки у нього розділені шляхи читання та запису даних, а також мікросервісна архітектура. Loki може бути налаштований під ваші особливості та може бути використаний під дуже великі обсяги даних журналів.
Мультиорендність
Мультиарендність кластера — загальна тема для скорочення OPEX, обидва стеки забезпечують мультиарендність. Для Elasticsearch є кілька розділення клієнтів: окремий індекс кожного клієнта, маршрутизація на основі клієнта, унікальні поля клієнта, пошукові фільтри. У Loki є у вигляді заголовка HTTP X-Scope-OrgID.
Вартість
Loki дуже ефективний економічно через те, що він не робить індексацію даних, а лише метаданих. Таким чином досягається і пам'яті (кеше), оскільки об'єктне сховище дешевше блочного, яке використовується в кластерах Elasticsearch.
Висновок
Стек EFK може використовуватися для різних цілей, забезпечуючи максимальну гнучкість та багатофункціональний інтерфейс Kibana для аналітики, візуалізації та запитів. Він додатково може бути покращений можливостями машинного навчання.
Стек Loki корисний в екосистемі Kubernetes через механізм виявлення метаданих. Можна легко порівняти дані для моніторингу на основі тимчасових рядів у Grafana та журналах.
Коли йдеться про вартість та тривале зберігання журналів, Loki є відмінним вибором для входу в хмарні рішення.
На ринку є більше альтернатив — деякі можуть бути кращими для вас. Наприклад, для GKE є інтеграція Stackdriver, яка забезпечує чудове рішення для моніторингу. Ми не включили їх у наш аналіз у цій статті.
Посилання:
Статтю перекладено та підготовлено для Хабра співробітниками - Інтенсиви, відеокурси та корпоративне навчання від практикуючих фахівців (Kubernetes, DevOps, Docker, Ansible, Ceph, SRE, Agile)
Джерело: habr.com