Skip to main content

Kända problem

Senast granskad: 2026-09-21 — mot produktversion 3.2.

Den här sidan dokumenterar kända problem i PDQ-plattformen och deras lösningar eller workarounds — beteenden som är kända, förväntade och ännu inte åtgärdade, med status där en fix är planerad.

Söker du vad du ska göra just nu?

Den här sidan förklarar varför en feltyp uppstår. För steg-för-steg-åtgärden när en daglig kontroll fallerar, använd driftmanualen: Felsökning.

Infrastruktur och systemstabilitet​

Docker containers stannar oväntat​

Problem: Docker containers avslutas med exit code 0 eller andra felkoder efter VM-omstart.

Symtom:

  • Containers visas som "Exited" i docker ps -a
  • Tjänster svarar inte på nätverksförfrågningar
  • DataOps-konsolen inte tillgänglig

Lösning:

cd /datadrive/configs
docker compose down
docker compose up -d

Status: Planerad — automatisk omstart av containrar efter en VM-omstart.

Diskutrymme 100% används​

Problem: /datadrive når 100% kapacitet, vilket orsakar systemfel.

Symtom:

  • Docker containers kan inte startas
  • Loggar visar "No space left on device"
  • Nya datafiler kan inte bearbetas

Lösning:

  1. Kontrollera diskutrymme: df -h
  2. Frigör utrymme från oanvända images, containrar och byggcache: docker system prune -a
  3. Kontrollera vilka containerloggar som vuxit: du -sh /datadrive/docker/containers/*
  4. Överväg att utöka disken via molnportalen

Workaround: Implementera automatisk loggrotation i /etc/docker/daemon.json

Caddy och autentisering​

FQDN-upplösning misslyckas​

Problem: Caddy kan inte få SSL-certifikat på grund av DNS-problem.

Symtom:

  • HTTPS-anslutningar misslyckas
  • SSL-certifikatfel i webbläsaren
  • Caddy-loggar visar ACME-fel

Lösning:

  1. Verifiera DNS-konfiguration: nslookup <your-fqdn>
  2. Kontrollera att Caddy-konfigurationen har rätt FQDN
  3. Bekräfta att metoden för certifikatutfärdande matchar er nätverksexponering
Port 443 ska förbli intern

Installera och säkra plattformen kräver att port 443 endast är nåbar inifrån kundmiljön, inte publikt. En publikt betrodd ACME HTTP-utmaning kan inte slutföras mot en värd som certifikatutfärdaren inte når, så en enbart intern installation behöver en DNS-baserad utmaning eller en intern CA i stället. Öppna inte porten publikt för att komma runt detta.

Status: Under utredning — förbättrad DNS-validering.

Azure AD grupper synkroniseras inte​

Problem: Användargrupper från Azure AD visas inte korrekt i PDQ.

Symtom:

  • Användare kan logga in men saknar rätt behörigheter
  • "Groups claim" saknas i JWT-token
  • Roller mappas inte korrekt

Lösning:

  1. Kontrollera App Registration Token Configuration
  2. Säkerställ att "Group Claims" är konfigurerat för "Security Groups"
  3. Verifiera att grupperna pdq_web_admins, pdq_web_developers, pdq_web_viewers existerar
  4. Bevilja admin consent för User.Read och GroupMember.Read.All

Datainhämtning (INGEST)​

OAuth 2.0 tokens upphör för tidigt​

Problem: Teams/SharePoint OAuth-tokens går ut oftare än förväntat.

Symtom:

  • INGEST-uppgifter misslyckas med "401 Unauthorized"
  • "Token expired" i INGEST-loggar
  • Manuell omautentisering krävs dagligen

Lösning:

  1. Kontrollera token refresh-logik i INGEST-konfiguration
  2. Säkerställ att refresh_token sparas korrekt
  3. Implementera automatisk token-förnyelse via API

Workaround: Konfigurera längre token-livslängd i Azure AD App Registration

Status: Planerad — förbättrad token-hantering.

Store filer orsakar minnesfel​

Problem: Mycket stora XML/JSON-filer (>2GB) överskrider tillgängligt systemminne.

Symtom:

  • INGEST-processen kraschar med "OutOfMemoryError"
  • DLS Worker stannar på stora filer
  • Systemet blir oresponsivt under bearbetning

Lösning: Aktivera streaming för stora filer:

curl -X PUT "http://localhost:8080/api/v3.2/sourcefiles/[filename]/metadata" \
  -H "Content-Type: application/json" \
  -d '{"hierarchyLevel": "records", "useForSplittingRecords": 1}'

Status: Avsiktligt beteende — streaming är tillgängligt men måste aktiveras manuellt.

Data Lake Service (DLS)​

DLS Worker fastnar i "Raw" status​

Problem: Filer förblir i Raw Archive och bearbetas inte vidare till Trusted.

Symtom:

  • DLS Trace visar data i Raw men inte i Trusted
  • lastSeenOn = raw för påverkade filer
  • Inga felmeddelanden i loggar

Lösning:

  1. Filtrera DLS Trace: lastSeenOn = raw
  2. Öppna Admin Console för påverkade filer
  3. Tryck "Load Trusted" för att tvinga bearbetning

Grundorsak: en korrupt eller oläsbar fil. Schemaavvikelser stoppar inte en leverans — de registreras, och filen går vidare till Trusted.

Inkonsistent dataräkning mellan zoner​

Problem: Betydande skillnader i antal records mellan Processing zones.

Symtom:

  • Landing: 1000, Trusted: 850, Published: 850
  • En skillnad på mer än 10–20 poster mellan zoner
  • Data saknas i nedströms system

Lösning:

  1. Kontrollera datakvalitet i källfiler
  2. Granska validering rules i Data Modifier
  3. Undersök filtering-logik i DLS-konfiguration

Workaround: En skillnad på upp till 10–20 poster mellan Published och övriga zoner är förväntad och kan accepteras. Landing, Raw Archive, Trusted och Profile ska stämma exakt — se Den dagliga rundan.

Data Warehouse Automation (DWA)​

SQL genereras inte för mappningar​

Problem: DWA genererar ingen SQL eftersom en mappningsgrupp saknar affärsnyckelmappning. Det är avsiktligt beteende, inte ett fel — se Tysta felmoder.

Symtom:

  • "No SQL Generated" i DWA Loading Tasks
  • Mappningar verkar kompletta i UI
  • Inga felmeddelanden visas

Lösning: Kontrollera mappningskomplettering:

  • Objektladdning: Kräver fullständig nyckelmappning
  • Attributladdning: Kräver nyckelmappning + minst ett attribut
  • Relationsladdning: Kräver två kompletta nycklar från samma källa

Vanliga orsaker:

  • Case-sensitive fältnamn matchar inte källdata
  • Saknade obligatoriska fält i mappning
  • Mappningar spridda över flera mappningsgrupper

Batchscheman körs för tidigt​

Problem: DWA-scheman triggas innan källdata är tillgänglig.

Symtom:

  • "Expected" tasks > "Completed" tasks
  • Tasks stannar i "Scheduled" status >2 timmar
  • Downstream system rapporterar saknad data

Lösning:

  1. Identifiera påverkade tasks
  2. Markera alla tasks för specifikt schema och källfil
  3. Använd "Restart Tasks" från DataOps-konsolen
  4. Justera schema-timing för framtida körningar

DataOps och övervakning​

DataOps Console laddar inte​

Problem: DataOps Console visar blank sida eller laddar oändligt.

Symtom:

  • Vit skärm vid navigation till konsolen
  • JavaScript-fel i browser developer tools
  • Timeout vid API-anrop

Lösning:

  1. Kontrollera AME API-status: curl http://localhost:8080/api/health
  2. Verifiera nätverkskonnektivitet mellan UI och AME
  3. Rensa webbläsarens cache och cookies
  4. Kontrollera för port-mappning problem i Docker

Systemhälsokontroller rapporterar fel status​

Problem: System Health visar en degraderad status för fungerande komponenter.

Symtom:

  • Röd status för aktiva tjänster
  • Motstridiga statusindikatorer
  • Falska alarm i övervakningssystem

Lösning:

  1. Manuell verifiering av komponentstatus
  2. Omstart av hälsokontroll-tjänster
  3. Kontrollera hälsokontroll-konfiguration i AME

Status: Under utredning — förbättrad hälsokontrollslogik.

Prestanda och skalning​

Långsam frågerespons i Published data​

Problem: SQL-frågor mot Published-tabeller tar lång tid att köra.

Symtom:

  • Timeout i rapporteringsverktyg
  • Hög CPU-användning på databasserver
  • Användareklagomål om långsam prestanda

Lösning:

  1. Analysera frågemönster och lägg till index
  2. Överväg datapartitionering för stora tabeller
  3. Implementera materialiserade vyer för vanliga aggregeringar
  4. Optimera DWA-genererad SQL

Workaround: Använd batch-bearbetning för stora analytiska frågor

Minnes läckage i långkörning containers​

Problem: Docker containers förbrukar allt mer minne över tid.

Symtom:

  • Successivt ökande minnesanvändning
  • System blir långsamt efter flera dagar
  • OOM-kills av containers

Lösning: Schemalagd omstart av containers:

# Lägg till i crontab för veckovis omstart
0 2 * * 0 cd /datadrive/configs && docker compose restart

Status: Under utredning — minnesoptimering.

Säkerhet​

Anslutningar kan behöva sparas om efter en uppgradering​

Problem: Efter en uppgradering kan en anslutning sluta autentisera, eftersom den lagrade hemligheten inte följer med. Plattformen lagrar aldrig en hemlighet okrypterat, så det tidigare rådet på den här sidan — att hämta konfigurationen med GET och posta tillbaka den — beskrev ett problem som inte finns och en åtgärd som förstör anslutningen.

Symtom:

  • INGEST-uppgifter misslyckas med autentiseringen mot en källa som fungerade före uppgraderingen
  • Anslutningen ser fortfarande komplett ut i gränssnittet

Lösning: Öppna varje berörd anslutning och spara den på nytt, med lösenord, nycklar och eventuell client_secret. En lagrad hemlighet återanvänds aldrig, så varje sparning kräver dem på nytt. Se Hemligheter efter en uppgradering.

Hämta inte en anslutning med GET och posta tillbaka den

Det finns ingenting att kryptera om. Att hämta en anslutning och posta tillbaka den krypterar det redan krypterade värdet en gång till och lämnar en fungerande anslutning obrukbar.

Rapportera nya problem​

Om du upptäcker nya problem som inte finns dokumenterade här:

  1. Samla information:

    • PDQ-version och komponentversioner
    • Detaljerade symtom och felmeddelanden
    • Steg för att återskapa problemet
    • Systemkonfiguration och miljödetaljer

  2. Kontrollera loggar:

    • Docker container loggar: docker logs <container_name>
    • System loggar: /var/log/
    • Applikationsloggar via DataOps Console

  3. Dokumentera workarounds: Om du hittar temporära lösningar, dokumentera dem för teamet

  4. Rapportera via: Support-kanaler enligt organisationens rutiner