Он построен на BPF LSM хуках и состоит из модульных детекторов, которые отслеживают процессы, файловые и сетевые операции, а также взаимодействие с eBPF-подсистемой ядра.

Самое интересное здесь — rule engine, который целиком работает внутри eBPF в отличие от Falco, где правила вычисляются в user mode части агента. Правила пишутся в YAML с булевыми предикатами (AND/OR/NOT, in, CIDR для IPv4/IPv6, списки и макросы). Каждое правило компилируется как программа: парсер строит AST,оптимизационные проходы его упрощают, а на выходе получается байткод в обратной польской записи. Байткод загружается в eBPF-мапы и исполняется прямо в ядре собственным RPN-интерпретатором. Поэтому фильтрация происходит до отправки событий в userspace, и накладные расходы минимальны. Для правил есть sandbox-режим в вариантах allow-list и deny-list, в отличие от Tetragon, где реализован только deny-list способ.

Отдельно стоит отметить детектор SysEnumMon, аналогов нет ни в Falco, ни в Tetragon. Обычно в eBPF-агентах одно срабатывание хука даёт одно событие. SysEnumMon работает иначе: он собирает наблюдения с нескольких хуков (запуск бинарей и открытие файлов), коррелирует их внутри дерева процессов в скользящем временном окне и принимает решение прямо в eBPF. Так он ловит сканеры вроде LinPEAS и LinEnum, хотя каждое их действие по отдельности (id, uname, чтение /etc/passwd) выглядит легитимно.

В Grafana Alerting появилась полезная штука для тех, у кого одним инстансом пользуются несколько команд.

Исторически маршрутизация уведомлений жила в одном общем дереве. Можно было выделить каждой команде свою ветку, но конфигурация всё равно оставалась общей. Хочешь поменять доставку алертов своего сервиса — правишь дерево, в котором живут и все соседи. С ростом числа команд удовольствие сомнительное.

В Grafana 13.2 в GA появились несколько независимых деревьев notification policies. Теперь можно завести отдельное дерево для команды или сервиса и явно направить в него алерты нужных правил. У каждого дерева — своё управление через UI, API или Terraform.

Самое полезное здесь — возможность раздельно менять и выкатывать настройки маршрутизации. Команда платежей правит свои маршруты, не затрагивая конфигурацию и состояние уведомлений платформенной команды.

Переносить всё разом тоже не требуется: существующие правила продолжат использовать политику по умолчанию, пока им не назначат другую.