Page History

Versions Compared

Key

This line was added.
This line was removed.
Formatting was changed.

Navitabs

root	MinLog2 - Leverancebeskrivelse
firsttab	MinLog2
includeroot	true

Indhold

Table of Contents

Indledning

Læsevejledning

Læseren forventes at have kendskab til National Sundheds-IT's platform NSP, samt generelt kendskab til WildFly applikation server, MariaDB og java.

Dokumenthistorik

...

Version

...

Dato

...

Ansvarlig

...

Beskrivelse

...

1.3

...

28-10-2017

...

Openminds

...

Beskrivelse af organisation job

...

1.2

...

Openminds

...

Beskrivelse af clean up job

...

1.1

...

26-06-2017

...

Openminds

...

Nærmere specificering af Logning

...

1.0

...

09-06-2017

...

Openminds

Definitioner og forkortelser

Definition	Beskrivelse
NSP	Den nationale service platform (inden for sundheds-IT)

Monitoreringssnitflade

Løsningen kan overvåges med:

http://<server>:<port>/minlog2-lookup/monitor

http http://<server>:<port>/minlog2-lookupid/monitor

http://<server>:<port>/minlog1-lookup/monitor

som svarer HTTP OK tilbage, hvis alt fungerer. Dette kald verificerer services samt databaseadgang.

Generel overvågningsflade

Det er muligt at få vist yderligere detaljer med:

http://<server>:<port>/minlog2-lookup/monitor?details

http http://<server>:<port>/minlog2-lookupid/monitor?detailshttp://<server>:<port>/minlog1-lookup/monitor?details

Denne viser status for eventuelle services og databaseadgange.

...

MinLog2 database : OK
Stamdata database : OK

Version

Løsningernes versioner kan vises med:

http://<server>:<port>/minlog2-lookup/version

http http://<server>:<port>/minlog2-lookupid/versionhttp://<server>:<port>/minlog1-lookup/version

Der er intet krav om at versionerne skal "følges" ad – således kan eksempelvis "Registration 2.0.1 godt fungere sammen med Lookup 2.5.1. Det bør tilstræbes at versionerne er det samme.

Service snitflade

Løsningerne tilgås på:

http://<server>:<port>/minlog2-lookup/LookupService?wsdl

http http://<server>:<port>/minlog2-lookupid/LookupidService?wsdl

DKS snitflade

DKS for Lookup- og Lookupidservice på minlog2 findes på følgende url'er.

http://<server>:<port>/minlog2-lookup/dksconfig

http://<server>:<port>/minlog2-lookup/20241101/dksconfig

http://<server>:<port>/minlog2-lookup/20250312/dksconfig

http://<server>:<port>/minlog2-lookupid/dksconfig

http://<server>:<port>/minlog2-lookupid/20241101/dksconfig

http://<server>:<port>/minlog2-lookupid/20250312/dksconfig

Følgende properties bruges i DKS til opbygning af endpoint.

# DCC Endpoint
minlog2.endpoint.lookupid=http://test1-cnsp.ekstern-test.nspop.dk:8080/minlog2-lookupid
minlog2.endpoint.lookup=http://test1-cnsp.ekstern-test.nspop.dk:8080/minlog2-lookup

Cleanup snitflade

Det er muligt at starte og se status for cleanup på:

http://<server>:<port>/minlog2-lookup/cleanup/start

http://<server>:<port>/minlog2-lookup/cleanup/statusminlog1-lookup/LookupService?wsdl

Funktionalitet

Servicene stiller metoder til rådighed til at fremsøge cpr relaterede hændelser.

Adgang er håndteret med IDCard. Der kan jf. Netic etableres blacklistning i HAProxy og/eller firewall på NSP'erne.

Håndtering af fejlsituationer

De eneste eksterne afhængigheder er til databaser. Det må derfor forventes, at den mest sandsynlige kilde til fejlsituationer er problemer med databaseadgang. Det forudsættes at databaseskema, tabeller og brugere herunder rettighederne er på plads:

