Centrum monitorowania

Centrum monitorowania to operacyjne centrum sterowania platformy DataFlow AI. Daje każdej roli wgląd w czasie rzeczywistym i historyczny w wykonanie potoków w ramach ponad 500 potoków Polkomtela, ze wspomaganą AI diagnozą awarii wbudowaną bezpośrednio w widok szczegółów uruchomienia.

Nowy tutaj? Co oznacza „monitorowanie"

Gdy potok zostanie zbudowany i zaplanowany, uruchamia się sam — często w środku nocy. Monitorowanie to sposób, w jaki sprawdzasz, czy te automatyczne uruchomienia faktycznie zadziałały, oraz w jaki dowiadujesz się, dlaczego, gdy któreś nie zadziałało. Centrum monitorowania to ekran, który otwierasz każdego ranka, aby odpowiedzieć na trzy pytania:

• Czy wszystko uruchomiło się ostatniej nocy?
• Jeśli coś zawiodło, co zawiodło i dlaczego?
• Czy coś działa wolniej lub kosztuje więcej, niż powinno?

Kilka słów, które zobaczysz wszędzie na tym ekranie:

• Uruchomienie — pojedyncze wykonanie potoku. Każde uruchomienie ma własny identyfikator, czas rozpoczęcia i zakończenia, status oraz własne dzienniki. Ten sam potok produkuje nowe uruchomienie za każdym razem, gdy się odpala.
• Status — wynik uruchomienia. Sukces (zielony) oznacza, że zakończyło się poprawnie; Awaria (czerwony) oznacza, że zatrzymało się z błędem; Uruchomione (niebieski, pulsujący) oznacza, że nadal trwa; Ostrzeżenie (żółty) oznacza, że zakończyło się, ale coś wyglądało nie tak; Anulowane oznacza, że osoba lub limit czasu je zatrzymał.
• SLA — umowa o poziomie usług (ang. Service Level Agreement), obietnica dotycząca tego, jak potok powinien się zachowywać (na przykład „kończy w ciągu 30 minut" lub „powodzenie w 99% przypadków"). Centrum monitorowania ostrzega Cię, gdy potok jest zagrożony złamaniem tej obietnicy.
• Dzienniki — szczegółowy, linijka po linijce, dziennik, który uruchomienie zapisuje podczas pracy. Gdy coś zawiedzie, dzienniki zawierają dokładny błąd.

Co robi Centrum monitorowania

Polkomtel uruchamia mieszankę obciążeń wsadowych (nocnych, godzinowych, co 2 godziny) oraz strumieni CDC/Kafka niemal w czasie rzeczywistym kierowanych do Teradata DWH-MONA, Snowflake, Databricks oraz GCS/Iceberg. Centrum monitorowania istnieje, aby szybko ujawniać awarie, wspierać wspomaganą AI diagnozę i sprawiać, że setki współbieżnych uruchomień są możliwe do przeskanowania.

Jego zasady projektowe:

• Łatwość spojrzenia — krytyczny status jest widoczny w ciągu dwóch sekund od wczytania strony.
• Zagłębianie się — każdy element podsumowania jest klikalny i prowadzi do szczegółów.
• Debugowanie z AI na pierwszym miejscu — panel diagnozy AI jest wyeksponowany, a nie ukryty.
• Gęste, ale możliwe do przeskanowania — siatki danych i wykresy Gantta dla zaawansowanych użytkowników; karty KPI dla menedżerów.

Baza trasy: /monitor (przekierowuje do /monitor/runs). Plik wejściowy: src/pages/MonitorCenter.tsx, układ pages/monitor/MonitorCenterLayout.tsx.

Kto z niego korzysta

Wszystkie role korzystają z Centrum monitorowania; jest to główna powierzchnia robocza dla inżyniera danych (Anny) oraz administratora platformy (Katarzyny).

Nawigacja — podstrony

Centrum monitorowania to zagnieżdżony moduł. Jego układ renderuje pasek kart z plakietkami liczbowymi, a pasek boczny prowadzi do mniej więcej jedenastu podstron.

