Мониторинг доступности сайтов

Обзор

Мониторинг сайтов — система blackbox-мониторинга, встроенная в DOP. Позволяет проверять доступность веб-сайтов, TCP-сервисов и DNS-записей из внешних точек наблюдения (зон).

Агент устанавливается на сервер за пределами кластера, получает конфигурацию из DOP, выполняет проверки и отправляет метрики обратно в DOP. Результаты доступны на дашбордах и через систему алертов.

Поддерживаемые типы проверок: HTTP, TCP/TLS, DNS, Ping (ICMP).

Быстрый старт

1. Убедитесь, что функция мониторинга сайтов включена (Admin → Settings → web_monitoring_enabled)
2. Создайте зону: Admin → Zones → New Zone (укажите имя, например world)
3. Создайте агента: Admin → Agents → New Agent (укажите имя и зону)
4. Скопируйте токен агента из карточки
5. Установите агент на внешний сервер (см. раздел Установка агента)
6. Перейдите в проект: Project → Web Monitoring → Add Site
7. Укажите домен, выберите зоны, добавьте пробу через preset «HTTPS Check», сохраните

Через 1–2 минуты на дашбордах появятся данные о доступности.

Основные понятия

Зоны

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

Создание зон: Admin → Zones → New Zone.

Сайты

Сайт — объект мониторинга: доменное имя или IP-адрес. Принадлежит проекту. Каждый сайт содержит одну или несколько проб и общие настройки (период, ping, зоны, лейблы).

Пробы и чеки

Проба — один запрос определённого типа (HTTP, TCP или DNS) к сайту. Каждая проба содержит один или несколько чеков — конкретных условий проверки (например, HTTP status = 200 или время ответа < 5s).

Агент выполняет все чеки при каждом срабатывании пробы и отправляет метрику gogomonia_test (1 = pass, 0 = fail) для каждого чека.

Лейблы

Лейблы — произвольные Prometheus-совместимые key=value пары, добавляемые к метрикам. Используются для группировки, фильтрации и управления алертингом.

Лейблы задаются на трёх уровнях:

• Сайт (site_labels) — добавляются ко всем метрикам сайта
• Сайт (check_labels) — добавляются ко всем проверкам сайта
• Чек (check_labels) — per-check лейблы, переопределяют site-level

Управление алертингом: лейбл alert=yes (по умолчанию) включает алерты, alert=no — отключает для конкретного чека.

Формат ключей: латинские буквы, цифры, подчёркивания; начинается с буквы или подчёркивания (/^[a-zA-Z_][a-zA-Z0-9_]*$/).

Типы проверок

Каждая проба (HTTP/TCP/DNS) содержит один или несколько чеков. Агент выполняет все чеки при каждом срабатывании пробы и отправляет метрику gogomonia_test (1 = pass, 0 = fail) для каждого чека.

Все pattern-поля (bodyMatch, contentType, answerMatch, location, headers.match, cookies.match) используют формат /regex/ (Go RE2-совместимый). Добавление ! после закрывающего слэша (/pattern/!) инвертирует результат (NOT match).

HTTP-чеки

status — Проверка HTTP status code

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

• Поле: список кодов через запятую
• Формат: целые числа 100–599 или regex в слэшах
• Примеры: 200 · 200, 301, 302 · /2[0-9]{2}/ (любой 2xx)

responseTime — Максимальное время ответа

Проверяет, что запрос выполнился быстрее порога. Чек срабатывает в реальном времени: если ответ не пришёл за max, тест помечается как fail ещё до завершения запроса.

• Поле: max — максимальная длительность
• Формат: число + единица: ms, s, m, h
• Примеры: 5s · 1500ms · 1m

bodyMatch — Regex-проверка тела ответа

Проверяет, что тело HTTP-ответа содержит (или не содержит) указанный паттерн. Полезно для проверки, что страница содержит ожидаемый контент и не показывает ошибку.

• Поле: regex
• Формат: /regex/ или /regex/! (NOT match)
• Примеры: /OK/ · /Welcome to/ · /error|maintenance/! (не должно содержать)