...

Dette vil fremgå af overvågningsfladen og detaljer vil være tilgængelige i applikationsloggen. Yderligere fejl vil også kunne spores i applikationsloggen.

Logfiler

Lookup har eget sæt af logfiler – alle placeret i <jboss>/standalone/logs. SLA logning sker til en særlig fil – "nsputil-sla-minlog2.log". Derudover kan der forekomme logning til server.log.

...

Logformaterne kan findes i log4j filerne som er placeret i Wildfly – se konfigurationer – og hjælp til patterns kan findes i forbindelse med Log4J:

https://logging.apache.org/log4j/1.2/apidocs/org/apache/log4j/PatternLayout.html

SLA log

nsputil-sla-minlog2.log indeholder SLA loggen. Loggen indeholder målepunkter for service- og databasekald. Databasekaldet foregår inden for servicekaldet og har til formål at gøre det synligt, hvor tiden går.

...

2017-06-26 08:22:05,751 [default task-4] INFO dk.sdsd.nsp.slalogdata - LogPoint="DB_Operation" LogPointUniqId="lookupPersonName" StartTime="2017-06-26 08:22:05.750" EndTime="2017-06-26 08:22:05.750" Duration="767 microseconds" MessageId="AAABXOMQcV1mt6jYItbXz1NPU0k=" RequestSize=0 ReplySize=0 Result=OK ClientIP="<empty>" SOAPOperation="<empty>" SOAPEndpoint="<empty>" SOAPAction="<empty>" TargetSOAPOperation="<empty>" TargetSOAPEndpoint="<empty>" GenericCallParms(0)= { }

2017-06-26 08:22:05,773 [default task-4] INFO dk.sdsd.nsp.slalogdata - LogPoint="DB_Operation" LogPointUniqId="getLogStatements" StartTime="2017-06-26 08:22:05.141" EndTime="2017-06-26 08:22:05.773" Duration="632086 microseconds" MessageId="AAABXOMQcV1mt6jYItbXz1NPU0k=" RequestSize=0 ReplySize=0 Result=OK ClientIP="<empty>" SOAPOperation="<empty>" SOAPEndpoint="<empty>" SOAPAction="<empty>" TargetSOAPOperation="<empty>" TargetSOAPEndpoint="<empty>" GenericCallParms(0)= { }

2017-06-26 08:22:05,997 [default task-4] INFO dk.sdsd.nsp.slalogdata - LogPoint="minlog2.GetLogStatementsForCPRPerson" LogPointUniqId="minlog2.GetLogStatementsForCPRPerson" StartTime="2017-06-26 08:22:04.657" EndTime="2017-06-26 08:22:05.997" Duration="1340017 microseconds" MessageId="AAABXOMQcV1mt6jYItbXz1NPU0k=" RequestSize=0 ReplySize=0 Result=OK ClientIP="127.0.0.1" SOAPOperation="GetLogStatementsForCPRPerson" SOAPEndpoint="http://localhost:8080/minlog2-lookup/LookupService" SOAPAction="GetLogStatementsForCPRPerson" TargetSOAPOperation="<empty>" TargetSOAPEndpoint="<empty>" GenericCallParms(0)= { }

Audit log

Filen minlog2-lookup-audit.log indeholder logning af alle kald med information om, hvem der har kaldt hvad.

...

2017-06-26 08:22:04,267 Action=AddRegistrations Caller=46837428 Params={"logDataEntry":[{"source": {"correlationId":"40075148-7b1b-476c-b5c34181a39650c5","systemName":"TestSystem", "source":{"correlationId":"40075148-7b1b-476c-b5c34181a39650c5","systemName":"TestSubSystem", "source":null}},"destination":{"systemName":"Integrationtest","activity":"Inserting","reason":"h","addition":null,"criticality":"Ingen","dateTime":1498458123444,"fromDateTime":null,"toDateTime":null,"organisationId":{"value":"240971000016006","source":"SOR"},"organisationName":"Openminds","personIdentifier":{"value":"2412752045","source":"CPR"},"personName":"Test Tester","correlationId":"40075148-7b1b-476c-b5c3-4181a39650c5","sequenceNumber":"1","userPersonIdentifier":{"value":"2412751044", "source":"CPR"},"userPersonName":"Sygeplejerske Jensen","userRole":"UserRole", "onBehalfOfPersonIdentifier":{"value":"2412751946","source":"CPR"},"onBehalfOfPersonName":"Læge Olsen","onBehalfOfUserRole":"OnBehalfOfUserRole","filter":["Ikke borger","Ikke forældremyndighedsindehaver"]}}]}