Monitor Center
 [Pipeline Runs (3 running)]  [Performance]  [Alerts (5 active)]  [Logs (12 errors)]

Plakietki liczbowe: Pipeline Runs pokazuje N running (niebieski), Alerts pokazuje N active (czerwony, jeśli istnieje alert krytyczny, w przeciwnym razie żółty), Logs pokazuje N errors (czerwony, gdy są nieprzeczytane błędy z ostatniej godziny).

Pulpit uruchomień potoków

Domyślny ekran startowy — /monitor/runs.

+-----------------------------------------------------------------------+
| KPI STRIP                                                              |
| [Total 487] [Running 3] [Success 461] [Failed 8] [Warning 15]         |
+-----------------------------------------------------------------------+
| FILTERS:  Status [All v]  Time [Last 24h v]  Search [____]  [Refresh] |
+-----------------------------------------------------------------------+
| GANTT CHART (last 24 hours)                                            |
|  wf_E112          ===RED===                                            |
|  wf_SAP_Replika       ====GREEN====                                    |
|  wf_CDR_Daily             ======GREEN======                            |
+-----------------------------------------------------------------------+
| DATA GRID                                                              |
|  Pipeline | Status | Start | Duration | Rows | Volume | Engine | By   |
+-----------------------------------------------------------------------+

Pasek KPI

Pięć kafelków — Łącznie uruchomień (24h), Uruchomione, Sukces, Awaria, Ostrzeżenie. Każdy kafelek jest klikalny i ustawia filtr statusu zarówno na wykresie Gantta, jak i na siatce danych poniżej.

Wiersz filtrów

Wykres Gantta

24-godzinna oś czasu z jednym wierszem na potok. Słupki są kolorowane według statusu (słupki uruchomione pulsują), ich szerokość jest proporcjonalna do czasu trwania, a podpowiedź po najechaniu pokazuje nazwę, status, czasy, czas trwania i wiersze. Kliknięcie słupka otwiera stronę szczegółów tego uruchomienia.

Siatka danych

Domyślne sortowanie to malejący czas rozpoczęcia. Kliknięcie wiersza otwiera stronę szczegółów uruchomienia.

Szczegóły uruchomienia potoku

Widok szczegółów jednego uruchomienia — /monitor/runs/:runId.

+-----------------------------------------------------------------------+
| < Back        wf_E112 - Run run-20260303-001                          |
| [FAILED]  Started 03:12  Ended 03:47  Duration 35m  Engine Push-down   |
+-----------------------------------------------------------------------+
| [Re-run] [Re-run from Checkpoint] [View Logs] [Open in Design Studio]  |
+-----------------------------------------------------------------------+
| +-- VISUAL DAG (60%) --------+  +-- AI DIAGNOSIS (40%) --------------+ |
| | [Sybase] -> [Filter]       |  | Summary: lock timeout at the      | |
| |    |                       |  |  'Enrich with CRM Data' node.     | |
| |    v                       |  | Root Cause: ...                   | |
| | [Enrich CRM] (RED) -> [...] |  | Suggested Actions: 1. 2. 3.       | |
| +----------------------------+  | Confidence: 92%                   | |
|                                 +-----------------------------------+ |
| EXECUTION TIMELINE  (per-node horizontal bars)                         |
| DATA VOLUME BY NODE (rows in / out, bytes)                             |
+-----------------------------------------------------------------------+

Pasek nagłówka i akcje

Nagłówek pokazuje plakietkę statusu, identyfikator uruchomienia, rozpoczęcie/zakończenie/czas trwania, wyzwolone przez, silnik, środowisko i obszar roboczy. Przyciski akcji:

Wizualny DAG (lewa strona, 60%)

Graf React Flow uruchomienia, ze statusem poszczególnych węzłów:

Panel diagnozy AI (prawa strona, 40%)

