Page History
...
Afsnit 4 (Konfiguration) beskriver aktuelle konfigurationsparametre for DDS Registry henholdsvis Repository, samt eksempler på konfigurationsparameter-filer.
Afsnit 5 .1, 5.2 og 5.3 (Overvågning) beskriver hvorledes DDS Registry og Repository komponenterne overvåges.
I afsnit 5.4 6 (Logfiler og fortolkning af disse) er DDS Registry og Repository-relaterede logfiler beskrevet, så disse evt. kan overvåges, og tillige danne baggrund for fejlsøgning.
...
nsp-role-mapping.properties
DDS Registry og Repository anvender denne property fil til at mappe hvilken rolle (role), der kommer ned i minlog registreringen.
Property filen vedligeholdes her: https://git.nspop.dk/projects/TOOL/repos/nsp-role-mapping/browse/nsp-role-mapping.properties
...
|
...
Kombinationen oid og unique_id_type skal være unik.
Monitorering
Til statuscheck af DDS Registry og Repository findes til hver en servicecheck servlet der kalder servicens afhængigheder, samt en statuscheck servlet der monitorerer de kald der foretages fra DDS Registry og Repository. Alle servlets udstiller http-snitflader som melder 500 ved fejl.
Test af versionsnummer
Det er muligt at konfigurere grænser for tilladte fejl i et givet tidsrum for de alarm og status check, der findes i DDS'en health endpoints. Se afsnittet "Overvågning" nedenfor.
Overvågning
DDS registry og repository har følgende endpoints til overvågningEfter konfiguration og deploy af DDS Registry og Repository kan versionsnummeret hentes med følgende kommandoer:
curl localhost:9090/ddsregistry/
...
status
- curl localhost:9090/ddsregistry/alarm
curl localhost:9091/ddsrepository/
...
status
- curl localhost:9091/ddsrepository/alarm
Generelt omkring status endpointet:
- Returnerer status HTTP 200, hvis DDS'en kan modtage forespørgsler, og 500 hvis den ikke er i stand til det.
- Returnere tekst i json format
- Eksempel på status check er adgang til database og gyldig certifkat for kald til backends
- Eksempel på relevant driftinformation information, der returneres er f.eks. servicens version og tidspunkt for certifikat udløb
Status omkring alarm endpoint:
- Returnerer HTTP 500, hvis der er aktive alarmer og ellers HTTP 200.
- Returnerer tekst i text/plan format.
- Der returneres kun tekst, hvis der en alarm. Hver alarm adskilles med lf.
- En klassisk alarm holder øje med kald til ekstern service i et givet y tidsrum og melder fejl hvis antal fejl overstiger x antal.
Eksempel på status tekst, når alt er godt.
200 ok |
Eksempel på alarm tekst, når der har været for mange kald til person information uden svar:
500 Internal Server Error |
HealthIndictors
I den følgende tabel gives et overblik over de forskellige status og alarm check. Efterfølgende er enkelte af de forskellige check udbybet for relevant.
En Healthindicator kan være enten status- eller alarmindicator. Eller både og. Hvis tabellens celler er tomme for status eller alarm, betyder dette at den ikke er implementeret for den pågældende healthindicator.
Forklaring til tabellen:
- HealthIndicator: navn på healthIndicator. Dette er også navnet på klassen i sourcekoden
- Udførsel: det tjek der udføres ved health chekket
- Status 200: Den tekst status og/eller alarm returnerer ved kald når tjekket går godt
- Status 500: Den tekst status og/eller alarm returnerer ved kald når tjekket fejler
| Healthindicator | Udførsel/resultat | StatusIndicator tekst | AlarmIndicator tekst | Konfiguration (property) |
|---|---|---|---|---|
| DatasourceHealthIndicator for documentSourcesDS | Udførsel | Kalder datasource med den konfigurerede sql streng | Kalder datasource med den konfigurerede sql streng | documentsourcesds.statement |
Status 200 | {"Database DocumentSourcesDataSource":"OK"} | <empty> | ||
Status 500 | {"Database DocumentSourcesDataSource":"Ikke tilgængelig"} | Der er ingen forbindelse til databasen med navnet DocumentSourcesDataSource. | ||
| DatasourceHealthIndicator for authDataSource | Udførsel | Kalder datasource med den konfigurerede sql streng | Kalder datasource med den konfigurerede sql streng | authds.statement |
Status 200 | {"Database AuthDataSource":"OK"} | <empty> | ||
Status 500 | {"Database AuthDataSource":"Ikke tilgængelig"} | Der er ingen forbindelse til databasen med navnet AuthDataSource. | ||
| ConsentVerificationHealthIndicator | Udførsel | Tjekker antal fejl inden for en given periode ikke overstiger maks | verification.errorcount.duration:PT10M verification.error.tolerance:0 | |
| Status 200 | <empty> | |||
| Status 500 | Samtykke servicen har fejlet flere gange end tilladt i en given periode. | |||
| TreatmentRelationHealthIndicator | Udførsel | Tjekker antal fejl inden for en given periode ikke overstiger maks | treatment.relation.errorcount.duration:PT10M treatment.relation.error.tolerance:0 | |
| Status 200 | <empty> | |||
| Status 500 | Behandlerrelation servicen har fejlet flere gange end tilladt i en given periode. | |||
| PersonInformationHealthIndicator | Udførsel | Tjekker antal fejl inden for en given periode ikke overstiger maks | personinformation.errorcount.duration:PT10M personinformation.error.tolerance:0 | |
| Status 200 | <empty> | |||
| Status 500 | Person Information servicen har fejlet flere gange end tilladt i en given periode. | |||
| MinlogQueryMessagesHealthIndicator | Udførsel | Tjekker alle minlog tekster (activity) ikke er længere end 75 karakterer | minlog.query.default minlog.query.consentoverride minlog.query.childcustodyholder minlog.query.proxyholder minlog.query.citizen Samt data i tabellerne minlog_text og minlog_usertype_text (se også her) | |
| Status 200 | <empty> | |||
| Status 500 | Der er fejl i MinlogQueryMessages fordi de konfigurerede tekster er for lange. Se log fil for detaljer. | |||
| MinLogHealthIndicator | Udførsel | Tjekker antal fejl inden for en given periode ikke overstiger maks | minlog.errorcount.duration:PT10M minlog.error.tolerance:0 | |
| Status 200 | <empty> | |||
| Status 500 | MinLog servicen har fejlet flere gange end tilladt i en given periode. | |||
VersionHealthIndicator | Udførsel | Henter versionen i pom.properties | ||
| Status 200 | {"Version":"<version>"} | |||
| Status 500 | na - svarer altid 200 | |||
| StsHealthIndicator | Udførsel | Tjekker antal fejl inden for en given periode ikke overstiger maks | sts.errorcount.duration:PT10M sts.error.tolerance:0 | |
| Status 200 | <empty> | |||
| Status 500 | STS servicen har fejlet flere gange end tilladt i en given periode. | |||
| CertificateHealthIndicator | Udførsel | Tjekker om expiry date er indtruffet på det keystore angivet i property filen | Tjekker om expiry date indtræffer inden for given periode på det keystore angivet i property filen | sts.keystore sts.keystore.expiry.warning.duration |
| Status 200 | {"Servicens certifikat udløber den 2025-11-28T10:30:24.":"OK"} | <empty> | ||
| Status 500 | {"Servicens certifikat udløber den 2024-11-28T10:30:24.":"Udløbet"} eller {"Servicens certifikat kunne ikke findes eller har ingen udløbsdato.":"Ikke tilgængelig"} | Servicens certifikat er ved at udløbe. Det udløber den 2025-11-28T10:30:24. eller Servicens certifikat kunne ikke findes eller har ingen udløbsdato. | ||
| BackendRegistryHealthIndicator | Udførsel | Tjekker antal fejl inden for en given periode ikke overstiger maks for den enkelte registry der er konfigureret. | backend.errorcount.duration:PT10M database tabellen documentregistry.documentregistryfailurethreshold default failurethreshold er 5 | |
| Status 200 | <empty> | |||
| Status 500 | Backend med navnet <backend> har fejlet flere gange end tilladt i en given periode | |||
| BackendRepositoryHealthIndicator | Udførsel | Tjekker antal fejl inden for en given periode ikke overstiger maks for den enkelte repository der er konfigureret. | backend.errorcount.duration:PT10M database tabellen documentsource.failurethreshold default failurethreshold er 5 | |
| Status 200 | <empty> | |||
| Status 500 | Backend med navnet <backend> har fejlet flere gange end tilladt i en given periode | |||
DatasourceHealthIndicator - konfiguration af databasemonitorering
Databasemonitoreringen laver en simpel query mod databasen. Denne query er justbar og kan ændres i servicenes property filer.
DDSRegistry.properties:
documentsourcesds.statement=SELECT * FROM documentsources.documentregistry LIMIT 1; |
DDSRepository.properties:
documentsourcesds.statement=SELECT * FROM documentsources. documentsource LIMIT 1; |
...
hvilket hver giver output i stil med:
|
I eksemplet kørte servicen på en lokal maskine konfigureret til port 9090.
Specielt vedrørende testConnection på JBoss
På grund af en kendt fejl i JBoss 6, logges en række exceptions i server loggen, hvis følgende filer ikke findes (de må gerne være tomme):
|
Konfiguration af databasemonitorering
Databasemonitoreringen laver en simpel query mod databasen. Denne query er justbar og kan ændres i servicenes property filer.
DDSRegistry.properties:
|
DDSRepository.properties:
|
Test af monitorering af afhængigheder
Til Monitorering af afhængigheder til egen propertyfil, trådmanager, document registry (for DDS registry) og egen database findes en servlet i DDS Registry og Repository. Bemærk at denne snitflade laver kald til databasen og healthshare registry.Efter konfiguration og deploy af komponenterne kan det testes med:
|
Servicen returnerer følgende http koder:
- Der returneres http kode 200 ved normal situation.
- http fejlkode 404 returneres hvis servicen ikke er deployeret
- Hvis en eller flere af afhængighederne mangler eller ved intern fejl i WildFly returneres kode 500. Fejlbeskeden vil kunne ses i ddsregistry-servicecheck.log eller ddsrepository-servicecheck.log. Såfremt der ikke er nogen fejlbeskeder i loggen bør property-filen undersøges som det første, da det er herigennem logindstillingerne bestemmes.
Test af monitorering af status
Til Monitorering af forbindelser til BRS, MinLog, SamtykkeVerifikationsservice, PersonInformation, registries (DDS registry), repositories (DDS Repository), egen database og længde på konfigurerede minlog tekster findes en servlet i DDS Registry og Repository. Disse services opsamler f.eks. data på hvor mange kald til de forskellige andre services der er fejlet, og melder fejl hvis det overstiger de threshold-værdier der er defineret i property-filen.
...
|
Servicen returnerer følgende http koder:
- Der returneres http kode 200 ved normal situation.
- http fejlkode 404 returneres hvis servicen ikke er deployeret
- Hvis en eller flere af interne afhængighederne har fejlet nok gange til at nå deres grænseværdi returneres kode 203.
- Hvis en eller flere af ekserne afhængighederne (minlog osv) har fejlet nok gange til at nå deres grænseværdi returneres kode 500.
- Bemærk at
- DDS Registry anvender ”documentregistryfriendlyname” kombineret med ”documentregistryititransaction” (se afsnit 4.1.1.1) til identifikation af de forskellige indekser.
DDS Repository anvender ”service_endpoint” til identifikation af de forskellige repositories.
Fejlbeskeder vil kunne ses i ddsregistry-status.log henholdsvis ddsrepository-status.log
Opsamlingen af kald til en service der fejler nulstilles automatisk efter et antal sekunder. Dette styrres med en properti, servicestatuscheck.unlockdelay.
Nulstilling af opsamling af kald
Opsamlingen af kald der benyttes til monitoring af status kan nustilles. Servicen resetstatuscounters nulstiller alle de opsamlede data omkring fejlkald der har været siden sidste nulstilling.
...
Nulstil status for DDS Registry:
|
Nulstil status for DDS Repository:
|
Servicen returnerer følgende http koder:
- Der returneres http kode 200 ved normal situation.
Overvågning
DDS Registry og Repository overvåges hver af en servicespecifik servicechecksnitflade, samt en statussnitflade. Disse to snitfladers url’er kan aflæses i afsnit 2.
Placering af HTML overvågningsside
Under listen af komponenter først i dette dokument, er der henvisninger til overvågningssiderne.
Fortolkning af HTML overvågningsside
Alle overvågningssider returnerer enten status 200 hvis de i øjeblikket kører fint, status 404 hvis servicen ikke er deployeret, 203 mange fejl fra intern dds kald (DDS registry) og status 500, hvis der er opstået en fejl, og komponenten derfor ikke virker korrekt.
Overvågningstype
Simpel webside deployeret på serveren. Som udgangspunkt overvåges følgende:
...
Logfiler og fortolkning af disse
...