Indhold


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.407-09-2018OpenmindsBeskrivelse af ny borgerservice

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-registration/monitor


Eller


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

http://<server>:<port>/minlog2-lookupid/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-registration/monitor?details


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

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


Denne viser status for eventuelle services og databaseadgange.

Eksempel på svar, hvor databasen er til rådighed.


MinLog2 database : OK
Stamdata database : OK


Version

Løsningernes versioner kan vises med:


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


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

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

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

Service snitflade

Løsningerne tilgås på


http://<server>:<port>/minlog2-registration/RegisterService


Eller


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

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


Funktionalitet

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

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

Registration og Lookup har eget sæt af logfiler – alle placeret i <jboss>/standalone/logs. SLA logning sker til samme 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.

Logpunkter til servicekald benytter soap operationen som Logpoint og LogPointUniqId, mens databasekald benytter "DB_Operation" som Logpoint og en tekstuel beskrivelse af opslaget som LogPointUniqId

Service- og databasekald er korrelerede med messageID.

Eksempel GetLogStatementForCPRPerson udløser flere databasekald: Et hvor logentries slåes op, et hvor personnavn hentes fra Stamdata og et opslag på organistationsid'et.

Alle 3 logpunkter deler Messageid hentet fra SOAP headeren.

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-registration-audit.log og minlog2-lookup-audit.log indeholder logning af alle kald med information om, hvem der har kaldt hvad.

Eksempel fra auditloggen. "Action" udpeger, hvad der er kaldt, "Caller" hvem der har kaldt og "Params" en json repræsentation af inputparametre:

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-registration-application.log og 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


SLA log configures i:


<jboss>/standalone/configuration/nspslalog-minlog2.properties


Øvrige konfigurationer (log og systemspecifikke konfigurationer) findes i:


<jboss>/modules/nsi/minlog2/config/main


Se i øvrigt installationsvejledningen.

Batch job

Lookup applikationen indeholder følgende batchjobs:

Jobbene 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 cleanup job:

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). Jobbet kører indtil der ikke er flere at slette eller der er mindre end 10 minutter til næste job starter.

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

<jboss>/standalone/configuration/kommuner.json

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

Se i øvrigt 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