DataOps-konsolen
DataOps-konsolen är den operatörsinriktade webbapplikationen för PDQ-plattformen. Det är ett verktyg för övervakning och åtgärd: den visar om varje schemalagd inhämtning, förflyttning i datasjön, laddning till lagret och kvalitetskontroll har körts som förväntat, och den låter en operatör starta om, hoppa över eller trigga om det som inte gjorde det.
Den är inte ett utvecklings- eller konfigurationsgränssnitt. Pipelines definieras av metadata i PDQ-repositoryt; konsolen läser den metadatan och körningsloggarna och erbjuder en liten, avgränsad uppsättning åtgärder ovanpå dem.
All data läses via PDQ:s REST-API (ett fåtal referensvyer läser repository-databasen direkt). Konsolen har inget eget tillstånd.
Navigeringskarta
Sidomenyn grupperar sidorna efter vilket steg i plattformen de täcker.
| Grupp | Sida | Vad den svarar på |
|---|---|---|
| Ingestion | INGEST Tasks | Kördes varje schemalagt uttag, och hur mycket data kom tillbaka? |
| Data Lake | DLS Trace | Flyttades varje levererad fil genom Landing → Raw → Trusted → Published? |
| Publisher Trace | Landade varje publiceringsoperation i sin måltabell? | |
| Data Profiler | Hur ser en leverans faktiskt ut, och vilket datakontrakt innebär den? | |
| Contract Validation | Har en källa avvikit från sitt överenskomna datakontrakt? | |
| Data Warehouse | Loading Tasks | Slutfördes varje laddningssteg för varje källfil? |
| Additional Tasks | Kördes de efterbearbetningar som hakats på laddningarna? | |
| Task Orchestration | Vilket schema har varje källfil, och är det fortfarande friskt? | |
| Loading Statistics | Hur många rader stagades och infogades, per källfil och per objekt? | |
| Data Quality | QPI Monitor | Vad svarade varje kvalitetskontroll senast? |
| QPI Administration | Skapa, redigera, pensionera och manuellt trigga kvalitetskontroller. | |
| Reference | Documentation | Hela konfigurationen och datakontraktet bakom en källfil. |
| Data Lineage | Var kommer en kolumn ifrån, och var hamnar den? | |
| Data Model | Hur hänger målmodellen ihop? | |
| System | System Health | Kör tjänsterna själva, och vad loggade de? |
System Health är standardsidan vid inloggning.
Globala kontroller
Tre kontroller i sidomenyn gäller varje sida och är det första att kontrollera när en sida ser tom eller inaktuell ut.
Datumintervall
Fäst högst upp i sidomenyn. Det sätter global_date_range, som varje tidsfönstrad sida läser.
- Snabbval: Today, 24h, 7 days
- En datumintervallväljare plus separata From- och To-tider (30-minuterssteg)
- Standard i en ny session är de senaste 24 timmarna
Sidor som visar "no data for the selected time range" svarar nästan alltid korrekt för ett för smalt fönster — vidga det innan du antar ett fel.
Plattformshälsa och uppdatering
En enda färgad rad under datumintervallet sammanfattar hela plattformen för det valda fönstret:
| Indikator | Betydelse |
|---|---|
| 🟢 All systems healthy | Inga misslyckade jobb, inga fel- eller varningsposter i loggen |
| 🟠 n warning(s) | Fel- eller varningsposter i körningsloggen, men inga misslyckade jobb |
| 🔴 Degraded — n job(s) failed | Minst ett jobb misslyckades |
| ⚪ Health check unavailable | Hälsofrågan kunde inte köras |
Uppdateringsknappen bredvid rensar alla cacher och läser om plattformen.
Settings
Längst ned i sidomenyn, hopfälld som standard: cache-TTL. Frågeresultat cachas i 120 sekunder som standard, så att två operatörer som tittar på samma fönster inte var för sig belastar repositoryt. Ändra den bara om du behöver en annan avvägning mellan färskhet och last; använd uppdateringsknappen för en engångsomläsning.
Roller och behörigheter
Konsolen autentiserar inte användare själv. Den ligger bakom en Caddy-omvänd proxy som autentiserar användaren och vidarebefordrar rubrikerna X-User-Email och X-User-Groups.
| Roll | Härledd från | I den här konsolen | I Config UI |
|---|---|---|---|
admin | Gruppen authp/admin | Allt, inklusive samtliga åtgärder för omstart / hoppa över / trigga / redigera | Skriv |
developer | Gruppen authp/user | Läsa alla sidor — inga admin-åtgärder | Skriv |
reader | Reserv när ingen grupp matchar | Läsa alla sidor | Ingen skrivrätt |
Rollerna sträcker sig över två gränssnitt, och skillnaden spelar roll: en developer har full
skrivrätt där plattformen konfigureras, och kan inte ingripa i en pågående laddning.
Läsbehörighet här betyder inte läsbehörighet överallt.
Själva mappningen görs vid installation — installatören sätter GUID:t för en Entra-grupp som värde på varje intern grupp. Se Rollmappning.
Varje förändrande åtgärd ligger inuti en Admin console-expander eller en knapp som bara administratörer ser. Andra roller ser panelen ersatt av en låsnotis som namnger deras aktuella roll.
Rollrubrikerna är tillförlitliga endast eftersom proxyn sätter dem. Exponera aldrig containerporten direkt.
Åtgärdslogg
Varje användarutförd åtgärd skriver en strukturerad JSON-rad till stdout (fångas av containerloggarna) med vem som gjorde den, deras roll, sidan, åtgärden, målet och tidsstämpeln — till exempel en omstart av misslyckade INGEST-uppgifter, en ompublicering, en schemaändring eller en avslutad QPI-körning.
Felhantering
Fel i repositoryt tömmer inte en sida. Varje sida omsluter sina hämtningar så att ett fel renderas som ett åtgärdbart kort som beskriver vad som misslyckades och om det går att försöka igen, medan de delar som laddades ändå visas. På System Health slås identiska fel från flera endpoints ihop till ett enda kort.
Den dagliga genomgången
Själva rutinen dokumenteras en gång, i Den dagliga rundan — vilken ordning man arbetar i, vad varje kontroll letar efter, och vad man gör när en av dem slår ut.
Det som det här avsnittet tillför är var varje sida bär sin egen checklista, längst ned, som jämför konfigurerat mot utfört. Den jämförelsen är det snabbaste sättet att upptäcka arbete som aldrig ens startade — ett tyst fel som ett "inga fel"-mätvärde inte avslöjar.