Karta z fioletowym gradientem zawierająca Podsumowanie, wyjaśnienie Przyczyny źródłowej, ponumerowaną listę Sugerowanych działań (z elementami wyróżnionymi jako kod, takimi jak READ UNCOMMITTED), plakietkę % pewności, klikalne łącza do powiązanych awarii i dotkniętych potoków oraz łącze do informacji zwrotnej. Poniżej dwóch paneli znajdują się Oś czasu wykonania (poziomy wykres słupkowy poszczególnych węzłów) oraz podział Wolumen danych według węzła.

Dla przepracowanego przykładu awaria wf_E112 diagnozuje przekroczenie limitu czasu blokady Sybase ASE w węźle Enrich with CRM Data — spowodowane rywalizacją o blokady przez współbieżną aktualizację wsadową wf_SAP_Replika — i sugeruje ponowne uruchomienie od punktu kontrolnego z izolacją READ UNCOMMITTED, przeharmonogramowanie w celu uniknięcia nakładania się oraz długoterminowe przejście na replikę Snowflake, z 92% pewnością.

Przeglądarka dzienników

Kliknięcie View Logs otwiera Przeglądarkę dzienników ograniczoną do uruchomienia pod /monitor/runs/:runId/logs. Strumieniuje ustrukturyzowane wpisy dziennika uruchomienia z kolumnami ważności, kategorii i znacznika czasu oraz obsługuje filtrowanie i wyszukiwanie pełnotekstowe.

Globalna Przeglądarka dzienników pod /monitor/logs to ten sam komponent bez ograniczenia do uruchomienia, ujawniający ustrukturyzowane dzienniki ze wszystkich ponad 500 potoków.

Analityka wydajności

/monitor/performance — siatka wykresów Recharts napędzana selektorem zakresu czasu (7d / 30d / 90d / niestandardowy).

Alerty, dzienniki i operacyjne podstrony

Poza uruchomieniami i wydajnością Centrum monitorowania niesie zestaw operacyjnych podstron, z których każda odpowiada na konkretne pytanie o niezawodność lub koszty.

Świeżość danych

Monitor świeżości danych (/monitor/freshness) śledzi, jak nieaktualny jest każdy źródłowy zbiór danych względem oczekiwanej kadencji aktualizacji. Każde źródło — CRM, Billing, Network, CDR, Product Catalog — pokazuje pasek świeżości i znacznik czasu „ostatnio zaktualizowano", kolorowany na zielono, gdy świeże, bursztynowo, gdy nieaktualne, i czerwono, gdy krytycznie zaległe.

Tempo wypalania SLA

Podstrona SLA Burn Rate (/monitor/sla) pokazuje, jak szybko każdy potok zużywa swój budżet błędów SLA. Potok, który zawodzi lub działa długo, szybko wypala swój budżet; widok oznacza potoki na kursie do naruszenia ich okna SLA — na przykład uruchomienie wf_CDR_Daily, które przekroczyło swój próg 30 minut.

Koszty potoków

Podstrona Pipeline Costs (/monitor/costs) przypisuje wydatki na infrastrukturę poszczególnym potokom i pokazuje trend kosztów w czasie. Naturalnie łączy się z wykresem Top 10 Slowest Pipelines — potoki działające długo są zwykle najdroższe — i zasila widok budżetu Konsoli administratora.

Zaplanowane raporty

Zaplanowane raporty pozwalają zespołom otrzymywać cykliczne podsumowania monitorowania — zestawienia kondycji uruchomień, SLA i kosztów — z określoną kadencją, dostarczane automatycznie, a nie pobierane ręcznie.

Przewodnik — Twoja poranna kontrola kondycji

To rutyna, którą inżynier danych wykonuje na samym początku każdego dnia. Zajmuje dwie lub trzy minuty i mówi Ci, czy zeszłonocna praca jest bezpieczna.

