Dokumentacja API
Dokumentacja API: Monitorowanie i AI
Ta strona dokumentuje usługę Monitorowania (openapi-monitor.yaml, port 8085) oraz proxowane usługi AI Copilot, Silnika Migracji i konektorów CDC. Usługa Monitorowania udostępniana jest pod ścieżką /api/v1 i wymaga tokenu JWT bearerAuth na każdym endpoincie.
Panel
Endpointy panelu agregują metryki platformy, stan konektorów oraz stan systemu.
| Method | Path | Operation ID | Przeznaczenie | Auth |
|---|---|---|---|---|
| GET | /api/v1/monitor/dashboard | getDashboard | Zagregowane metryki panelu | JWT |
| GET | /api/v1/monitor/pipelines/{id}/metrics | getPipelineMetrics | Szczegółowe metryki potoku (percentyle, SLA) | JWT |
| POST | /api/v1/monitor/pipelines/run | recordPipelineRun | Wewnętrzny — rejestracja wyniku uruchomienia potoku | JWT |
| GET | /api/v1/monitor/connectors/health | getConnectorsHealth | Statusy stanu konektorów + podsumowanie | JWT |
| POST | /api/v1/monitor/connectors/health | recordConnectorHealth | Wewnętrzny — rejestracja kontroli stanu konektora | JWT |
| GET | /api/v1/monitor/system/health | getSystemHealth | Stan systemu (CPU/pamięć/dysk/wątki/usługi) | JWT |
DashboardMetrics zawiera totalPipelinesRun, successRate, avgDurationMs, rowsProcessed, activeAlerts, pipelinesByStatus, recentRuns[], topErrors[], connectorHealth[], timeSeriesData[]. PipelineMetricsDetail dodaje czasy trwania p50/p95/p99 oraz slaComplianceRate.
// GET /api/v1/monitor/dashboard → 200 OK (DashboardResponse)
{
"totalPipelinesRun": 1284,
"successRate": 0.973,
"avgDurationMs": 184200,
"rowsProcessed": 9821044,
"activeAlerts": 3,
"pipelinesByStatus": { "SUCCESS": 1249, "FAILED": 28, "RUNNING": 7 },
"recentRuns": [],
"topErrors": []
}
// GET /api/v1/monitor/pipelines/{id}/metrics → 200 OK (PipelineMetricsDetail)
{
"pipelineId": "f47ac10b-58cc-4372-a567-0e02b2c3d479",
"p50DurationMs": 162000,
"p95DurationMs": 240000,
"p99DurationMs": 318000,
"slaComplianceRate": 0.991
}
Uwaga
recordPipelineRun i recordConnectorHealth to wewnętrzne endpointy przyjmowania danych używane przez samą platformę. Są udokumentowane dla kompletności, ale nie są przeznaczone do bezpośredniego użycia przez klienta.
Alerty
Endpointy alertów zarządzają poszczególnymi rekordami alertów, w tym operacjami zbiorczymi, historią i czyszczeniem.
| Method | Path | Operation ID | Przeznaczenie | Auth |
|---|---|---|---|---|
| GET | /api/v1/monitor/alerts | getAlerts | Lista alertów | JWT |
| POST | /api/v1/monitor/alerts | createAlert | Utworzenie alertu | JWT |
| GET | /api/v1/monitor/alerts/{id} | getAlert | Pobranie alertu po ID | JWT |
| DELETE | /api/v1/monitor/alerts/{id} | deleteAlert | Usunięcie alertu | JWT |
| POST | /api/v1/monitor/alerts/{id}/ack | acknowledgeAlert | Potwierdzenie alertu | JWT |
| POST | /api/v1/monitor/alerts/{id}/resolve | resolveAlert | Rozwiązanie alertu | JWT |
| POST | /api/v1/monitor/alerts/bulk/ack | bulkAcknowledge | Zbiorcze potwierdzanie alertów | JWT |
| POST | /api/v1/monitor/alerts/bulk/resolve | bulkResolve | Zbiorcze rozwiązywanie alertów | JWT |
| GET | /api/v1/monitor/alerts/history | getAlertHistory | Historia alertów | JWT |
| GET | /api/v1/monitor/alerts/summary | getAlertSummary | Podsumowanie liczby alertów | JWT |
| POST | /api/v1/monitor/alerts/purge | purgeResolved | Czyszczenie starych rozwiązanych alertów | JWT |
getAlerts przyjmuje status, severity, category oraz limit (domyślnie 100). getAlertHistory przyjmuje category oraz sinceSeconds (domyślnie 86400). purgeResolved przyjmuje olderThanSeconds (domyślnie 604800). Alert.severity: CRITICAL | WARNING | INFO; status: ACTIVE | ACKNOWLEDGED | RESOLVED; category: PIPELINE_FAILURE | PERFORMANCE_DEGRADATION | SECURITY_VIOLATION | DATA_QUALITY | SYSTEM_HEALTH | SLA_BREACH.
// POST /api/v1/monitor/alerts → 201 Created
// Request: CreateAlertRequest
{
"title": "Pipeline billing-daily-load failed",
"severity": "CRITICAL",
"category": "PIPELINE_FAILURE",
"message": "Task 'load' failed after 3 retries"
}
// POST /api/v1/monitor/alerts/bulk/ack → 200 OK
// Request: BulkAlertRequest
{ "alertIds": ["al-0001", "al-0002", "al-0003"] }
// GET /api/v1/monitor/alerts/summary → 200 OK (AlertSummaryResponse)
{
"active": 3,
"acknowledged": 5,
"resolved": 142,
"bySeverity": { "CRITICAL": 1, "WARNING": 2, "INFO": 0 }
}
Definicje alertów
Definicje alertów to reusowalne reguły, które silnik ocenia w celu generowania zdarzeń alertów.
| Method | Path | Operation ID | Przeznaczenie | Auth |
|---|---|---|---|---|
| GET | /api/v1/monitor/alerts/definitions | getDefinitions | Lista definicji alertów | JWT |
| POST | /api/v1/monitor/alerts/definitions | createDefinition | Utworzenie definicji alertu | JWT |
| GET | /api/v1/monitor/alerts/definitions/{id} | getDefinition | Pobranie definicji | JWT |
| PUT | /api/v1/monitor/alerts/definitions/{id} | updateDefinition | Aktualizacja definicji | JWT |
| DELETE | /api/v1/monitor/alerts/definitions/{id} | deleteDefinition | Usunięcie definicji | JWT |
| POST | /api/v1/monitor/alerts/definitions/{id}/toggle | toggleDefinition | Włączenie/wyłączenie definicji | JWT |
| POST | /api/v1/monitor/alerts/definitions/{id}/silence | silenceDefinition | Tymczasowe wyciszenie definicji | JWT |
getDefinitions przyjmuje type oraz enabled (bool). AlertDefinition.type: PIPELINE_FAILURE | SLA_BREACH | DATA_QUALITY | ROW_COUNT_ANOMALY | CONNECTION_DOWN | RESOURCE_THRESHOLD. Każda definicja zawiera AlertCondition (metric, operator ∈ GREATER_THAN | LESS_THAN | EQUAL | …, threshold, windowMinutes, consecutiveFailures) oraz recipients[] (NotificationRecipient z channel ∈ EMAIL | SLACK | PAGERDUTY | WEBHOOK).
// POST /api/v1/monitor/alerts/definitions → 201 Created
// Request: AlertDefinition
{
"name": "Billing SLA breach",
"type": "SLA_BREACH",
"enabled": true,
"condition": {
"metric": "duration_ms",
"operator": "GREATER_THAN",
"threshold": 300000,
"windowMinutes": 60,
"consecutiveFailures": 1
},
"recipients": [
{ "channel": "PAGERDUTY", "target": "routing-key-billing" }
]
}
// POST /api/v1/monitor/alerts/definitions/{id}/silence → 200 OK
// Request: { "durationMinutes": 120 }
{
"id": "def-0001",
"name": "Billing SLA breach",
"enabled": true,
"silencedUntil": "2025-12-15T16:30:00Z"
}
Zdarzenia alertów
Zdarzenia alertów to poszczególne wyzwolenia generowane przez silnik, gdy warunek definicji zostanie spełniony.
| Method | Path | Operation ID | Przeznaczenie | Auth |
|---|---|---|---|---|
| GET | /api/v1/monitor/alerts/events | getEvents | Lista zdarzeń alertów wygenerowanych przez silnik | JWT |
| GET | /api/v1/monitor/alerts/events/{id} | getEvent | Pobranie zdarzenia alertu | JWT |
| POST | /api/v1/monitor/alerts/events/{id}/ack | acknowledgeEvent | Potwierdzenie zdarzenia | JWT |
| POST | /api/v1/monitor/alerts/events/{id}/resolve | resolveEvent | Rozwiązanie zdarzenia | JWT |
| POST | /api/v1/monitor/alerts/events/{id}/silence | silenceEvent | Wyciszenie zdarzenia | JWT |
| GET | /api/v1/monitor/alerts/events/history | getEventHistory | Historia zdarzeń alertów | JWT |
getEvents przyjmuje status, severity, type. getEventHistory przyjmuje definitionId (uuid), from/to (date-time), limit (domyślnie 100). acknowledgeEvent i resolveEvent przyjmują treść {user}; silenceEvent przyjmuje treść {durationMinutes}. AlertEvent.status: FIRING | ACKNOWLEDGED | RESOLVED; zawiera metricValue, threshold, firedAt, metadane potwierdzenia/rozwiązania oraz silencedUntil.
// GET /api/v1/monitor/alerts/events/{id} → 200 OK (AlertEvent)
{
"id": "ev-0042",
"definitionId": "def-0001",
"status": "FIRING",
"metricValue": 342000,
"threshold": 300000,
"firedAt": "2025-12-15T14:30:00Z",
"silencedUntil": null
}
// POST /api/v1/monitor/alerts/events/{id}/ack → 200 OK
// Request: { "user": "u-1001" }
{
"id": "ev-0042",
"status": "ACKNOWLEDGED",
"acknowledgedBy": "u-1001"
}
Strumienie SSE (czas rzeczywisty)
Usługa Monitorowania udostępnia strumienie Server-Sent Events dla alertów i metryk w czasie rzeczywistym. Są one routowane przez bramę za pośrednictwem prefiksu przejścia SSE /api/v1/monitor/sse/**.
| Method | Path | Operation ID | Przeznaczenie | Auth |
|---|---|---|---|---|
| GET | /api/v1/monitor/sse/alerts | streamAlerts | Strumień SSE alertów w czasie rzeczywistym | JWT |
| GET | /api/v1/monitor/sse/metrics | streamMetrics | Strumień SSE okresowych metryk systemowych | JWT |
streamAlerts przyjmuje parametr zapytania severity (filtr rozdzielony przecinkami) i zwraca text/event-stream. Jego typy zdarzeń to connected (początkowe potwierdzenie zawierające subscriberId), alert (ładunek JSON alertu) oraz heartbeat (utrzymanie połączenia). Połączenie wygasa po 30 minutach.
// GET /api/v1/monitor/sse/alerts?severity=CRITICAL,WARNING
event: connected
data: {"subscriberId":"sub-7c2e","at":"2025-12-15T14:30:00Z"}
event: alert
data: {"id":"al-0099","severity":"CRITICAL","title":"Connector teradata-prod down"}
event: heartbeat
data: {}
Uwaga
Połączenia SSE są zamykane przez serwer po 30 minutach. Klienci muszą się ponownie połączyć — i mogą wznowić filtrowanie na tym samym zestawie severity — aby nadal otrzymywać alerty w czasie rzeczywistym.
Kanały powiadomień
Kanały powiadomień dostarczają alerty do zewnętrznych miejsc docelowych.
| Method | Path | Operation ID | Przeznaczenie | Auth |
|---|---|---|---|---|
| GET | /api/v1/monitor/channels | listNotificationChannels | Lista kanałów powiadomień | JWT |
| POST | /api/v1/monitor/channels | createNotificationChannel | Utworzenie kanału powiadomień | JWT |
| GET | /api/v1/monitor/channels/{id} | getNotificationChannel | Pobranie kanału po ID | JWT |
| PUT | /api/v1/monitor/channels/{id} | updateNotificationChannel | Aktualizacja kanału | JWT |
| DELETE | /api/v1/monitor/channels/{id} | deleteNotificationChannel | Usunięcie kanału | JWT |
| POST | /api/v1/monitor/channels/{id}/test | testNotificationChannel | Wysłanie powiadomienia testowego | JWT |
listNotificationChannels przyjmuje workspaceId (uuid), channelType oraz enabled (bool). NotificationChannelDto.channelType: EMAIL | SLACK | PAGERDUTY | WEBHOOK | TEAMS. Obiekt config jest specyficzny dla kanału — EMAIL → recipients, SLACK/TEAMS → webhookUrl, PAGERDUTY → routingKey, WEBHOOK → url.
// POST /api/v1/monitor/channels → 201 Created
// Request: NotificationChannelDto
{
"name": "Billing team Slack",
"channelType": "SLACK",
"enabled": true,
"config": { "webhookUrl": "https://hooks.slack.com/services/T000/B000/XXXX" }
}
// POST /api/v1/monitor/channels/{id}/test → 200 OK (ChannelTestResult)
{
"success": true,
"message": "Test notification delivered",
"testedAt": "2025-12-15T14:30:00Z"
}
AI Copilot
Usługa Copilot (port 8086) jest proxowana przez bramę. Jest udostępniana przez pojedynczą operację-zaślepkę bramy, a nie poprzez formalną specyfikację OpenAPI.
| Method | Path | Operation ID | Przeznaczenie | Auth |
|---|---|---|---|---|
| GET | /api/v1/ai/copilot | copilotEndpoint | AI copilot (proxowany do copilot-service) | JWT |
// GET /api/v1/ai/copilot → 200 OK
{
"service": "copilot",
"status": "available"
}
Uwaga
Usługi Copilot, Migracji i CDC są wyłącznie proxowane — są osiągalne przez bramę, ale nie są formalnie wyspecyfikowane poza tymi operacjami-zaślepkami bramy. Pokazane tutaj struktury mają charakter poglądowy; pełne kontrakty żądań i odpowiedzi należy uzgodnić z zespołami usług.
Silnik Migracji
Usługa Migracji (port 8087) jest proxowana przez bramę i udostępnia plany migracji.
| Method | Path | Operation ID | Przeznaczenie | Auth |
|---|---|---|---|---|
| GET | /api/v1/migration/plans | migrationPlans | Plany migracji (proxowane do migration-service) | JWT |
// GET /api/v1/migration/plans → 200 OK
{
"plans": [
{ "id": "mig-0001", "name": "Teradata → Snowflake DWH migration", "status": "IN_PROGRESS" }
]
}
Konektory CDC
Operacje konektorów CDC są proxowane do Connector SDK (port 8088).
| Method | Path | Operation ID | Przeznaczenie | Auth |
|---|---|---|---|---|
| GET | /api/v1/cdc/connectors | listCdcConnectors | Lista konektorów CDC | JWT |
| POST | /api/v1/cdc/connectors | deployCdcConnector | Wdrożenie konektora CDC | JWT |
| GET | /api/v1/cdc/health | cdcHealth | Podsumowanie stanu CDC | JWT |
deployCdcConnector przyjmuje ogólny obiekt jako treść i zwraca 201 Created.
// POST /api/v1/cdc/connectors → 201 Created
// Request: generic connector configuration object
{
"name": "oracle-orders-cdc",
"sourceType": "ORACLE",
"tables": ["SALES.ORDERS", "SALES.ORDER_ITEMS"]
}
// GET /api/v1/cdc/health → 200 OK
{
"status": "UP",
"connectors": 6,
"running": 6,
"failed": 0
}