SnippetBook и Local Uptime Board

Приложение решает две задачи: хранит сниппеты, заметки и секреты в SnippetBook и контролирует доступность сервисов и почтовых доменов в Local Uptime Board. Оно работает как локальный Go-сервер с Gin, SQLite и vanilla JavaScript без frontend bundler. Секреты шифруются локальным AES-256-GCM ключом; синхронизация и multi-user режим не используются.

Запуск

go mod download
go run .

Откройте http://localhost:8080

Конфигурация

• PORT — порт (по умолчанию 8080)
• DB_PATH — путь к SQLite-базе; по умолчанию используется ./app.db в текущем каталоге запуска

Для проверки доступности приложения используйте публичный endpoint GET /healthz. Он возвращает статус процесса, версию сборки, commit, время сборки и uptime. Защищённый API-вариант доступен по адресу GET /api/v1/health.

HTML, CSS и JavaScript приложение отдаёт с Cache-Control: no-store, поэтому браузер каждый раз проверяет актуальную версию frontend. В ответах также доступны заголовки X-App-Version и X-App-Commit.

При release-сборке версию можно задать так:

make build VERSION=1.2.3 COMMIT="$(git rev-parse --short HEAD)" BUILD_TIME="$(date -u +%Y-%m-%dT%H:%M:%SZ)"

Возможности

• Записи трёх типов: сниппет, заметка, ключ/секрет
• Теги, поиск, избранное
• Шифрование ключей (AES-256-GCM, локальный ключ генерируется автоматически)
• Local Uptime Board для сервисов: CRUD, dashboard и проверки HTTP(s), SMTP(s), IMAP(s), POP3(s), MySQL, Redis(s), RabbitMQ/AMQP(s) и PostgreSQL
• Типы endpoint-проверок: HTTP(s), SMTP(s), IMAP(s), POP3(s), MySQL, Redis(s), RabbitMQ/AMQP(s) и PostgreSQL
• REST API /api/v1/...
• подробная диагностика каждого сбоя с сохранением в истории;
• AI-отчёты для Domains через OpenAI-compatible API;

Local Ops Board

Откройте /uptime после запуска приложения. Раздел позволяет добавлять важные сервисы, проверять их доступность, видеть response time и сохранять историю последних проверок. Включённые сервисы также проверяются автоматически в фоне. Для всех TLS/SSL-типов отображается дата окончания сертификата. Если до окончания осталось 21 день или меньше, сервис получает предупреждение и отправляется TLS alert в настроенные каналы уведомлений. Timeout и размер истории настраиваются на отдельной странице /uptime/settings и сохраняются в SQLite. Интервал задаётся отдельно для каждого сервиса. Если интервал не указан, используется 30s. При первой установке отсутствующие значения заполняются defaults: 30s, 10s, 500. После создания сервиса первая проверка запускается сразу, поэтому интерфейс не ждёт следующего таймера мониторинга.

Режим Карта показывает расположение публичных IPv4/IPv6 и текущие статусы сервисов. Геоданные ip-api.com кэшируются в SQLite по IP и обновляются в фоне раз в сутки. Бесплатный API работает по HTTP и разрешён только для некоммерческого использования. Настройка, ограничения точности и диагностика описаны в руководстве карты.

Для протоколов кроме HTTP(s) используются protocol-level проверки: SMTP/IMAP/POP3 проверяют greeting, Redis выполняет PING, MySQL и PostgreSQL выполняют подключение и SELECT 1, а RabbitMQ выполняет AMQP handshake. Учётные данные можно передать в URL подключения в стандартном формате scheme://user:password@host:port/database. Для каждого сервиса можно отдельно включить повторные уведомления об активной проблеме и задать интервал (30s, 5m, 1h). По умолчанию повторные уведомления выключены. Уведомление о начале проблемы и уведомление о восстановлении отправляются всегда.

Если Telegram включён в настройках уведомлений, после успешного запуска HTTP listener приложение отправляет сообщение СЕРВИС ЗАПУЩЕН с версией, commit и временем запуска, в том числе после деплоя. Отправка выполняется в фоне и не мешает работе сервера при ошибке Telegram. Подробности: уведомления о запуске.

Авторизация через Cloudflare Access

Production-доступ к /uptime и Ops API защищается Cloudflare Access. Приложение проверяет подписанный заголовок Cf-Access-Jwt-Assertion через публичные ключи команды Cloudflare, поэтому одного поддельного email-заголовка недостаточно.

Задайте переменные из .env.example:

CLOUDFLARE_ACCESS_TEAM_DOMAIN=https://my-team.cloudflareaccess.com
CLOUDFLARE_ACCESS_AUDIENCE=<application-audience-tag>

При пустых переменных авторизация отключена для локальной разработки. Если задана только одна переменная, запросы к защищённым маршрутам отклоняются с ошибкой конфигурации.

Приложение автоматически загружает файл .env из текущего каталога запуска. Создайте его на основе .env.example. Уже заданные переменные окружения имеют приоритет над значениями из .env.

