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.

MethodPathOperation IDPrzeznaczenieAuth
GET/api/v1/monitor/dashboardgetDashboardZagregowane metryki paneluJWT
GET/api/v1/monitor/pipelines/{id}/metricsgetPipelineMetricsSzczegółowe metryki potoku (percentyle, SLA)JWT
POST/api/v1/monitor/pipelines/runrecordPipelineRunWewnętrzny — rejestracja wyniku uruchomienia potokuJWT
GET/api/v1/monitor/connectors/healthgetConnectorsHealthStatusy stanu konektorów + podsumowanieJWT
POST/api/v1/monitor/connectors/healthrecordConnectorHealthWewnętrzny — rejestracja kontroli stanu konektoraJWT
GET/api/v1/monitor/system/healthgetSystemHealthStan 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.

MethodPathOperation IDPrzeznaczenieAuth
GET/api/v1/monitor/alertsgetAlertsLista alertówJWT
POST/api/v1/monitor/alertscreateAlertUtworzenie alertuJWT
GET/api/v1/monitor/alerts/{id}getAlertPobranie alertu po IDJWT
DELETE/api/v1/monitor/alerts/{id}deleteAlertUsunięcie alertuJWT
POST/api/v1/monitor/alerts/{id}/ackacknowledgeAlertPotwierdzenie alertuJWT
POST/api/v1/monitor/alerts/{id}/resolveresolveAlertRozwiązanie alertuJWT
POST/api/v1/monitor/alerts/bulk/ackbulkAcknowledgeZbiorcze potwierdzanie alertówJWT
POST/api/v1/monitor/alerts/bulk/resolvebulkResolveZbiorcze rozwiązywanie alertówJWT
GET/api/v1/monitor/alerts/historygetAlertHistoryHistoria alertówJWT
GET/api/v1/monitor/alerts/summarygetAlertSummaryPodsumowanie liczby alertówJWT
POST/api/v1/monitor/alerts/purgepurgeResolvedCzyszczenie starych rozwiązanych alertówJWT

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.

MethodPathOperation IDPrzeznaczenieAuth
GET/api/v1/monitor/alerts/definitionsgetDefinitionsLista definicji alertówJWT
POST/api/v1/monitor/alerts/definitionscreateDefinitionUtworzenie definicji alertuJWT
GET/api/v1/monitor/alerts/definitions/{id}getDefinitionPobranie definicjiJWT
PUT/api/v1/monitor/alerts/definitions/{id}updateDefinitionAktualizacja definicjiJWT
DELETE/api/v1/monitor/alerts/definitions/{id}deleteDefinitionUsunięcie definicjiJWT
POST/api/v1/monitor/alerts/definitions/{id}/toggletoggleDefinitionWłączenie/wyłączenie definicjiJWT
POST/api/v1/monitor/alerts/definitions/{id}/silencesilenceDefinitionTymczasowe wyciszenie definicjiJWT

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, operatorGREATER_THAN | LESS_THAN | EQUAL | …, threshold, windowMinutes, consecutiveFailures) oraz recipients[] (NotificationRecipient z channelEMAIL | 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.

MethodPathOperation IDPrzeznaczenieAuth
GET/api/v1/monitor/alerts/eventsgetEventsLista zdarzeń alertów wygenerowanych przez silnikJWT
GET/api/v1/monitor/alerts/events/{id}getEventPobranie zdarzenia alertuJWT
POST/api/v1/monitor/alerts/events/{id}/ackacknowledgeEventPotwierdzenie zdarzeniaJWT
POST/api/v1/monitor/alerts/events/{id}/resolveresolveEventRozwiązanie zdarzeniaJWT
POST/api/v1/monitor/alerts/events/{id}/silencesilenceEventWyciszenie zdarzeniaJWT
GET/api/v1/monitor/alerts/events/historygetEventHistoryHistoria zdarzeń alertówJWT

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/**.

MethodPathOperation IDPrzeznaczenieAuth
GET/api/v1/monitor/sse/alertsstreamAlertsStrumień SSE alertów w czasie rzeczywistymJWT
GET/api/v1/monitor/sse/metricsstreamMetricsStrumień SSE okresowych metryk systemowychJWT

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.

MethodPathOperation IDPrzeznaczenieAuth
GET/api/v1/monitor/channelslistNotificationChannelsLista kanałów powiadomieńJWT
POST/api/v1/monitor/channelscreateNotificationChannelUtworzenie kanału powiadomieńJWT
GET/api/v1/monitor/channels/{id}getNotificationChannelPobranie kanału po IDJWT
PUT/api/v1/monitor/channels/{id}updateNotificationChannelAktualizacja kanałuJWT
DELETE/api/v1/monitor/channels/{id}deleteNotificationChannelUsunięcie kanałuJWT
POST/api/v1/monitor/channels/{id}/testtestNotificationChannelWysłanie powiadomienia testowegoJWT

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.

MethodPathOperation IDPrzeznaczenieAuth
GET/api/v1/ai/copilotcopilotEndpointAI 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.

MethodPathOperation IDPrzeznaczenieAuth
GET/api/v1/migration/plansmigrationPlansPlany 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).

MethodPathOperation IDPrzeznaczenieAuth
GET/api/v1/cdc/connectorslistCdcConnectorsLista konektorów CDCJWT
POST/api/v1/cdc/connectorsdeployCdcConnectorWdrożenie konektora CDCJWT
GET/api/v1/cdc/healthcdcHealthPodsumowanie stanu CDCJWT

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
}
Poprzednia
API metadanych i pochodzenia