edge

Tero Edge — это легковесный высокопроизводительный телеметрический прокси, написанный на Zig, который применяет фильтрацию на основе политик (DROP/KEEP) к телеметрическим данным до их доставки. Он предназначен для работы вместе с OpenTelemetry Collector, а не для его замены, предлагая целенаправленную альтернативу для применения политик. Проект включает несколько предварительно сконфигурированных дистрибутивов (точек входа) для разных случаев использования: - **Полный дистрибутив**: обрабатывает приём данных Datadog и OTLP для логов и метрик. - **Дистрибутив Datadog**: ориентирован на конечные точки логов и метрик Datadog. - **Дистрибутив OTLP**: ориентирован на приём логов по протоколу OpenTelemetry. - **Дистрибутив Prometheus**: действует как прокси-сайдкар для сбора метрик Prometheus с потоковой фильтрацией. - **Дистрибутив Lambda**: расширение AWS Lambda для обработки телеметрии Datadog. - **Edge Tail**: файловый/потоковый трейлер для построчного копирования логов с возобновлением по контрольным точкам. Ключевые возможности включают: - Фильтрация на основе политик (DROP/KEEP) логов и метрик - Асинхронная загрузка политик (сервер запускается немедленно, пока политики загружаются в фоне) - Поведение fail-open (ошибки пропускают данные без изменений) - Обновление политик без блокировок через атомарные снимки - Корректное завершение работы с обработкой сигналов - Обработчик SIGSEGV для диагностики сбоев - Потоковая обработка ответов для Prometheus (ограниченная память) - Передача метрик, прошедших проверку политик, с нулевым копированием - Настраиваемые лимиты на сбор - Поддержка файловых и HTTP-провайдеров политик - Конечная точка метрик Prometheus на `/_edge/metrics` - Проектирование, ориентированное на данные, для когерентности кэша - Модульная структура пакетов с явными зависимостями ## Структура репозитория Исходный код организован в модульные пакеты: - `core/` — примитивы времени выполнения (лимиты, слой соединений, пул арен, ввод-вывод) - `frontend/` — входящий HTTP (фронтенды stdio и httpz) - `service/` — маршрутизация и планирование запросов по сигналам - `signals/` — типы записей протоколов (Datadog, OTLP, Prometheus) - `pipeline/` — фрейминг, кодеки и потоковый конвейер записей - `runtime/` — жизненный цикл процесса, дистрибутивы, метрики - `tail/` — слежение за файлами и stdin - `config/` — разбор конфигурации - `lambda/` — поддержка расширений AWS Lambda - `zonfig/` — конфигурация времени компиляции с переопределением через переменные окружения ## Сборка и запуск Соберите все цели с помощью `zig build`. Запустите тесты с помощью `zig build test`. Соберите конкретные дистрибутивы с помощью `zig build edge`, `zig build datadog`, `zig build otlp`, `zig build prometheus`, `zig build tail` или `zig build lambda`. Предварительно собранные бинарные файлы доступны для Linux x86_64, Linux ARM64 и macOS ARM64. Docker-образы доступны из GitHub Container Registry. ## Конфигурация Конфигурация выполняется через JSON-файл. Ключевые настройки включают: - `listen_address` / `listen_port` — адрес привязки сервера - `upstream_url` — целевой адрес по умолчанию - `logs_url` / `metrics_url` — необязательные конкретные URL-адреса - `workspace_id` — идентификатор рабочей области для синхронизации политик - `log_level` — уровень журналирования - `policy_providers` — список источников политик (файл/http) - `max_body_size` — лимиты тела запроса/ответа Переменные окружения, такие как `TERO_LOG_LEVEL`, могут переопределять настройки. ## Оценка размера и производительности В README включены таблицы размеров, показывающие использование CPU и памяти для различных размеров полезной нагрузки и частот запросов. Память в основном определяется количеством одновременных отправителей, а не частотой запросов. CPU масштабируется с количеством записей, а не запросов. Количество политик минимально влияет на производительность. ## Метрики Prometheus Метрики времени выполнения доступны на `GET /_edge/metrics` в текстовом формате Prometheus. Все метки являются ограниченными перечислениями для предотвращения взрыва серий. Метрики охватывают запросы, ответы, соединения, попытки восходящих сервисов, оценки политик и информацию о сборке. ## Принципы проектирования 1. **Проектирование, ориентированное на данные** — оптимизация для когерентности кэша и паттернов доступа к памяти 2. **Чтение без блокировок** — оценка политик использует атомарные указатели снимков для чтения без конкуренции 3. **Fail-Open** — ошибки при оценке политик приводят к пропуску данных, а не к их отбрасыванию 4. **Модульная композиция** — пакеты можно использовать независимо или комбинировать 5. **Явные зависимости** — каждый пакет объявляет свои зависимости через импорты