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

Overvågning

Statussnitflade

Løsningen kan overvåges med:

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

Snitfladen svarer HTTP 200, hvis komponenten kan modtage forespørgsler, og HTTP 500, hvis den ikke kan. NSP-loadbalanceren bruger svaret til at ind- og udmelde komponenten.

Kaldet verificerer adgang til registrerings-databasen og til Kafka Proxyen, som registreringer afleveres til.

Svaret er et JSON-array med driftsinformationer, herunder komponentens versionsnummer. Rækkefølgen af de øvrige elementer er ikke garanteret.

HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8

[{"Version":"2.6.0"},{"MinLog2 database":"OK"},{"Kafka Proxy":"OK"}]

Svarer en indikator Unavailable, er statuskoden 500, og komponenten tages ud af loadbalanceren indtil forholdet er udbedret. Der skrives samtidig en linje i loggen med årsagen; den gentages højst én gang i minuttet for samme årsag.

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 de samme.

Alarmsnitflade

Løsningen kan overvåges med:

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

Snitfladen svarer HTTP 500, hvis der er aktive alarmer, og HTTP 200, hvis der ingen er. Svaret er text/plain med én linje per aktiv alarm; ved ingen alarmer returneres den tomme streng.

Aktive alarmer melder ikke komponenten ud af loadbalanceren – det er statussnitfladens opgave. Aktive alarmer skrives også i loggen, højst én gang i minuttet per alarm.

HTTP/1.1 500 Internal Server Error
Content-Type: text/plain;charset=UTF-8

Der er ingen forbindelse til Kafka Proxyen på http://kafkaproxy:8080/minlog2-kafka-proxy/status.

Service snitflade

Løsningerne tilgås på

DKS snitflade

DKS for Registration-service på minlog2 findes på følgende url'er.

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

# DCC Endpoint

minlog2.endpoint.register=http://test1-cnsp.ekstern-test.nspop.dk:8080/minlog2-registration

Funktionalitet

Servicene stiller metoder til rådighed til at registrere 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

Registration afhænger af registrerings-databasen og af Kafka Proxyen, som registreringer afleveres til. Det må derfor forventes, at den mest sandsynlige kilde til fejlsituationer er problemer med databaseadgang eller med Kafka Proxyen. Det forudsættes at databaseskema, tabeller og brugere herunder rettighederne er på plads:

• SELECT
• INSERT
• UPDATE
• DELETE

Begge dele fremgår af status- og alarmsnitfladen, og detaljer vil være tilgængelige i loggen. Yderligere fejl vil også kunne spores i loggen.

Logfiler

Registration og 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-registration-application
• minlog2-registration-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

SLA log

nsputil-sla-minlog2.log indeholder SLA loggen. Loggen indeholder målepunkter for service- og Kafka kald. Kaldet til Kafka 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.

Audit log

Audit-logning foretages med det officielle "NSP Audit API" modul.

Der laves audit-logning i:

• lookup
• registration

Informationer, der logges:

Eksempler fra auditloggen:

{
  "time": "2022-06-13T14:49:29.09Z",
  "category": "dk.sds.nsp.audit.log.minlog2",
  "audit": {
    "timestamp": "2022-06-13T16:49:29.046+02:00",
    "components": [
      {
        "component": "MinLog2",
        "contexts": [
          {
            "context": "LookupRequest",
            "information": [
              {
                "key": "Caller",
                "type": "SPI",
                "value": "1010780337"
              },
              {
                "key": "Parameters",
                "type": "SPI",
                "value": "NA"
              }
            ]
          }
        ]
      }
    ]
  },
  "access": {
    "code": 200,
    "duration": 39,
    "httpHeaders": {
      "Content-Type": "text/xml; charset=UTF-8",
      "SOAPAction": "\"GetLogStatementsForCPRPersonWithID\""
    },
    "httpHost": "localhost",
    "idCardAttributes": {
      "dk:gov:saml:attribute:AssuranceLevel": "3",
      "dk:gov:saml:attribute:CprNumberIdentifier": "1010780337",
      "dk:gov:saml:attribute:SpecVer": "DK-SAML-2.0"
    },
    "method": "POST",
    "path": "/minlog2-lookupid/LookupidService",
    "query": "",
    "port": 8081,
    "protocol": "http",
    "reqSize": 11810,
    "resSize": 21707,
    "soapHeaders": {
      "Audience": "https://minlog",
      "Issuer": "TEST2-NSP-STS",
      "NameID": "C=DK,O=Ingen organisatorisk tilknytning,CN=Lars Larsen,Serial=PID:9208-2002-2-633568693394",
      "w3Action": "action",
      "w3MessageID": "64d6a252-f391-460c-a90b-1ea7d8512cd8"
    },
    "threadId": "default task-102",
    "time": "2022-06-13T16:49:29.046+02:00",
    "stats": {
      "handlerDuration": 3,
      "RequestContentDuration": 0,
      "ResponseContentDuration": 0,
      "SecurityProtocolRequestDuration": 0,
      "SecurityProtocolResponseDuration": 0,
      "bufferAllocated": false,
      "usedBuffers": 2,
      "activeBuffersInPool": 2,
      "idleBuffersInPool": 29
    }
  }
}

Applikationslog

Filen minlog2-registration-application.log og minlog2-lookup-application.log indeholder loggen 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.

Pool size

Hvis den konfigurede pool størrelse (producer.pool.count) er for lille kan nedenstående error logning ses. Hvis pool size ændres skal servicen genstartes.

Message producer pool empty. Consider increasing property producer.pool.count.

Konfigurationer

Databaseadgang konfigureres i datasource filer i:

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

Se i øvrigt installationsvejledningen.

Whitelisting

For at et anvender kan kalde en bestemt registration-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:

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

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

• registration
• registration_20210511
• registration_20230425

Batch job

Lookup applikationen indeholder følgende batchjobs:

• Sletning af logentries
• Opdatering af kommune cache

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

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

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 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.

Baggrund for vurdering af belastning

TBD