bodySize — Размер тела ответа

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

• Поле: min — минимальный размер
• Формат: число + единица: b, Kb, Mb, Gb
• Примеры: min 100b · min 1Kb · min 10Mb

contentType — Проверка Content-Type заголовка

Проверяет, что заголовок Content-Type в ответе соответствует ожидаемому. Используется для контроля, что сервер возвращает правильный тип контента, а не страницу ошибки.

• Поле: regex
• Формат: /regex/ или /regex/!
• Примеры: /text\/html/ · /application\/json/ · /image\/.*/

location — Проверка заголовка Location (редиректы)

Проверяет, что заголовок Location в ответе (при 3xx редиректах) соответствует паттерну. Полезно для проверки, что редирект ведёт на правильный URL.

• Поле: regex
• Формат: /regex/ или /regex/!
• Примеры: /https:\/\/example\.com\// · /\/login$/

sslBasicConstraintsValid — Проверка TLS-сертификата

Комплексная проверка TLS-сертификата: корректность BasicConstraints (CA-сертификаты должны иметь BasicConstraintsValid=true), срок действия leaf-сертификата (NotBefore / NotAfter), соответствие имени хоста (exact и wildcard *.example.com).

• Поля: нет (включается как boolean)

certValidDays — Срок действия сертификата

Проверяет, что TLS-сертификат не истечёт в ближайшие N дней. Используется для заблаговременного обнаружения истекающих сертификатов.

• Поле: min — минимум дней до истечения
• Формат: положительное целое число
• Примеры: 30 (предупредить за 30 дней) · 7 · 90

sslValidDays — Срок действия сертификата (альтернатива)

Аналогичен certValidDays. Нельзя использовать одновременно с certValidDays.

• Поле: min — минимум дней до истечения
• Формат: положительное целое число

headers — Проверка HTTP-заголовков ответа

Проверяет, что заголовки HTTP-ответа содержат указанные значения. Каждая пара: имя заголовка + regex для значения. Все пары должны совпасть (AND-логика).

• Поля: пары name / match
• name: имя заголовка (case-insensitive), например Content-Type, X-Request-Id
• match: regex /pattern/ или /pattern/!
• Примеры: name X-Request-Id match /^[a-f0-9-]+$/ · name Cache-Control match /no-cache/!

cookies — Проверка cookies в ответе

Проверяет, что cookies HTTP-ответа содержат указанные значения. Каждая пара: имя cookie + regex для значения. Все пары должны совпасть (AND-логика).

• Поля: пары name / match
• name: имя cookie, например session_id, csrf_token
• match: regex /pattern/ или /pattern/!
• Примеры: name session_id match /^[a-f0-9]{32}$/ · name lang match /^(en|ru)$/

TCP/TLS-чеки

connected — Проверка TCP-соединения

Проверяет, что TCP-соединение (и TLS-хэндшейк, если TLS включён) установлено успешно. Базовый чек доступности TCP-сервиса.

• Поля: нет (включается как boolean)

responseTime — Время установки соединения

Аналогичен HTTP responseTime, но измеряет время установки TCP-соединения (и TLS-хэндшейка при наличии).

• Поле: max — максимальная длительность
• Примеры: 5s · 2s

sslBasicConstraintsValid — Проверка TLS-сертификата

Аналогичен HTTP sslBasicConstraintsValid. Проверяет сертификат TCP/TLS соединения.

• Поля: нет (включается как boolean)

certValidDays — Срок действия TLS-сертификата

Аналогичен HTTP certValidDays. Проверяет сертификат TCP/TLS соединения.

• Поле: min — дней до истечения
• Примеры: 30 · 7

sslValidDays — Срок действия TLS-сертификата (альтернатива)

Аналогичен certValidDays. Нельзя использовать одновременно с certValidDays.

DNS-чеки

gotAnswer — Получен непустой DNS-ответ

Проверяет, что DNS-запрос вернул хотя бы одну запись. Базовый чек — домен резолвится.

• Поля: нет (включается как boolean)

answerMatch — Regex-проверка DNS-ответа

