309d273f3f
All checks were successful
CI Trade-In / changes (pull_request) Successful in 8s
CI / changes (pull_request) Successful in 9s
CI / backend-tests (pull_request) Has been skipped
CI / frontend-tests (pull_request) Has been skipped
CI Trade-In / backend-tests (pull_request) Has been skipped
CI Trade-In / browser-tests (pull_request) Has been skipped
CI Trade-In / frontend-checks (pull_request) Has been skipped
CI / openapi-codegen-check (pull_request) Has been skipped
Метрик в проекте не было ни одной: ни экспортеров, ни /metrics в бэкендах, единственный канал наблюдения — journald, единственный сигнал об аварии — исключение в GlitchTip. Из-за этого целый класс отказов невидим в принципе: задача рапортует done, строк ноль, исключения нет. Так протухли данные на семь месяцев (#2998), 34 дня был мёртв house_imv_backfill (#2698), 8 суток писал ноль newbuilding_enrich (#2767), 91 день копилось раздутие listings (#2992). Grafana не заменяет GlitchTip: ошибки остаются там. Grafana OSS не принимает Sentry DSN ни одним компонентом, а скрубберы в before_send — требование 152-ФЗ. Здесь появляется другой класс данных: ряды и алерты по трендам. Наблюдатель поставлен у ДРУГОГО провайдера, чем наблюдаемое: серверная сторона на Beget, рядом с GlitchTip. Если ляжет Poincare, мониторинг должен об этом сказать, а не лечь вместе с ним. Транспорт push, а не pull: агент на Poincare шлёт remote_write и логи исходящим HTTPS, поэтому там не открывается ни одного входящего порта сверх 22/80/443. При обрыве канала Alloy копит в WAL и досылает — pull-скрейп в той же ситуации терял бы точки именно в аварии, ради которой мониторинг и нужен. Два контура доступа с разными учётками. Пароль приёмника по построению лежит открытым на продуктовом хосте, значит его компрометация неизбежна вместе с хостом; будь это учётка витрины, утёк бы и доступ к дашбордам. GlitchTip читается прямым SQL, а не Sentry-плагином: у плагина на 6.1.6 stats_v2 отдаёт 500 (баг GlitchTip #381), Events/Discover — 404 (#416), а в grafana/sentry-datasource слово glitchtip не встречается ни разу. Схема сверена на живой базе: колонка времени называется timestamp, а не received, и отдельной таблицы IssueIndex не существует — агрегаты лежат на самой issue_events_issue. Алерты за профилем alerts: канал доставки — открытый вопрос #3078, и стек не должен на нём стоять. Деплой предупреждает, что уведомлять пока некому. Каждая настройка, способная отказать молча, закрыта явно: ретенция Prometheus задана и по времени и по размеру, retention_enabled у компактора Loki (без него retention_period не работает вовсе), путь к журналу и запуск Alloy от root (иначе агент читает ноль записей без ошибки), проверка Caddy до перезагрузки (на этом хосте тот же Caddy держит git, errors и obsidian). Refs #3078
75 lines
3.3 KiB
YAML
75 lines
3.3 KiB
YAML
apiVersion: 1
|
||
|
||
# Источники данных задаются файлом, а не руками в интерфейсе: настройка, сделанная
|
||
# кликами, живёт только в томе и теряется при пересоздании контейнера — ровно та
|
||
# ловушка, из-за которой при переезде «healthy» ничего не значил.
|
||
|
||
datasources:
|
||
- name: Prometheus
|
||
uid: prometheus
|
||
type: prometheus
|
||
access: proxy
|
||
url: http://prometheus:9090
|
||
isDefault: true
|
||
jsonData:
|
||
# Совпадает со scrape_interval: иначе Grafana подбирает шаг сама и на
|
||
# длинных окнах рисует пилу там, где данные ровные.
|
||
timeInterval: 30s
|
||
httpMethod: POST
|
||
manageAlerts: false
|
||
editable: false
|
||
|
||
- name: Loki
|
||
uid: loki
|
||
type: loki
|
||
access: proxy
|
||
url: http://loki:3100
|
||
jsonData:
|
||
maxLines: 2000
|
||
# Связка логов с метриками по общей метке host.
|
||
derivedFields: []
|
||
editable: false
|
||
|
||
- name: Alertmanager
|
||
uid: alertmanager
|
||
type: alertmanager
|
||
access: proxy
|
||
url: http://alertmanager:9093
|
||
jsonData:
|
||
implementation: prometheus
|
||
handleGrafanaManagedAlerts: false
|
||
editable: false
|
||
|
||
# ── GlitchTip через ПРЯМОЙ SQL, а не через Sentry-плагин ────────────────────
|
||
# Плагин grafana/sentry-datasource официально документирован GlitchTip'ом, но
|
||
# на нашей 6.1.6 половина его путей нерабочая: stats_v2 с фильтром по проекту
|
||
# отдаёт 500 (открытый баг GlitchTip #381 с 2025-01-10), Events/Discover — 404
|
||
# (#416), Metrics/Spans/Tags вообще Sentry-only. В самом grafana/sentry-datasource
|
||
# слова «glitchtip» не встречается ни разу — апстрим эту связку не тестирует.
|
||
#
|
||
# Прямой SQL от этого свободен и правок в GlitchTip не требует вовсе, нужен
|
||
# только read-only пользователь. Схема проверена на живой базе 26.08:
|
||
# issue_events_issue несёт count / first_seen / last_seen / status / level,
|
||
# а issue_events_issueaggregate (issue_id, organization_id, date, count)
|
||
# партиционирована по неделям — ряды и топ-N без сканов сырья.
|
||
#
|
||
# ГРАНИЦА: доступ read-only. Тренды — здесь, а assign/resolve, стектрейсы и
|
||
# breadcrumbs — только в самом GlitchTip. Окна остаётся два: витрина и рабочее
|
||
# место, и это осознанно, а не недоделка.
|
||
- name: GlitchTip DB
|
||
uid: glitchtip-db
|
||
type: postgres
|
||
access: proxy
|
||
url: gendesign-infra-postgres:5432
|
||
database: glitchtip
|
||
user: grafana_ro
|
||
secureJsonData:
|
||
password: ${GLITCHTIP_RO_PASSWORD}
|
||
jsonData:
|
||
sslmode: disable
|
||
postgresVersion: 1600
|
||
timescaledb: false
|
||
maxOpenConns: 4
|
||
maxIdleConns: 2
|
||
connMaxLifetime: 14400
|
||
editable: false
|