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.

Definitioner og forkortelser

Definition

Beskrivelse

NSP

Den nationale service platform (inden for sundheds-IT)

Overvågning - Statussnitflade

Løsningen kan overvåges med:

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


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

Eksempel på svar, hvor datasen er til rådoghed.

HTTP/1.1 200 OK

Database : OK 

Overvågning - Alarmsnitflade

Løsningen kan overvåges med:

http://<server>:<port>/minlog2-cleanup/alarm

som svarer HTTP OK tilbage, hvis alt fungerer eller svarere HTTP  Internal Server Error, hvis fejl.

Dette kald verificerer services, eksterne kald og databaseadgange.

Eksempel på svare, hvor personinformationservice ikke er tilgængelig.

HTTP/1.1 500 Internal Server Error

Baggrundsjobbet StackedOperationsService fejlede sidst det blev kørt. Problemet var: Data for CPR-nummeret kunne ikke findes, fordi kaldet til PersonInformation-servicen returnerede en uventet statuskode: 409.
Person Information servicen har fejlet flere gange end tilladt i en given periode.

Logfiler

Cleanup har eget sæt af logfiler – alle placeret i <jboss>/standalone/logs. 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

Applikationslog

Filen minlog2-cleanup-application.log indeholder applikationsloggen og kan benyttes i fejlsituationer og til statistik. 

timestamp="2025-01-29 14:37:06,321" threadId="MSC service thread 1-6" priority="INFO" category="dk.nsi.minlog2.util.Minlog2PropertiesProducer" message="minlog2-cleanup.properties properties successfully loaded from: minlog2-cleanup.properties"
timestamp="2025-01-29 14:48:25,149" threadId="default task-11" priority="INFO" category="dk.nsp.backgroundjob.service.StackedOperationsService" message="MinLog2 Deceased Cleanup: 366 new operations added to stack from Minlog2DeceasedCleanupSupplier"
timestamp="2025-01-29 14:48:25,197" threadId="default task-11" priority="INFO" category="dk.nsp.backgroundjob.service.StackedOperationsService" message="MinLog2 Deceased Cleanup: 0 new operations added to stack from CPRPrefixDeceasedCleanupSupplier"
timestamp="2025-01-29 14:48:25,200" threadId="default task-11" priority="INFO" category="dk.nsp.backgroundjob.service.StackedOperationsService" message="MinLog2 Deceased Cleanup: 0 new operations added to stack from CPRPrefixDeceasedCleanupSupplier"
timestamp="2025-01-29 14:48:25,207" threadId="default task-11" priority="INFO" category="dk.nsp.backgroundjob.service.StackedOperationsService" message="MinLog2 Deceased Cleanup: 1 new operations added to stack from CPRPrefixDeceasedCleanupSupplier"
timestamp="2025-01-29 14:48:25,278" threadId="default task-11" priority="ERROR" category="dk.nsi.minlog2.personinformation.PersonInformationServiceClientDeceased" message="Fejl i kald til PersonInformation: "
dk.nsi.minlog2.personinformation.exception.ValidationServiceException: Data for CPR-nummeret kunne ikke findes, fordi kaldet til PersonInformation-servicen returnerede en uventet statuskode: 409
    at dk.nsi.minlog2.personinformation.PersonInformationServiceClientDeceased.handleResponse(PersonInformationServiceClientDeceased.java:152)

Konfigurationer

Databaseadgang konfigureres i datasource filer i:

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

Cleanup snitflade

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

Det er muligt at starte cleanup på følgende adresser:

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

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

Cleanup job

Slettejob står for at slette logentries i databasen og jobbene er lavet efter standarden for baggrundsjob på NSP.

MinLog2-cleanup består af 2 slettejob, som kan startes seperat og dermed afvikles uafhængigt af hinanden.