Проверяет, что хотя бы одна запись в DNS-ответе соответствует паттерну. Ответ содержит полную строку записи (например example.com. 300 IN A 1.2.3.4).

• Поле: regex
• Формат: /regex/ или /regex/!
• Примеры: /1\.2\.3\.4/ · /IN A/ · /IN MX.*mail\./

responseTime — Время DNS-запроса

Аналогичен HTTP responseTime, но измеряет время DNS-запроса.

• Поле: max — максимальная длительность
• Примеры: 2s · 500ms

Ping (ICMP)

Ping включается флагом ping: true на уровне сайта. Работает полностью независимо от проб — не требует ни проб, ни чеков. Встроенный тест ping.maxRtt проходит, если RTT < 500ms (порог захардкожен).

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

Создание зон

Зона — географическая или сетевая точка наблюдения. Каждый агент принадлежит одной зоне.

Создание: Admin → Zones → New Zone. Укажите имя зоны.

Создание сайтов

Путь: Project → Web Monitoring → Add Site.

Два режима формы

Форма создания/редактирования сайта работает в двух режимах.

Простой режим (по умолчанию для новых сайтов):

• Показаны основные поля: host, period, ping, зоны
• Добавление проб через presets (готовые шаблоны)
• Доступные чеки ограничены (см. таблицу ниже)
• TCP: упрощённый переключатель TLS

Расширенный режим (переключатель «Расширенный режим» внизу формы):

• Все дополнительные поля: hosts, probe_all_resolved_ips, site_labels, check_labels, request_defaults
• Полный набор типов чеков
• Группировка чеков
• Per-probe лейблы и period
• TCP: полная настройка TLS (insecureSkipVerify, serverName)

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

Доступные чеки по режимам

Группировка чеков

В расширенном режиме доступен переключатель «Группировать условия в проверки».

Без группировки (по умолчанию): каждый чек — отдельная проверка с собственным результатом (pass/fail) и собственным алертом.

С группировкой: несколько условий (status, bodyMatch, responseTime и т.д.) объединяются в одну логическую проверку с общим именем и общим алертом. Группе назначается уровень severity.

Пример: группа «https-health» может включать status=200 + bodyMatch="/OK/" + responseTime max=5s. При нарушении любого условия срабатывает один общий алерт.

Группировка включается автоматически, если сайт уже содержит чеки с несколькими условиями в одном config.

Параметры сайта

Presets

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

Требования к проектам

Для работы мониторинга сайтов у проекта должен быть API-токен с правом «Метрики: запись» (write_metrics). Этот токен создаётся автоматически при создании проекта.

Если токен удалён — в разделе Web Monitoring отображается предупреждение, а агент не получает конфигурацию для этого проекта.

Установка агента

Требования

• Linux (amd64)
• Сетевой доступ до DOP API (api.<domain>)

Ручная установка

1. Создать агента в Admin UI: Admin → Agents → New Agent (указать имя и зону)
2. Скопировать токен из карточки агента
3. На целевом сервере:

# Скачать бинарь
curl -o /usr/local/bin/gogomonia-agent \
  "https://update.<domain>/gogomonia-agent/storage/latest/linux/amd64/gogomonia-agent"
chmod +x /usr/local/bin/gogomonia-agent

# Конфиг
mkdir -p /usr/local/gogomonia-agent/etc
cat > /usr/local/gogomonia-agent/etc/config.yaml <<EOF
dop_api_url: "https://api.<domain>"
EOF

# Токен
echo -n "<TOKEN>" > /usr/local/gogomonia-agent/agent.token

# Запуск
/usr/local/bin/gogomonia-agent

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

Файл config.yaml:

dop_api_url: "https://api.dop.example.com"
proxy:
  url: ""          # HTTP proxy (опционально)
  no_verify_tls: false

Переменные окружения

Управление конфигурацией из Git

Утилита converter позволяет хранить конфигурацию сайтов в git-репозитории в декларативном YAML-формате с поддержкой Go-шаблонов и синхронизировать её с DOP через API. Это GitOps-подход: validate на merge request, sync на merge в master.