Проверка домена доступна на /uptime/domain. Она анализирует MX, SPF, DKIM, DMARC и адреса почтовых серверов в DNSBL/RBL. Для DKIM укажите selector, например default или google. На этой же странице домен можно добавить в постоянный мониторинг: укажите интервал, после чего фоновый worker будет повторять проверку и сохранять результаты в историю. Проверка также получает регистрационные данные домена через RDAP, дату окончания регистрации и проверяет TLS-сертификаты MX-серверов на портах 25, 587 и 465. Изменение RDAP-снимка постоянного домена создаёт уведомление.

Настройки и уведомления

Страница /uptime/settings содержит три раздела: Настройки мониторинга, Общий канал уведомлений для Telegram, Slack и SMTP, а также Напоминания.

AI-анализ Domains

На странице /uptime/settings можно включить AI-отчёты и указать OpenAI-compatible Base URL, модель и лимит токенов. API-ключ не сохраняется в SQLite. Задайте его в .env:

AI_API_KEY=your-api-key

После проверки домена кнопка Сформировать AI-отчёт анализирует фактические результаты SPF, DKIM, DMARC, MX, MX TLS, RDAP и DNSBL/RBL. Отчёт содержит приоритеты проблем, рекомендации по DNS, план исправления и инструкции по delisting. AI не изменяет DNS, не отправляет запросы и не выполняет команды автоматически.

Скриншоты интерфейса

SnippetBook

Главная страница содержит поиск, фильтры, теги и список записей SnippetBook.

Local Uptime Board

Пустая панель показывает доступные разделы и кнопки добавления сервисов и почтовых проверок.

Панель отображает сводные статусы, фильтры, список сервисов, диагностику, последние ошибки и время ответа endpoint.

Добавление сервиса

Форма Новый сервис содержит название, тип проверки, endpoint, окружение, интервал, повторные уведомления, описание, теги и автоматический запуск проверок.

Список поддерживаемых типов включает HTTP(s), SMTP(s), IMAP(s), POP3(s), MySQL, Redis(s), RabbitMQ/AMQP(s) и PostgreSQL.

Domains

Страница /uptime/domain запускает проверку домена и позволяет добавить его в постоянный мониторинг.

Результат содержит Mail Health Score и показывает штрафы, применённые к отдельным проверкам.

Карточки диагностики показывают MX, MX TLS, SPF, DKIM, DMARC, DNSBL и регистрационные данные домена.

Настройки мониторинга

На странице /uptime/settings настраиваются timeout проверок, лимит истории и общие каналы уведомлений Telegram, Slack и SMTP.

Runbooks

Runbook — это инструкция по обслуживанию конкретного сервиса. Он хранится в SQLite как Markdown, привязан к сервису и доступен на странице его деталей в Ops Board. Runbook можно создавать, редактировать и удалять.

Рекомендуемая структура runbook:

• назначение сервиса и его критичность;
• владелец, команда и контакты для эскалации;
• зависимости: база данных, очереди, внешние API и DNS;
• health endpoint, ожидаемый HTTP-код и нормальный response time;
• типовые проблемы: timeout, HTTP 5xx, TLS error и недоступные зависимости;
• порядок диагностики;
• безопасные действия по восстановлению;
• rollback и проверка после восстановления;
• история изменений инструкции.

Пример:

# Runbook: Orders API

## Назначение

Orders API принимает и обрабатывает заказы пользователей. Критичность: высокая.

## Health check

Проверить `https://orders.example.com/health`. Ожидается HTTP `200` и response time менее `500 ms`.

## Зависимости

- PostgreSQL;
- Redis;
- Payment API;
- Auth API.

## Если сервис недоступен

1. Проверить последнюю проверку в Local Ops Board.
2. Проверить TLS-сертификат.
3. Проверить PostgreSQL, Redis и внешние API.
4. Сравнить время ошибки с последним изменением сервиса.

## После восстановления

1. Запустить ручную проверку в Ops Board.
2. Убедиться, что endpoint возвращает HTTP `200`.
3. Проверить response time и отсутствие новых ошибок.

Preview runbook отображает разобранный Markdown: заголовки, списки, code, bold, italic и безопасные ссылки. HTML экранируется, пользовательский JavaScript не выполняется, а размер Markdown ограничен. После сохранения runbook отображается таким же разобранным Markdown, а не исходным текстом. Сейчас приложение не требует обязательных разделов — содержание runbook можно адаптировать под сервис.

Уведомления

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

• Telegram Bot API: bot token и chat ID;
• Slack Incoming Webhook;
• email через SMTP.

Настройки каналов доступны в блоке Общий канал уведомлений на /uptime/settings и через API:

GET /api/v1/notification-settings
PUT /api/v1/notification-settings
POST /api/v1/notification-settings/test

В интерфейсе у каждого канала есть кнопка Сохранить и проверить. Она сначала сохраняет общую конфигурацию, затем отправляет тестовое сообщение только в выбранный канал. Тестовая отправка не создаёт запись о смене статуса сервиса.

Если канал включён, но настроен неполностью, приложение показывает ошибку в логах и продолжает проверять остальные сервисы и отправлять уведомления в остальные каналы. Секреты хранятся в локальной SQLite-базе приложения; не коммитьте файл базы в репозиторий.