For hvert slettejob gælder, at de skal kunne dele opslag, filtreringer og udførsel af sletningerne op i så små opgaver, at 1 eller flere opgaver kan udføres indenfor en afsat tidsramme (deletion.desired.execution.duration). 

Ifølge den nye standard for baggrundsjob, så fortsættes rækken af opgaver fra den opgave, hvor jobbet sluttede sidst. Dermed undgås det, at de samme opgaver skal udføres hver gang jobbet kaldes.


Følgende properties er angivet ift. afviklingen af baggrundsjob i Minlog2-cleanup:

# Max. antal CPR vi forespørger på i en enkelt request til personinformation
personinformation.batchsize=100

# PersonInformation integration
personinformation.url=http://test1-cnsp.ekstern-test.nspop.dk:8080/stamdata-personinformation/v1
personinformation.maxTotalConnections=200
personinformation.defaultMaxConnectionsPerRoute=20
personinformation.error.tolerance=0

# Max. antal logentry vi sletter i hver sletning
deletion.batchsize=1000

# Den tid vi ønsker at bruge på sletning ved hvert request.
# Tiden er ikke geranteret, da vi kun tjekker mod den efter hver StackOperation er udført.
deletion.desired.execution.duration=PT20S

# Den tid som skal gå før vi sletter data for en afdød person.
# Dette gøres så vi ikke sletter data, hvis personens status ændres til afdød og derefter tilbage til levende.
deletion.save.deceased=P60D

# Antal dage der skal gå før vi betragter logentries, som værende for gamle.
# Værdien er i dage.
days.to.remain.persisted=730

# Max. antal logentries vi tillader i resultatet af en query, hvor der ledes efter logentries der skal slettes.
query.limit=1000

# JNDI til datasource for Minlog2 Cleanup
dk.nsp.log4j.datasource.jndi=java:jboss/datasources/minlog2DS

Minlog2DeceasedCleanup

Dette slettejob finder alle eksisterende CPR-numre i minlog-databasen og tjekker vha. personinformationservicen om den pågældende person er død. Der er indbygget i den logik, at personen skal være død i en angivet periode (deletion.save.deceased) inden data slettes fra databasen.

Der tjekkes mod personinformation servicen om en person var død på tidspunktet for dags dato minus perioden deletion.save.deceased. Der tjekkes kun for personinformation.batchsize ad gangen.

Udtrækket bliver så opdelt i mindre opgaver, hvor et antal (deletion.batchsize) rækker slettes.




Følgende properties bruges i afviklingen af dette slettejob:

# Max. antal CPR vi forespørger på i en enkelt request til personinformation
personinformation.batchsize=100

# PersonInformation integration
personinformation.url=http://test1-cnsp.ekstern-test.nspop.dk:8080/stamdata-personinformation/v1
personinformation.maxTotalConnections=200
personinformation.defaultMaxConnectionsPerRoute=20
personinformation.error.tolerance=0

# Den tid som skal gå før vi sletter data for en afdød person.
# Dette gøres så vi ikke sletter data, hvis personens status ændres til afdød og derefter tilbage til levende.
deletion.save.deceased=P60D

# Max. antal logentry vi sletter i hver sletning
deletion.batchsize=1000

Minlog2TimeBasedCleanup

Dette slettejob finder og slette de ældste log-data i databasen, som er ældre end en angivet periode (days.to.remain.persisted).

Der udtrækkes max. det antal rækker, som er angivet i query.limit

Udtrækket bliver så opdelt i mindre opgaver, hvor et antal (deletion.batchsize) rækker slettes.



Følgende properties bruges i afviklingen af dette slettejob:

# Antal dage der skal gå før vi betragter logentries, som værende for gamle.
# Værdien er i dage.
days.to.remain.persisted=730

# Max. antal logentries vi tillader i resultatet af en query, hvor der ledes efter logentries der skal slettes.
query.limit=1000

# Max. antal logentry vi sletter i hver sletning
deletion.batchsize=1000