Скачивание

Бинарь: webmon-cli.

curl -o /usr/local/bin/webmon-cli \
  "https://update.<domain>/webmon-cli/storage/latest/linux/amd64/webmon-cli"
chmod +x /usr/local/bin/webmon-cli

Команды

Первый аргумент — команда: sync или validate. Параметры задаются только переменными окружения.

sync — синхронизация конфигов в DOP

Создаёт, обновляет и (при DELETE_ORPHANS=true) удаляет сайты в DOP по содержимому YAML-файлов.

export DOP_API_URL="https://api.<domain>/api/v1/observability"
export CONFIGS_DIR=/path/to/configs
export DOP_WEB_MON_TOKEN_MYPROJECT="<API-token>"
webmon-cli sync

validate — локальная валидация

Проверяет конфиги без применения: формат полей, допустимые ключи, deprecated поля, дупликаты. Загружает список зон из API для проверки.

export DOP_API_URL="https://api.<domain>/api/v1/observability"
export CONFIGS_DIR=/path/to/configs
webmon-cli validate

Важно: DOP_API_URL обязателен и для validate (загрузка зон). Токен для validate не требуется.

Глобальные переменные окружения

Маппинг проектов и токены

Для каждого каталога проекта задаются переменные окружения. Суффикс формируется из имени папки: все символы кроме букв и цифр заменяются на _, результат приводится к верхнему регистру.

Примеры: папка myapp → MYAPP, папка my-client → MY_CLIENT.

Структура репозитория

{team-repo}/
  .helpers/helpers.tpl       # общие Go-шаблоны (Sprig)
  {project}/conf.yaml        # конфигурация сайтов
  .gitlab-ci.yml

• Проект = любая папка, содержащая *.yaml файлы
• Шаблоны .tpl загружаются из COMMON_TEMPLATES и .helpers/ каталогов по пути вверх от папки проекта
• Шаблоны используют синтаксис Go text/template с библиотекой Sprig
• Конфиги рендерятся как шаблоны перед парсингом YAML

Формат conf.yaml

# Лейблы уровня юнита — добавляются ко всем сайтам
siteLabels:                      # опционально, map[string]string
  env: production
checkLabels:                     # опционально, map[string]string
  alert: "yes"

# Значения по умолчанию для всех сайтов
defaults:                        # опционально
  ping: "true"                   # "true"/"yes" → включить ping
  period: "20s"                  # формат: \d+(s|m), max 60s
  request:                       # defaults для HTTP-запросов
    scheme: https                # http / https
    timeout: 10s                 # формат: \d+(ms|s|m|h)
    headers:                     # массив {name, value}
      - name: User-Agent
        value: "monitoring/1.0"

# Список целей мониторинга (обязателен, минимум 1)
targets:
  - name: example-main           # ОБЯЗАТЕЛЬНО: уникальное имя сайта
    host: example.com            # ОБЯЗАТЕЛЬНО: домен или IP
    hosts:                       # опционально: фиксированные IP вместо DNS
      - 93.184.216.34
    probeAllResolvedIPs: "true"  # опционально: проверять все IP при DNS resolve
    period: 30s                  # override периода
    ping: true                   # override ping
    siteLabels:                  # merge с unit-level
      env: staging
    checkLabels:                 # merge с unit-level
      alert: "no"
    request:                     # override request defaults
      scheme: https
      timeout: 5s
    probes:                      # >= 1 проба, если ping=false
      - name: https-main         # ОБЯЗАТЕЛЬНО: уникальное, без пробелов/кавычек/скобок/пайпов
        period: 30s              # опционально: override периода
        siteLabels:              # опционально: merge с site-level
          component: api
        checkLabels:             # опционально: merge с site-level
          alert: "yes"
        request:                 # полная HTTP-конфигурация
          scheme: https
          path: /healthz
          method: GET            # GET, POST, PUT, DELETE, HEAD, OPTIONS, PATCH
          port: 443              # 1-65535
          timeout: 5s            # max 300s
          headers:
            - name: Accept
              value: application/json
          basicAuth:
            username: user
            password: pass
          data: '{"key":"value"}'
          disableHttp2ForHttps: "true"
        checks:                  # ОБЯЗАТЕЛЬНО: >= 1 чек
          - name: status-ok      # ОБЯЗАТЕЛЬНО: уникальное, без пробелов/кавычек/скобок/пайпов
            status: [200, 301]
          - name: response-time
            responseTime:
              max: 5s
          - name: body-check
            bodyMatch: "/OK/"
          - name: size-check
            bodySize:
              min: 100b
          - name: content-type
            contentType: "/text\\/html/"
          - name: ssl-check
            sslBasicConstraintsValid: true
          - name: cert-expiry
            certValidDays:
              min: 30
            checkLabels:
              alert: "no"