Applikationslog

Filen minlog2-lookup-application.log indeholder applikationsloggen og kan benyttes i fejlsituationer og til statistik. På nuværende tidspunkt anvendes denne primært til logning i forbindelse med batchjob og indlæsning til cache.

2017-06-27 11:31:12,535 INFO [dk.nsi.minlog2.lookup.controller.CleanUpController] CleanUp job created. 2017-06-27 11:31:12,536 INFO [dk.nsi.minlog2.lookup.controller.CleanUpController] Set to run at: ScheduleExpression[second=0 minute=/1 hour= dayOfWeek=* dayOfMonth=* month=* year=* start=null end=null timezone=] 2017-06-27 11:31:12,536 INFO [dk.nsi.minlog2.lookup.controller.CleanUpController] Batch/limitsize: 10000 2017-06-27 11:31:12,536 INFO [dk.nsi.minlog2.lookup.controller.CleanUpController] Days to remain in database: 730 2017-06-27 11:32:00,031 INFO [dk.nsi.minlog2.lookup.controller.CleanUpController] Starting cleanup 2017-06-27 11:32:00,157 INFO [dk.nsi.minlog2.lookup.controller.CleanUpController] Number of old logentries to be deleted are: 0 2017-06-27 11:32:00,160 INFO [dk.nsi.minlog2.lookup.controller.CleanUpController] Number of remaining old logentries are: 0 2017-06-27 11:32:00,160 INFO [dk.nsi.minlog2.lookup.controller.CleanUpController] Ending cleanup

Konfigurationer

Databaseadgang konfigureres i datasource filer i:

<jboss>/standalone/deployments/minlog2-ds.xml
<jboss>/standalone/deployments/minlog2-stam-ds.xml
<jboss>/standalone/deployments/minlog2-fo-ds.xml

SLA log og øvrige konfigurationer (log og systemspecifikke konfigurationer) findes i:

...

Se i øvrigt installationsvejledningen.

Whitelisting

For at et anvender kan kalde en bestemt lookup-snitflade, skal de whitelistes først. Dette gøres enten på deres CVR-nummer eller via et certifikats SSN som indsættes i whitelist-tabellen.

Eksempler:

Code Block

language	sql

INSERT INTO whitelist (operation, identification_type, identification, note) VALUES ('lookup_20241101', 'SSN', 'UI:DK-O:G:8d3fa047-c77e-47e4-bdd2-e91488610ce6', 'En note');
INSERT INTO whitelist (operation, identification_type, identification, note) VALUES ('lookupid_20241101', 'CVR', '33257872', 'En note');

Operationen der whitelistes på, er altid en bestemt version af en operation. Herunder er de lookup-operationer der pt. kan whitelistes til:

lookup
lookup_20241101
lookup_20250312
lookupid
lookupid_20241101
lookupid_20250312

Der er derudover også behov for at whitelisting til opslag, hvor en borger laver opslag på vegne af en anden borger i rollen som "værge". Til det skal det kaldene certifikat whitelistes til, at man må komme ind som værge af den vej (i praksis kun FMK).

Operationen hedder:

claimWardRelation

Og et eksempel på en whitelistning af denne:

Code Block

language	sql

INSERT INTO whitelist (operation, identification_type, identification) VALUES ('claimWardRelation', 'SSN', 'UI:DK-O:G:8d3fa047-c77e-47e4-bdd2-e91488610ce6');

