У динамічній інфраструктурі важливо мати віддалене зберігання логів додатків, адже їх життєвий цикл може бути коротким. Середовище додатку (наприклад, под, в якому додаток працює) банально вже може не існувати допоки інженер знайде час для дослідження проблеми. Тому цього разу поглянемо на роботу Fluent Bit в Kubernetes і як він здатен допомогти у вирішенні цієї задачі.
У 2014 році, розуміючи потребу в легкому процесорі логів для вбудованих систем на базі Linux, команда Fluentd в межах компанії Treasure Data створила Fluent Bit. Наразі він продовжує розвиватись під парасолею команди Fluentd як стабільний CNCF проєкт. Fluent Bit є дещо менш функціональним за материнський проєкт Fluentd, проте все ж пропонується як продукт наступної генерації.
Fluent Bit звісно не єдиний в своєму роді і ту ж роботу може виконати Grafana Alloy, Vector від Datadog, FileBeat від Elastic тощо.
1. KEY CONCEPTS
Для того, щоб рухатись далі, познайомимось із базовими концепціями Fluent Bit.
Кожен фрагмент логу, метрики, трейсу чи профайлу, що отримав Fluent Bit, називається Подією чи Записом (Event or a Record).
Для прикладу розглянемо вміст файлу Syslog:
Jan 18 12:52:16 flb systemd[2222]: Starting GNOME Terminal Server
Jan 18 12:52:16 flb dbus-daemon[2243]: [session uid=1000 pid=2243] Successfully activated service 'org.gnome.Terminal'
Jan 18 12:52:16 flb systemd[2222]: Started GNOME Terminal Server.
Jan 18 12:52:16 flb gsd-media-keys[2640]: # watch_fast: "/org/gnome/terminal/legacy/" (establishing: 0, active: 0)
Тож тут наведено 4 різні події, кожна із яких складається із наступних частин:
- позначка часу (timestamp)
- метадані ключ/значення (metadata)
- корисні дані (payload, message)
[[TIMESTAMP, METADATA], MESSAGE]
Основне завдання Fluent Bit - зробити запис структурованим, за потреби збагативши його корисними даними, і готовим до запису у віддалене сховище. Цей функціонал забезпечується плагінами, що можуть відповідати за збір даних (Input), фільтрацію (Filter), передачу (Output) тощо.