Система измерения качества сети (задержки, потери, джиттер) по протоколу TWAMP и обычному ICMP-ping. Центральный сервер раздаёт задачи зондирования распределённым пробам, собирает результаты, разбирает их в статистику и складывает в ClickHouse.
Рассчитана на масштаб ~10 000 одновременных задач на пробу.
Представьте: у вас сотни маршрутизаторов по всей стране, и нужно постоянно знать, какая до каждого из них задержка, есть ли потери пакетов и джиттер. Вручную это не сделать. SPI TWamp решает задачу так:
- Рядом с «интересными» участками сети ставятся пробы — лёгкие агенты, которые умеют запускать измерительные утилиты.
- В центре работает сервер — на нём оператор описывает, что, как часто и откуда измерять.
- Сервер раздаёт задачи пробам, пробы гоняют зонды по расписанию, результаты стекаются обратно на сервер, где превращаются в статистику и пачками уезжают в ClickHouse.
| Термин | Что означает |
|---|---|
| Проба (probe) | агент на измерительной площадке; исполняет задачи. Один статический бинарник на Go — ни .NET, ни зависимостей |
| Задача | «зондируй узел X с расписанием Y и параметрами Z»; живёт в БД сервера |
| Зонд | одиночный запуск измерительной утилиты (twping, twampy, ping) |
| Рефлектор | TWAMP-ответчик на измеряемом узле, «отражает» пакеты обратно |
| Шаблон | заготовка задачи; накладывается на список маршрутизаторов при массовой заливке |
| Результат | сырой вывод одного зонда; разбирается сервером в статистику |
| Сверка (reconcile) | фоновое выравнивание списка задач между сервером и пробой |
Полная документация вынесена в папку docs/ — так её удобно читать
по частям прямо на GitHub. Начните с нужного раздела:
| Раздел | О чём |
|---|---|
| 📖 Руководство пользователя | как пользоваться веб-интерфейсом: подключение проб, задачи, массовая заливка, отчёты, типовые сценарии |
| 🚀 Быстрый старт | установка из релизов или сборка из исходников (ниже на этой странице) |
| 🏗 Архитектура и процессы | устройство системы, схемы процессов, механизмы надёжности |
| ⚙️ Конфигурация | все настройки сервера и пробы, безопасность, производительность |
| 🧵 Сколько замеров одновременно | сколько зондов можно запускать сразу, почему один замер стоит процесса и потока, настройка CentOS на максимум |
| 📄 Форматы файлов | CSV шаблонов, маршрутизаторов, задач и отчёта |
| 🔌 HTTP API | все эндпоинты сервера и пробы |
| 📡 Режим TWampy | вторая утилита (nokia/twampy) и сходимость значений |
| 🐹 Проба на Go | лёгкая проба одним бинарником ~6 МБ |
| 🛠 Сборка, релизы, обновление | сборка из исходников, выпуск релизов, порядок обновления |
- Три режима зондирования: TWamp (
twpingот perfsonar), TWampy (nokia/twampy, TWAMP-Light на Python — вендорен в проекте) и системныйping; параметры командной строки задаются на задачу. Режим фиксируется в каждом результате и показан во всех таблицах и в отчёте (колонкаMode). Данные twampy разбираются в те же поля, что и twping, — отчёты и графики одинаковы независимо от утилиты (см. Как работать с TWampy). - Расписание: cron-выражения (с секундами при необходимости), период действия задачи, циклы/повторы/паузы.
- Индивидуальный таймаут каждого запуска зонда — процесс принудительно завершается (
Kill), факт фиксируется в результате. - Массовая заливка: файл шаблонов CSV × файл маршрутизаторов → тысячи задач одним запросом, с предпросмотром.
- Самонастройка пробы: чистая (переустановленная) проба автоматически получает все свои задачи от сервера.
- Гарантированная доставка результатов: пачки с подтверждением + дедупликация = «ровно один раз».
- Хранение измерений в ClickHouse: сервер копит результаты в дисковом буфере и переносит их пачками (по числу строк или по таймауту), после чего удаляет у себя. Если база недоступна — сегменты копятся, а исчерпав буфер, сервер приостанавливает опрос проб, и данные ждут на них (см. путь результатов).
- Отчёты CSV: потоковая выгрузка любой глубины, колонка
CallLine(фактическая команда) для однозначной идентификации ответа. - Мониторинг: страница статуса проб — связь, ошибки, версия, число задач.
- Полный цикл управления пробами: регистрация → подтверждение → обновление данных → удаление (с остановкой опроса и, по желанию, задач пробы); неопознанную пробу можно отклонить.
- Проба одним бинарником: ~6 МБ на Go, без .NET и внешних библиотек — работает на CentOS 7+, Rocky, Alma, Ubuntu, Debian и Windows, ставится службой одной командой (см. Проба).
- Встроенные зонды TWamp и TWampy: замер идёт прямо в процессе пробы, без запуска внешней утилиты. Такой замер не занимает ни процесса, ни потока ожидания, поэтому предел одновременных замеров на него не распространяется (см. Сколько замеров одновременно). Клиент TWAMP — библиотека twping-go, та же, из которой собрана утилита
twping. На 50 одновременных замерах: внешний путь — 50 процессов и 340 МБ, встроенный — ни одного процесса и 41 МБ, значения совпадают (измерения). - Ретенция: автоматическая очистка старых данных, БД не растёт бесконечно.
На странице релизов лежат готовые сборки для Linux x64 — самый быстрый способ попробовать систему:
# Сервер (самодостаточный — .NET на хосте не нужен)
tar -xzf twamp-server-*-selfcontained.tar.gz -C /opt/twamp-server
/opt/twamp-server/SPI.Twamp.Server
# Проба (на измерительной площадке) — один статический бинарник, .NET не нужен
tar -xzf twamp-probe-go-*-linux-x64.tar.gz -C /opt/twamp-probe
/opt/twamp-probe/twamp-probetwamp-server-*-framework.tar.gz — тот же сервер в 15 раз меньше, но на хосте нужен .NET 10 Runtime (ASP.NET Core).
Проба поставляется только сборкой на Go: она не требует рантайма и одинаково работает на Linux и Windows.
- Сервер: .NET 10 SDK (для сборки) или .NET 10 Runtime (для запуска); вариант selfcontained не требует ничего.
- Проба: Go 1.25 для сборки; на целевой машине — ничего.
- Для режима TWamp — утилита
twping(perfsonar); в linux-пакете пробы она уже лежит рядом. - Для режима TWampy — Python 3.8+ на пробе, либо встроенный отправитель
(
twampy:embedded), которому python не нужен. Сам twampy вендорен в проекте (папкаgo-probe/twampy/, копируется в пакет). - Windows или Linux: обе части ставятся службой (systemd или диспетчер служб Windows).
dotnet build SPI.TWamp.slnx -c Releasecd go-probe && go build .Публикация самодостаточного дистрибутива:
dotnet publish SPI.Twamp.Server -c Release -r linux-x64 --self-contained trueПроще всего взять готовый релиз и поставить службой одной командой — установщики лежат внутри каждого архива, и для сервера, и для пробы:
sudo ./install.shinstall.cmdПервый — для Linux (служба systemd, лимиты и настройки ядра), второй — для Windows (служба, порт в брандмауэре; права администратора запросит сам).
Установка и обновление — один скрипт: первый запуск ставит, каждый
следующий обновляет. Ваш appsettings.json при обновлении не заменяется —
значения остаются как есть, а появившиеся в новой версии настройки
добавляются рядом, и установщик их перечисляет. База данных и буфер
результатов не трогаются вовсе.
Вручную, из папки приложения:
# Проба (на измерительной площадке), по умолчанию порт 8443
./twamp-probe
# Сервер (в центре), по умолчанию порт 9000
dotnet SPI.Twamp.Server.dllПорты меняются ключом Urls в appsettings.json каждого приложения.
Схема процесса — в разделе «Архитектура». Кратко:
- Откройте веб-интерфейс сервера:
http://сервер:9000/. - На вкладке «Статус проб» введите адрес пробы (
http://адрес-пробы:8443) и нажмите «Опросить пробу» — проба появится в списке неопознанных. - Нажмите «Подтвердить» — сервер запустит опрос результатов и синхронизацию задач.
После этого можно создавать задачи: проба получит их автоматически.
Дальше — вся документация в docs/. Начните с руководства пользователя.