Семейство Beats: Filebeat и Metricbeat

Что такое Beats как семейство и чем Filebeat отличается от Metricbeat.

Beats — семейство лёгких одноцелевых агентов на Go, которые устанавливаются на источники и пересылают данные в Logstash или Elasticsearch.

Философия «один beat — одна задача»

Вместо одного тяжёлого универсального агента Elastic сделал набор маленьких. Каждый Beat собирает строго свой тип данных: Filebeat — лог-файлы, Metricbeat — метрики, Packetbeat — сетевые пакеты, Auditbeat — события аудита, Winlogbeat — журналы Windows, Heartbeat — доступность сервисов. Все они построены на общей библиотеке libbeat, поэтому конфигурация, форматы вывода и механизм доставки у них единые — выучив один, понимаешь остальные.

  libbeat (общая основа: вывод, очередь, доставка)
     |
     +-- Filebeat   -- лог-файлы
     +-- Metricbeat -- метрики ОС и сервисов
     +-- Packetbeat -- сетевой трафик
     +-- Winlogbeat -- журналы Windows
     +-- Heartbeat  -- пинги доступности

Filebeat — главный герой логирования

В контексте логов нас интересует прежде всего Filebeat. Он следит за файлами и стандартным выводом контейнеров и шлёт новые строки дальше. Filebeat потребляет считанные мегабайты памяти и почти не грузит CPU, поэтому его не страшно ставить на каждый прод-сервер. Подробно входы и модули Filebeat — в следующих уроках.

Metricbeat — на стыке с метриками

Metricbeat собирает метрики: загрузку CPU, память, диск, сеть, а также метрики конкретных сервисов (nginx, PostgreSQL, Docker) через модули. Важно: у нас есть отдельный учебник по мониторингу на Prometheus и Grafana, и Metricbeat — это «эластиковый» путь к тем же метрикам. В курсе про логи мы его лишь упоминаем как члена семьи: если вы уже строите метрики на Prometheus, Metricbeat вам, скорее всего, не нужен, а Filebeat для логов — нужен.

Как работает под капотом: общий путь доставки

Любой Beat внутри устроен одинаково: сборщик данных читает источник, события кладутся во внутреннюю очередь, затем publisher отправляет их в выход (Logstash или Elasticsearch) пачками. Если выход недоступен, очередь придерживает события и применяет backpressure — Beat замедляет чтение, чтобы не переполнить память. После подтверждения доставки события из очереди удаляются. Эта схема даёт «at-least-once» доставку: лучше повтор, чем потеря.

  источник --> [ сборщик ] --> [ очередь ] --> [ publisher ] --> выход
                                   ^                                |
                                   +-- backpressure при сбое выхода-+

Beats или Logstash на источнике?

Раньше на источники иногда ставили сам Logstash для сбора, но он тяжёлый (JVM, сотни МБ). Beats создавались именно чтобы заменить его на источнике лёгким агентом. Правило простое: на источнике — Beat (лёгкий сбор), в стороне — Logstash (тяжёлая обработка, если нужна).

Beats и общий стандарт полей

Отдельная ценность семейства Beats в том, что они изначально пишут данные по схеме ECS (Elastic Common Schema) — единому стандарту имён полей. Это значит, что IP-адрес источника во всех beat'ах называется одинаково (source.ip), имя хоста — host.name, и так далее. Когда логи от Filebeat и метрики от Metricbeat приходят с согласованными именами полей, их легко соотносить и строить общие дашборды. Эта стандартизация «из коробки» — большое преимущество перед самописными сборщиками, где каждый разработчик называет поля как придётся, и потом эти разнобойные имена приходится мучительно унифицировать на этапе обработки.

Стоит понимать и границы лёгкости Beats. Они нарочно простые: умеют читать, минимально парсить через процессоры и надёжно отправлять, но не предназначены для сложной обработки — ветвлений, обогащения из внешних баз, тяжёлых преобразований. Как только обработка перестаёт быть тривиальной, данные от Beats направляют в Logstash или в ingest-пайплайн Elasticsearch. Попытка нагрузить сам Beat сложной логикой через цепочки процессоров обычно заканчивается нечитаемой конфигурацией — это сигнал, что пора выносить обработку на следующий этап.

Частые ошибки

• Ставить Metricbeat ради логов. Metricbeat — про метрики, логи он не собирает. Для логов нужен Filebeat.
• Дублировать метрики. Если метрики уже идут в Prometheus, параллельный Metricbeat в ES — это лишние данные и расходы. Выбирайте один путь для метрик.
• Бояться нагрузки от Filebeat. Filebeat настолько лёгкий, что страх «он положит прод» необоснован; куда опаснее тяжёлая обработка на том же узле.

Итоги

• Beats — семейство лёгких одноцелевых агентов на общей основе libbeat.
• Filebeat собирает логи (наш главный инструмент), Metricbeat — метрики (пересекается с Prometheus).
• Внутри любого Beat: сборщик → очередь → publisher, с backpressure и доставкой at-least-once.
• На источнике ставят лёгкий Beat, тяжёлую обработку выносят на Logstash.