Модуль 9.6: Пошукові та аналітичні рушії (OpenSearch / Elasticsearch)

Складність: [COMPLEX] | Час на виконання: 2.5 год | Передумови: Модуль 9.2 (Брокери повідомлень), основи логування Kubernetes

Чому цей модуль важливий

У серпні 2023 року SaaS-компанія з 200 мікросервісами на EKS генерувала 12 ТБ логів на день. Вони запускали власний кластер Elasticsearch всередині Kubernetes — 12 потужних вузлів із швидкими дисками. Це коштувало $22 000 на місяць лише за сервери. Один інженер витрачав 30% свого часу на перерозподіл даних між вузлами, оновлення версій та тюнінг пам’яті Java. Коли вони спробували оновити версію, помилка в конфігурації “поклала” весь кластер на 4 години. Саме в ці 4 години команда безпеки не могла шукати логи під час реального інциденту.

Вони перейшли на керований Amazon OpenSearch Service. Переїзд зайняв три тижні. Тепер AWS сам замінює “хворі” вузли, робить бекапи та оновлює софт. Той самий інженер тепер витрачає на пошук 5% часу. А головне — за 14 місяців не було жодного незапланованого збою. Урок: запуск складного пошукового кластера в Kubernetes можливий, але операційні витрати величезні. Керовані сервіси дозволяють вам думати про дані, а не про залізо.

Цей модуль навчить вас будувати конвеєри збору логів (Logging Pipelines) із Kubernetes у керовані пошукові рушії. Ви дізнаєтеся, як налаштувати Fluent Bit, як автоматично видаляти старі дані для економії (Lifecycle Management) та як розмежувати доступ так, щоб кожна команда бачила логи тільки свого додатка.

Архітектура збору логів

Стандартний шлях лога в хмарі виглядає так:

Pod: пише лог у stdout/stderr.
Fluent Bit (DaemonSet): працює на кожному вузлі кластера, збирає логи з файлів, додає метадані (назву пода, неймспейс) і відправляє далі.
Buffer (Kafka/Kinesis): опційно. Якщо логів дуже багато, вони спочатку потрапляють у чергу, щоб не перевантажити пошуковий рушій.
OpenSearch / Elasticsearch: зберігає дані та дозволяє по ним шукати.

Управління життєвим циклом (ISM / ILM)

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

Hot Phase (0-3 дні): Логи на швидких SSD. Можна шукати миттєво.
Warm Phase (3-30 днів): Дані переносяться на дешевші диски. Пошук трохи повільніший.
Cold Phase (30-90 днів): Дані стискаються та архівуються.
Delete: Видалення логів через 90 днів (або інший термін за законом).

Шардинг: Як не “зламати” кластер

Дані в OpenSearch діляться на частини — шарди (shards).

Занадто малі шарди: Створюють велике навантаження на пам’ять кластера.
Занадто великі шарди (більше 50 ГБ): Пошук стає дуже повільним.

Золоте правило: Тримайте розмір шарда в межах 10-50 ГБ. Якщо ви пишете 100 ГБ логів на день — створіть індекс із 3-4 шардами.

Безпека: Document Level Security (DLS)

У великій компанії ви не хочете, щоб команда “Маркетингу” бачила логи “Платіжного шлюзу”. OpenSearch дозволяє налаштувати права так, що користувач при пошуку бачитиме тільки ті рядки, де поле kubernetes.namespace дорівнює його команді. Це дозволяє використовувати один великий кластер для всієї компанії безпечно.

Типові помилки

Помилка	Чому це стається	Як виправити
Один індекс на рік	”Так простіше шукати”	Величезні індекси неможливо обслуговувати. Використовуйте щоденні індекси або Rollover
Логування всього підряд	”На всяк випадок”	Фільтруйте логи у Fluent Bit. Не відправляйте логи успішних health-checks у хмару
Текстовий пошук по ID	Використання типу `text` для ID	Для ID, IP та неймспейсів використовуйте тип `keyword`. Це у 10 разів швидше
Відсутність лімітів пам’яті	Java (JVM) “з’їдає” все	Завжди моніторте JVM Heap Usage. Якщо воно > 80% — кластер скоро “впаде”

Тест

1. Чому Fluent Bit кращий за Fluentd для збору логів у Kubernetes?

Fluent Bit набагато легший. Він написаний на C і споживає в десятки разів менше оперативної пам’яті (кілька МБ проти сотень МБ у Fluentd). У кластері на 100 вузлів ця різниця стає дуже відчутною.

2. Що таке "Inverted Index" (інвертований індекс) в Elasticsearch?

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

Практична вправа: Аналітика логів

Налаштуйте Fluent Bit у вашому кластері для відправки логів у OpenSearch.
Створіть Index Pattern у дашбордах.
Напишіть запит, який показує топ-5 подів за кількістю помилок (level: “error”).
Налаштуйте ISM політику, яка автоматично видаляє логи через 7 днів для економії місця у вашому лабі.

Наступний модуль

Переходьте до Модуля 9.7: Конвеєри стрімінгових даних — ви навчитеся працювати з керованим Kafka (MSK), розберетеся з партиціями та навчитеся обробляти мільйони подій у реальному часі.