1. Indhold
2. Indledning
2.1. 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.
2.2. Dokumenthistorik
Version | Dato | Ansvarlig | Beskrivelse |
1.6 | 05-08-2020 | Openminds | Ændringer til logning |
1.5 | 26-04-2019 | Openminds | Tilføjelse af MinLog1 lookup og registrering |
1.4 | 07-09-2018 | Openminds | Beskrivelse 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 |
2.3. Definitioner og forkortelser
Definition | Beskrivelse |
NSP | Den nationale service platform (inden for sundheds-IT) |
2.4. Monitoreringssnitflade
Løsningen kan overvåges med:
http://<server>:<port>/minlog2-lookup/monitor 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.
2.5. Generel overvågningsflade
Det er muligt at få vist yderligere detaljer med:
http://<server>:<port>/minlog2-lookup/monitor?details http://<server>:<port>/minlog2-lookupid/monitor?details http://<server>:<port>/minlog1-lookup/monitor?details |
Denne viser status for eventuelle services og databaseadgange.
Eksempel på svar, hvor databasen er til rådighed.
MinLog2 database : OK |
2.6. Version
Løsningernes versioner kan vises med:
http://<server>:<port>/minlog2-lookup/version http://<server>:<port>/minlog2-lookupid/version http://<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.
2.7. Service snitflade
Løsningerne tilgås på:
http://<server>:<port>/minlog2-lookup/LookupService?wsdl http://<server>:<port>/minlog2-lookupid/LookupidService?wsdl http://<server>:<port>/minlog1-lookup/LookupService?wsdl |
2.8. 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/status |
2.9. 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.
2.10. 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:
- SELECT
- INSERT
- UPDATE
- DELETE
Dette vil fremgå af overvågningsfladen og detaljer vil være tilgængelige i applikationsloggen. Yderligere fejl vil også kunne spores i applikationsloggen.
2.11. 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.
- minlog2-lookup-application
- minlog2-lookup-audit
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
2.11.1. 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 database-og kafkakald benytter "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)= { } |
2.11.2. Audit log
Filen 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"]}}]} |
2.11.3. 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 |
2.12. Konfigurationer
Databaseadgang konfigureres i datasource filer i:
<jboss>/standalone/deployments/minlog2-ds.xml |
SLA log og øvrige konfigurationer (log og systemspecifikke konfigurationer) findes i:
<jboss>/standalone/configuration/ |
Se i øvrigt installationsvejledningen.
2.13. 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
2.14. Batch job
Lookup applikationen indeholder følgende batchjob:
- Opdatering af kommune cache
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 |
Jobbet startes hver dag på et bestemt tidspunkt (her hvert 10 minut mellem kl. 03.00 og kl. 04.00). 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). 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.
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 afsat til hver afvikling er nået.
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
2.15. Backup
Der skal tages backup af minlog2 databasen og evt. konfigurationsfilerne nævnt i installationsvejledningen.
2.16. 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 |
2.16.1. Baggrund for vurdering af belastning
TBD