Один Go-бинарник, один YAML-файл, одна SQLite-база: как я написал свой инструмент мониторинга
One Go binary, one YAML file, one SQLite database: I wrote my monitoring tool
Автору нужно было следить за разнородными сервисами: HTTP, PostgreSQL, Oracle, Redis, Elasticsearch, ping и Prometheus-метриками, с уведомлениями в Telegram, SMS и Signal. Вместо развертывания платформы мониторинга (Prometheus + Alertmanager + Grafana) он написал Gjallar — KISS-сервис на Go: один статический бинарник (CGO_ENABLED=0), один YAML-конфиг и одна SQLite-база. Ключевые решения: чисто Go-драйверы для Oracle и PostgreSQL без C-библиотек, блокировок нет благодаря конвейеру «горутина на монитор → канал → один потребитель», состояние переживает перезапуски, уведомления асинхронны, а конфиг валидируется перед горячей перезагрузкой по SIGHUP. Инструмент намеренно не имеет кластеризации, агентов и плагинов, чтобы не превратиться в платформу, за которой нужен собственный мониторинг.
Инструмент, чье состояние целиком помещается в одном SQLite-файле, а поведение — в одном YAML-файле, — это инструмент, который вы все еще понимаете в три часа ночи через восемнадцать месяцев после того, как его написали.
- nzoschke
Один Go-бинарник + SQLite-база — и всё. Я использую эту архитектуру на single-tenant VM уже лет шесть, и у неё куча преимуществ для деплоя, безопасности и масштабирования. Практически каждая новая машина и агент, которые я настраиваю, используют этот паттерн. Я писал об этом в блоге и создал шаблонный репозиторий. https://housecat.com/blog/the-hugs-stack-hypermedia-unix-go-... https://github.com/housecat-inc/scratch
- JensRantil
Класс! Но ты допустил ошибку, использовав только маленькие буквы в имени репозитория. Файловые системы macOS будут ругаться, и могут возникнуть всякие странные вещи.
- aster0id
Недавно я наколдовал пару скриптов, запускаемых через cron, чтобы сделать то же самое для нескольких сервисов на одном узле. Работает отлично.