1. Otwórz Centrum monitorowania. Kliknij Monitor w lewym pasku bocznym (lub naciśnij Alt+M). Otwiera się na pulpicie uruchomień potoków.
2. Przeczytaj pasek KPI. Spójrz na pięć kafelków na górze. Jeśli Awaria pokazuje 0, a Ostrzeżenie jest niskie, zeszła noc poszła dobrze — skończyłeś. Jeśli Awaria pokazuje liczbę, kontynuuj.
3. Przefiltruj do awarii. Kliknij czerwony kafelek Awaria. Wykres Gantta i siatka danych poniżej natychmiast filtrują się, aby pokazać tylko uruchomienia, które zawiodły.
4. Wybierz uruchomienie zakończone awarią. W siatce kliknij wiersz pierwszego zawiedzionego potoku (lub kliknij jego czerwony słupek na wykresie Gantta). Otwiera się strona Szczegóły uruchomienia.
5. Przeczytaj diagnozę AI. Po prawej stronie strony Szczegóły uruchomienia fioletowy panel Diagnoza AI daje Ci Podsumowanie w prostym języku, Przyczynę źródłową oraz ponumerowaną listę Sugerowanych działań — a także procent pewności, abyś wiedział, jak pewna jest AI.
6. Spójrz na zepsuty węzeł. Po lewej Wizualny DAG pokazuje potok jako schemat blokowy. Węzeł z czerwoną poświatą to miejsce, w którym się zepsuł. Najedź na niego, aby przeczytać dokładny błąd w dymku podpowiedzi.
7. Napraw to. Masz dwa szybkie wybory: kliknij Re-run from Checkpoint, aby ponowić od ostatniego dobrego punktu (przydatne, gdy przyczyna była tymczasowa, jak krótka czkawka sieci), lub kliknij Open in Design Studio, aby poprawić sam potok.
8. Powtórz dla pozostałych zawiedzionych uruchomień, a następnie wyczyść filtr Awaria, aby wrócić do pełnego obrazu.

Ścieżki kliknięć

Zbadaj zawiedzione uruchomienie

1. Otwórz /monitor/runs.
2. Kliknij kafelek KPI Awaria — to filtruje zarówno wykres Gantta, jak i siatkę danych do zawiedzionych uruchomień.
3. W siatce danych kliknij wiersz zawiedzionego potoku (lub jego czerwony słupek na wykresie Gantta).
4. Otwiera się strona Szczegóły uruchomienia. Przeczytaj panel Diagnoza AI w poszukiwaniu przyczyny źródłowej i sugerowanych działań.
5. W Wizualnym DAG znajdź węzeł z czerwoną poświatą i najedź na niego, aby przeczytać dymek z komunikatem błędu.
6. Albo kliknij Re-run from Checkpoint, aby ponowić od ostatniego dobrego punktu, albo kliknij Open in Design Studio, aby naprawić potok.

Skonfiguruj alert

1. Z paska kart Centrum monitorowania otwórz Alerts (/monitor/alerts).
2. Przejrzyj listę alertów — każdy wiersz pokazuje ważność i akcję potwierdzania.
3. Aby obsłużyć aktywny alert, kliknij jego akcję Acknowledge; zostaje oznaczony jako potwierdzony.
4. Dla głębszego triage'u prześledź alert aż do jego powiązanego uruchomienia lub widoku dziennika.

Przejrzyj koszty potoku

1. Otwórz podstronę Pipeline Costs (/monitor/costs).
2. Przejrzyj przypisanie kosztów poszczególnych potoków oraz trend kosztów.
3. Odnieś się do wykresu Top 10 Slowest Pipelines w Analityce wydajności — potoki działające długo są zwykle najdroższe.
4. Dla kontekstu budżetu w skali całej platformy strona Cost Management Konsoli administratora (/admin/costs) zapewnia budżety i prognozy.

Sprawdź kondycję SLA

1. Otwórz Performance Analytics (/monitor/performance).
2. Spójrz na wykres Success Rate Trend — każdy punkt spadający poniżej czerwonej linii referencyjnej 99% to naruszenie SLA.
3. Sprawdź wykres Pipeline Duration Trends dla tej samej daty; skok p95 zwykle koreluje z incydentem infrastruktury.
4. Dla szczegółów tempa wypalania otwórz podstronę SLA Burn Rate (/monitor/sla).

Częste pytania