Ved whitelistning af claimWardRelation, er det kun muligt at angive "identification_type" som "SSN".

Cleanup job

Servicens slettejob, står for at slette logentries i databasen.
Det bliver afviklet vha. en udstillet RestController, som kaldes vha. simpelt HTTP GET kald.
Dette gøres for at sikre afviklingen af slettejob i flere-node drift, hvor en loadbalancer sørger for fordeling af kald til bagvedliggende servere.

Driften vedligeholder en cron, som kalder slettejobbets url i et fast mønster vha. curl.

Følgende parametre til styring af slettejobbet kan ændres i application.properties for MinLog2:

days.to.remain.persisted=730
cleanupjob.runtime.max=25000
sql.delete.batch.size=10000
sleep.after.batch=2000

Alle rækker som er ældre end days.to.remain.persisted (her 2x365) fra dags dato slettes med en limit på sql.delete.batch.size (her 10000). Efter hvert batch tjekkes den samlede tid for den aktuelle afvikling, og hvis der er gået mere tid end angivet i cleanupjob.runtime.max (her 4 minutter), så afsluttes aktuelle afvikling.
Derved sørger cleanupjob.runtime.max for at begrænse udførselstiden for slettejobbet, for at undgå at ramme HTTP timeout.

Kommando til kald af slettejob:

curl <server>/minlog2-lookup/cleanup/start

Status for seneste cleanup kan ses på:

http://<server>:<port>/minlog2-lookup/cleanup/status

Batch job

Lookup applikationen indeholder følgende batchjobsbatchjob:

Sletning af logentries
Opdatering af kommune cache

Jobbene Jobbet initialiseres ved start af Wildfly. minlog2.properties indeholder parametre til konfiguration af jobbet – her markeret med fed:

sql.max.logevents.allowed.in.query=10000
federation=test
days.to.remain.persisted=730
sql.delete.batch.size=10000
cleanupjob.start.hour=3
cleanupjob.start.minute=0
organisationjob.start.hour=1
organisationjob.start.minute=0

Jobbet startes hver dag på et bestemt tidspunkt (her hvert 10 minut mellem kl. 03.00 og kl. 04.00). Her cleanup job:

Et enkelt batch skal være færdigafviklet inden der er gpet 5 minutter, da dette er timeout for transaktioner.

Ved nuværende properties så vil opydningsjobbet blev afviklet 6 gange indenfor 1 time.

Hvert jobbet kører indtil der ikke er flere at slette eller den tid der er mindre end 10 minutter til næste job starterafsat til hver afvikling er nået.

Kommune cache (kommunekode, kommunenavn) indlæses ved opstart. Se :

...

Filen er iøvrigt en kopi af kommuneinformationer taget fra grunddata - https://dawa.aws.dk/kommuner.

Se i øvrigt Opslag driftsvejledning Applikationslog

Backup

Der skal tages backup af minlog2 databasen og evt. konfigurationsfilerne nævnt i installationsvejledningen.

Belastning

Servicemålene herunder er for henholdsvis MinLog 2 RegistrationService og LookupService.

Service	Servicemål
Svartider opdatering	95 % af tilfældene ≤ 6,5 sek
	98 % af tilfældene ≤ 15,5 sek
Svartider forespørgsler	95 % af tilfældene ≤ 2,5 sek
	98 % af tilfældene ≤ 5,5 sek

Baggrund for vurdering af belastning

TBD

Content

Space Tools

Versions Compared

Old Version 21

New Version Current

Key

Indhold

Indledning

Læsevejledning

Dokumenthistorik

Definitioner og forkortelser

Monitoreringssnitflade

Generel overvågningsflade

Version

Service snitflade

DKS snitflade

Cleanup snitflade

Funktionalitet

Håndtering af fejlsituationer

Logfiler

SLA log

Audit log

Applikationslog

Konfigurationer

Whitelisting

Cleanup job

Batch job

Backup

Belastning

Baggrund for vurdering af belastning