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 <noreply@anthropic.com>

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 не бачить валідного `<PRI>` заголовка в сирому тексті 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:<ip>` у Search) — має впасти до звичайного рівня |
 
 ## Довідка: структура конфігурації