Mój potok utknął, pokazując „Uruchomione" od godzin — co teraz? Uruchomienie, które nie chce się zakończyć, to zwykle jedno z: baza danych źródłowych, która przestała odpowiadać, oczekiwanie na blokadę, gdzie inny proces przytrzymuje dane, lub zatrzymana usługa. Otwórz uruchomienie, sprawdź Dzienniki w poszukiwaniu linii „Connection timed out" i spójrz na panel Wolumen danych według węzła, aby zobaczyć, gdzie zamarło. Każde uruchomienie ma limit czasu (domyślnie 120 minut) i automatycznie anuluje się po jego upływie; możesz też kliknąć Cancel Run, aby zatrzymać je samodzielnie.

Jaka jest różnica między uruchomieniem „Awaria" a uruchomieniem „Ostrzeżenie"? Uruchomienie Awaria trafiło na błąd, z którego nie mogło się odzyskać, i zatrzymało się — jego dane nie zakończyły ładowania. Uruchomienie Ostrzeżenie zakończyło się i załadowało swoje dane, ale coś wyglądało nietypowo (reguła jakości oznaczyła pewne wiersze lub krok trwał znacznie dłużej niż zwykle). Awarie wymagają działania teraz; ostrzeżenia należy przejrzeć, ale nie są nagłymi przypadkami.

Co oznacza procent pewności w diagnozie AI? To stopień pewności AI co do jej wyjaśnienia przyczyny źródłowej. Wysoka liczba (powyżej ~85%) oznacza, że dowody wyraźnie wskazywały na jedną przyczynę. Niższa liczba oznacza, że AI znalazła kilka prawdopodobnych wyjaśnień — przeczytaj sugerowane działania, ale zweryfikuj przed zastosowaniem poprawki.

Czy „Re-run" jest bezpieczny? Czy zduplikuje moje dane? Dla potoków, których cel używa trybu zapisu upsert lub merge, ponowne uruchomienie jest bezpieczne — istniejące wiersze są aktualizowane, a nie duplikowane. Dla celów w trybie append ponowne uruchomienie może dodać wiersze dwukrotnie. Jeśli nie masz pewności, najpierw sprawdź tryb zapisu celu potoku w Studiu projektowania lub preferuj Re-run from Checkpoint.

Jak otrzymać alert, gdy coś zawiedzie, zamiast sprawdzać co rano? Otwórz podstronę Alerts i zasubskrybuj kanał — Email, Slack, Teams, webhook lub PagerDuty. Krytyczne (P1) i wysokie (P2) awarie mogą automatycznie powiadamiać personel dyżurny.

Co oznacza „tempo wypalania SLA"? Każdy potok ma „budżet błędów" SLA — małą tolerancję na spóźnienie lub awarię. Każde spóźnione lub zawiedzione uruchomienie wydaje część tego budżetu. Strona SLA Burn Rate pokazuje, jak szybko każdy potok zużywa swój budżet, abyś mógł zadziałać, zanim się wyczerpie i SLA zostanie formalnie naruszone.

Dlaczego jeden potok jest tak drogi? Potoki działające długo wypalają najwięcej mocy obliczeniowej chmury. Sprawdź podstronę Pipeline Costs względem wykresu Top 10 Slowest Pipelines — zwykle się pokrywają. Poprawka jest normalnie w Studiu projektowania: ładuj przyrostowo, przesuń pracę do bazy danych lub podziel gigantyczny potok na mniejsze.

Pulpit jest pusty — gdzie są moje dane? Potwierdź, że jesteś we właściwym obszarze roboczym (selektor górnego paska), poszerz filtr Zakres czasu i sprawdź, czy Twoje potoki faktycznie uruchomiły się co najmniej raz. Twarde odświeżenie (Ctrl+Shift+R) czyści nieaktualny widok.

Za kulisami

Strumienie w czasie rzeczywistym są dostarczane przez menedżer SSE platformy i pobierane przez haki takie jak useAlertStream, useMetricsStream oraz useRealtimePipelineStatus.