# Observability Review — 2026-06-04

**Tool:** SigNoz
**Period:** last 24h (comparison: last 168h / 7 дней)

## Key Metrics

| Metric | Value (24h) | vs 7 days avg |
|---|---|---|
| Error rate | **0%** (0 / 20,688) | ↓ улучшение (1.42% / 1,598 ошибок за 7д) |
| Request volume | **20,688** span-ов | ↑ +70% vs вчера (12,147) / +29% vs 7д avg (16,033/день) |
| p99 latency (MCP SSE) | 4,849,132 ms (~81 мин) | long-lived SSE — ожидаемо |
| p99 latency (cron/refresh-tokens) | 313 ms | норма |
| p99 latency (GSC URL Inspection) | 6,407 ms (7д) | 🔴 критично (> 2s порог) |
| Slow DB queries (> 100 ms) | N/A — данных нет | issue #81 в работе |

## Findings

### Ошибки
- **0 ошибок за последние 24h** — третий день подряд с нулевым error rate.
- **GET 400: 167 запросов за 24h** (вчера: 0) — резкий спайк. Все 167 ошибок сосредоточены в сегодняшнем окне (в 7-дневных данных ровно столько же — 167). Вероятно, боты/сканеры или невалидные запросы к API.
- **POST 400: 1,434 за 7 дней** — доминирующий тип ошибки недели. В последние 24h только 6 таких ошибок — тренд снижается.
- HTTP 404: 9 GET + 4 POST за 7д — незначительно, фоновый шум.

### Латентность
- **`GET /api/mcp/[apiKey]`** p99 = 4,849 с — SSE keep-alive (долгоживущие соединения), ожидаемо.
- **`GET` (без маршрута)** p99 = 1,812 с — анонимный span без `http.route`. **Третий снапшот подряд.** Источник не идентифицирован.
- **Google Search Console URL Inspection** p99 = 6,407 ms за 7д — внешний API, но время ответа критически высокое.
- **`POST /api/cron/refresh-tokens`** p99 = 313 ms — в норме.
- **LinkedIn API** p99 = 435 ms — в норме.

### База данных
- `slow_db_queries: []` — DB-запросы по-прежнему не трекаются в SigNoz.
- Issue #81 создан ранее — ожидает реализации.

### Объём трафика
- 20,688 span-ов за 24h vs 12,147 вчера — рост +70%.
- 7-дневный baseline ~16,033/день. Сегодня на 29% выше нормы.
- Без разбивки по маршрутам сложно определить источник роста.

## Recurring Issues

- **Анонимный спан `GET` (p99 ~30 мин)** — 3-й снапшот подряд. Вчера рекомендовано создать issue — создан сегодня.
- **Отсутствие DB-инструментации** — повторяется с 31 мая (5-й снапшот подряд). Issue #81 должен быть взят в работу.

## Hypotheses

- **Спайк 167×GET 400** — появился резко, весь объём в одном 24h-окне. Возможны: автоматические сканеры (Shodan, GreyNoise), невалидные API-клиенты, или изменение в поведении существующих интеграций. Необходима атрибуция по User-Agent / IP.
- **Рост объёма трафика +70%** — может коррелировать со спайком GET 400. Если оба явления от ботов — блокировка решит оба. Мониторить в следующем снапшоте.
- **Анонимный GET span** — вероятно, входящее long-lived соединение к внешнему WebSocket или Server-Sent Events (не MCP). Возможный кандидат: OpenRouter streaming endpoint.

## Recommendations

1. **[P2 — создан issue]** Расследовать источник 167 GET 400 — добавить логирование User-Agent / IP для незнакомых запросов.
2. **[P2 — создан issue]** Идентифицировать анонимный GET span (3-й снапшот) — добавить атрибуты к исходящим fetch-спанам.
3. **[P2 — создан issue]** Оптимизировать Google Search Console URL Inspection API — кэшировать результаты или добавить таймаут/fallback.
4. **[P2 — issue #81]** Добавить Prisma OTel instrumentation — без неё слепые зоны по DB.
5. **[Мониторить]** Рост трафика +70% — если продолжится завтра, создать issue.
