From 071d92000c604c6cfe208d8ea989a17ba43e255a Mon Sep 17 00:00:00 2001 From: byrsapty Date: Thu, 23 Jul 2026 15:43:51 +0300 Subject: [PATCH] Document Vector-side DHCP filtering to cut log volume before it hits Graylog Motivated by live capacity math: 2 active NAS servers measured at ~634 bytes/document in Graylog and ~75 msg/s each; projected to 10+ servers of similar profile that's ~38.5 GiB/day, which the current 50GB disk / 14-21 day retention can't hold. DHCP request/response chatter (Discover/Request/ Offer/Ack) is the bulk of that volume and isn't needed for RADIUS/ accounting analytics, so dropping it via a Vector `filter` transform (before the packet ever leaves the NAS server) is the cheapest place to cut it - no wasted network/disk/CPU on data nobody queries. Also cross-referenced two things diagnosed live earlier: the read_from: beginning cold-start replay burst, and where to look if a filtered-out message type stops appearing (intentional, not a bug). Co-Authored-By: Claude Sonnet 5 --- vector-accel-ppp-setup.md | 57 +++++++++++++++++++++++++++++++++++++++ 1 file changed, 57 insertions(+) diff --git a/vector-accel-ppp-setup.md b/vector-accel-ppp-setup.md index ecadc98..47b1751 100644 --- a/vector-accel-ppp-setup.md +++ b/vector-accel-ppp-setup.md @@ -13,6 +13,7 @@ - [Передумови](#передумови) - [Крок 1. Встановлення Vector](#крок-1-встановлення-vector) - [Крок 2. Базова конфігурація (приклад: accel-ppp)](#крок-2-базова-конфігурація-приклад-accel-ppp) +- [Крок 2b. (Опційно) Фільтрація DHCP-шуму](#крок-2b-опційно-фільтрація-dhcp-шуму) - [Крок 3. Права доступу (запуск від root)](#крок-3-права-доступу-запуск-від-root) - [Крок 4. Запуск та перевірка роботи](#крок-4-запуск-та-перевірка-роботи) - [Крок 5. Додавання інших джерел логів](#крок-5-додавання-інших-джерел-логів) @@ -138,6 +139,60 @@ Якщо є помилка — `vector validate` вкаже точний рядок і причину; не запускайте службу, поки ця команда не відповість без помилок. +## Крок 2b. (Опційно) Фільтрація DHCP-шуму + +**Навіщо:** `accel-ppp` при кожній оренді/оновленні DHCP пише повний +обмін (`recv [DHCPv4 Discover...]`, `send [DHCPv4 Ack...]` тощо) — це +основна частина обсягу логів, а не RADIUS/accounting-дані, заради яких +власне і збирається моніторинг. Порахували наживо на реальних цифрах +(2 активні NAS-сервери, ~634 байти/повідомлення в Graylog): при +масштабуванні до 10+ таких серверів це ~38.5 GiB/добу лише "сирих" даних +— диск, розрахований на 14-21 день retention, заповниться за лічені дні. +Прибирання DHCP на рівні Vector (до того, як пакет узагалі покине цей +сервер) — найдешевший спосіб скоротити обсяг, бо не витрачається ні +мережевий трафік, ні дисковий IO/CPU Graylog на індексацію того, що +однаково ніхто не шукає. + +Додайте `filter`-transform між `format_for_graylog` і `sinks`: + +```yaml +transforms: + format_for_graylog: + # ... як у кроці 2, без змін ... + + # Прибирає DHCP-обмін (Discover/Request/Offer/Ack) - основний обсяг + # шуму, не потрібний для RADIUS/accounting-аналітики. Умова true = + # повідомлення проходить далі; тут - "якщо НЕ містить маркер DHCPv4". + drop_dhcp_noise: + type: "filter" + inputs: + - "format_for_graylog" + condition: '!contains(string!(.message), "[DHCPv4 ")' + +sinks: + graylog_out: + type: "socket" + inputs: + - "drop_dhcp_noise" # було "format_for_graylog" - тепер через фільтр + address: "udp://10.254.254.202:5140" + mode: "udp" + encoding: + codec: "text" +``` + +Перевірка після зміни: + +```bash +vector validate /etc/vector/vector.yaml +sudo systemctl restart vector +sudo journalctl -u vector -f # переконайтесь, що йдуть RADIUS-рядки, а DHCPv4 - ні +``` + +Якщо для якогось джерела DHCP-дані навпаки потрібні (наприклад, окремий +DHCP-сервер, а не accel-ppp) — просто не додавайте `drop_dhcp_noise` у +ланцюжок цього джерела; фільтр застосовується лише до того `transform`, +який у нього `inputs`. + ## Крок 3. Права доступу (запуск від root) Лог-файли на кшталт `accel-ppp.log` часто мають права `600` (читає лише @@ -324,6 +379,8 @@ Graylog двічі з різними форматами. | Vector запускається, але не бачить оновлень файлу | Файл ротується (logrotate) інакше, ніж очікує Vector | Перевірте `include`/`ignore_older_secs`; за потреби додайте `fingerprint` налаштування у `source`, щоб Vector коректно стежив за файлом після ротації | | `vector validate` видає `error[E103]: unhandled fallible assignment` у `transform` | VRL вимагає явно гарантувати тип операнда перед конкатенацією/операцією (наприклад, `.message` без `to_string!()`) | Обгорніть проблемне поле в `to_string!(...)` (або іншу `!`-функцію відповідного типу) — саме так це вирішено в базовому конфізі кроку 2 | | Критичні алерти в Discord на рутинні `info`-повідомлення від Vector-джерела | Syslog UDP input не бачить валідного `` заголовка в сирому тексті Vector, тож Graylog проставляє severity `-1` ("невідомо") — а не 0-2 (справді критично) | Це вже виправлено на стороні Graylog (правило `generic_critical_severity` тепер явно виключає `level < 0`); якщо побачите знову — перевірте, чи не відкотилось це правило | +| DHCP-рядки більше не з'являються в Graylog | Це очікувано, якщо додано `drop_dhcp_noise` з кроку 2b | Перевірте `vector.yaml` — якщо DHCP-дані все ж потрібні, приберіть цей transform з ланцюжка `inputs` sink'у | +| Алерт "abnormal message volume" щойно після першого запуску Vector на новому сервері | `read_from: "beginning"` (крок 2) означає, що при першому старті Vector вичитує весь наявний лог-файл одразу, а не тільки нові рядки — одноразовий сплеск, не триваюча проблема | Перевірте обсяг від цього джерела через кілька хвилин (`gl2_remote_ip:` у Search) — має впасти до звичайного рівня | ## Довідка: структура конфігурації