Legacy-формат: вместо targets можно использовать sites с ключами site (вместо host/name) и servers (вместо hosts). Оба формата поддерживаются, но targets — рекомендуемый. Совмещение site + host или servers + hosts в одной записи вызовет ошибку.

TCP-проба (вместо request):

        tcp:
          port: 443
          timeout: 5s
          tls:
            insecureSkipVerify: false
            serverName: example.com

DNS-проба (вместо request):

        dns:
          type: A                # A, AAAA, CNAME, MX, NS, TXT, SOA, SRV, PTR, CAA
          query: example.com     # ОБЯЗАТЕЛЬНО: домен для запроса
          timeout: 2s

Правила валидации:

• name и host — обязательные поля каждой цели
• Если ping: false и probes пусто — ошибка
• Тип пробы определяется наличием ключа: tcp: → tcp, dns: → dns, иначе http
• Зоны определяются из siteLabels.zone; пустые зоны = все зоны
• certVerify / sslVerify — deprecated, вызывают ошибку
• Неизвестные ключи на любом уровне — ошибка
• certValidDays и sslValidDays — нельзя использовать одновременно
• bodySize поддерживает только min (не max)
• responseTime поддерживает только max (не min)

CI/CD интеграция

Converter предназначен для использования в GitLab CI: validate на MR, sync на merge в master.

stages:
  - validate
  - apply

variables:
  DOP_CONVERTER_URL: "https://update.${DOP_BASE_DOMAIN}/webmon-cli/storage/${DOP_CONVERTER_VERSION}/linux/amd64/webmon-cli"

.download_converter: &download_converter
  image: alpine:${DOP_WEB_MONITORING_ALPINE_VERSION}
  before_script:
    - apk add --no-cache curl
    - curl -sSL -o webmon-cli "${DOP_CONVERTER_URL}"
    - chmod +x webmon-cli

validate:
  <<: *download_converter
  stage: validate
  variables:
    DOP_API_URL: "${DOP_API_URL}"
    CONFIGS_DIR: "."
  script:
    - ./webmon-cli validate

apply:
  <<: *download_converter
  stage: apply
  variables:
    DOP_API_URL: "${DOP_API_URL}"
    CONFIGS_DIR: "."
  script:
    - ./webmon-cli sync
  rules:
    - if: '$CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH'

Переменные CI/CD:

Важно: подставьте {FOLDER} в соответствии с именем каталога проекта после санитизации. Папка myapp → DOP_WEB_MON_TOKEN_MYAPP.

Метрики

Имена метрик используют технический префикс gogomonia_ — это внутреннее имя компонента, сохранённое для обратной совместимости.

Probe-метрики (per-project tenant)

Лейблы: instance, zone, project, site, server, probe, check, test

Agent selfmon-метрики

Лейблы: instance, zone, uuid, hostname, version

Дашборды

При включении мониторинга сайтов в проекте автоматически появляются дашборды:

• Overall Status — сводная таблица всех сайтов проекта: availability, response times, статус чеков
• Zone Status — детализация по зонам: per-zone метрики, сравнение доступности между зонами
• Site by Instance — drill-down по сайту: per-server/per-instance метрики, scatter-plot времени ответа

Дополнительные системные дашборды (Go Runtime, Logs) доступны для мониторинга здоровья самих агентов.