Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: SDS-6515 Tilføj eksempel på application.properties

...

URL

Funktionalitet

<server>/fsk/actuator/info

Status-side. Se afsnittet versionsinformation.

<server>/fsk/actuator/health
Status-side. Viser om servicen fungerer korrekt, se afsnittet Overvågning.

Daglig drift

Servicen kræver ingen daglig vedligeholdelse udover sædvanlig systemovervågning.

Versionsinformation

Servicen udstiller en statusside med versionsinformation. Der returneres en body med JSON-data.
"$.build" indeholder oplysninger om versionen, og hvornår den blev bygget.
"$.time" indeholder oplysninger om det aktuelle tidspunkt, og tidspunktet for hvornår servicen blev deployed.

Eksempel:

Code Block
languagetext
{
    "build": {
        "version": "2.0.8",
        "artifact": "fsk-service",
        "name": "fsk-service",
        "group": "dk.sundhedsdatastyrelsen.stamkort",
        "time": "2019-07-30T07:30:22.496Z"
    },
    "time": {
        "currentTime": "2019-07-30T13:16:18.761Z",
        "deployed": "2019-07-30T13:16:10.382Z"
    }
}

Overvågning

De følgende afsnit beskriver emner i servicen, der kræver opmærksomhed ift. driften.

Health-statusside

Servicen udstiller en Health-statusside (også typisk kendt som isAlive), der viser om applikationen er sund, eller om noget kræver indgriben. Health-statussiden returnerer en body med JSON-data, der beskriver sundhedsstatus for forskellig funktionalitet i applikationen.

Health-statussiden er opbygget vha. Spring Boot Actuator, som er konfigureret med nogle specialfremstillede HealthIndicators.

Actuator beregner en overordnet status for applikationens tilstand, som baseres på den HealthIndicator, der returnerer den mest fatale status. Denne overordnede status vises i JSON-property'en "$.status". Se eksempler længere nede.

Der er udover standard Actuator statusser defineret en specielfremstillet status (NEEDS_ATTENTION). Den følgende tabel viser alle statusser i rækkefølge fra sund til fatal. Tabellen viser også den HTTP statuskode, som Health-statussiden vil returnere til en given overordnet status:

...

Opførsel for forskellige HealthIndicators

Nogle HealthIndicators anvender ikke nødvendigvis alle statusser men kun udvalgte. Følgende tabel viser, hvad de enkelte HealthIndicators tjekker, og hvornår de returnerer en specifik status.

Bemærk, at det kun er "db"-HealthIndicator'en der kan returnere statussen "DOWN" og dermed udløse HTTP statuskoden "500 Internal Server Error".

...

$.details.organDonorClient
$.details.livingWillClient
$.details.treatmentWillClient
$.details.personalDataCardRegisterClient
$.details.scesClient
$.details.minLogClient

...

Tjekker om det seneste kald med den pågældende integration var succesfuldt. Hvis det ikke var succesfuldt, så viser "error" en toString() på den exception der opstod. Der vises eventuelt "timeOfLastExecution", som angiver det seneste tidspunkt, hvor et kald blev forsøgt (uanset om det var successfuldt eller ikke-successfuldt).

Statuskode 200: OK
Statuskode 203: Der opstod en fejl under seneste forsøg på at kalde med den pågældende integration.

...

Er baseret på Actuator's indbyggede DataSourceHealthIndicator og tjekker, at der kan udføres en "SELECT 1" query på alle applikationens datasources. Query'en udføres i det øjeblik Health-statussiden forespørges. Der vises detaljer om status for de enkelte datasources.

Statuskode 200: OK
Statuskode 500: Der opstod en fejl under forsøget på at udføre test-query'en på en af applikationens datasources.

Opsætning

I application.properties kan der indstilles forkellige ting. Her følger et eksempel:

Code Block
author.institution.root=1.2.208.176.1.1
author.institution.extension=1126211000016009
author.institution.assigningAuthorityName=SOR
author.institution.name=Sundhedsdatastyrelsen

# Whitelisted CVRs (comma-separated) that are allowed to call with DGWS level 3
whitelisted.level3.cvrs=31908574,33257872

health.certificate-expires-warning=30

# JNDI datasource properties
datasource-fsk.jndi-name=java:jboss/datasources/FSK-DS
datasource-stm.jndi-name=java:jboss/datasources/STM-DS

sts.endpoint=http://test1.ekstern-test.nspop.dk:8080/sts/services/NewSecurityTokenService

# Minlog
minlog.read-activity.text=Opslag i Stamkort
minlog.on.idcard.level3.enabled=true

# SCES
sces.enable=true
sces.endpoint=http://test1.ekstern-test.nspop.dk:8080/stamdata-cpr-ws/service/DetGodeCPROpslag-1.0.4
sces.connect.timeout.millis=2000
sces.read.timeout.millis=7000

# ODR
odr.enable=true
odr.endpoint=http://test1-cnsp.ekstern-test.nspop.dk:8080/odr/odr
odr.connect.timeout.millis=2000
odr.read.timeout.millis=7000

# LTR
ltr.enable=true
ltr.endpoint=http://test1-cnsp.ekstern-test.nspop.dk:8080/btr/ltr
ltr.connect.timeout.millis=2000
ltr.read.timeout.millis=7000

# BTR
btr.startdatetime=2019-01-01 00:00:00
btr.enable=true
btr.endpoint=http://test1-cnsp.ekstern-test.nspop.dk:8080/btr/btr
btr.connect.timeout.millis=2000
btr.read.timeout.millis=7000

# SKR
skr.enable=true
skr.endpoint=http://test1-cnsp.ekstern-test.nspop.dk:8080/skr/skr
skr.connect.timeout.millis=2000
skr.read.timeout.millis=7000

# SYES
syes.endpoint=http://test1-cnsp.ekstern-test.nspop.dk:8080/stamdata-yder-lookup-ws/service/YderService
syes.connect.timeout.millis=2000
syes.read.timeout.millis=7000

# DDS
dds.repository.unique.id=1.2.208.176.43210.8.10.12
dds.home.community.id=1.2.208.176.8.1.12

# FGVHR - De andre services genbruger ID-kort og HSUID-header som FSK modtager, til at kalde videre. Det gør FGVHR ikke, derfor skal certifikat og ID-kort konfigureres:
fgvhr.enable=true
fgvhr.endpoint=http://test1-cnsp.ekstern-test.nspop.dk:8080/fgvhr/20230601/hasNoResuscitation
fgvhr.connect.timeout.millis=2000
fgvhr.read.timeout.millis=7000
fgvhr.sts.keystore=NSP_Test_Service_Consumer_sds.p12 # skal mappes ind i containeren på følgende sti, så navnet på keystore stemmer overens: /pack/wildfly/modules/dk/sundhedsdatastyrelsen/fsk/main/NSP_Test_Service_Consumer_sds.p12
fgvhr.sts.keystore.password=Test1234
fgvhr.idcard.subject.name=Sundhedsdatastyrelsen
fgvhr.idcard.subject.id=33257872
fgvhr.idcard.system.name=FSK


Daglig drift

Servicen kræver ingen daglig vedligeholdelse udover sædvanlig systemovervågning.

Versionsinformation

Servicen udstiller en statusside med versionsinformation. Der returneres en body med JSON-data.
"$.build" indeholder oplysninger om versionen, og hvornår den blev bygget.
"$.time" indeholder oplysninger om det aktuelle tidspunkt, og tidspunktet for hvornår servicen blev deployed.

Eksempel:

Code Block
languagetext
{
    "build": {
        "version": "2.0.8",
        "artifact": "fsk-service",

Eksempel på response, når applikationen er sund

HTTP statuskode: 200 OK

Code Block
languagetext
{
    "status": "UP",
    "details": {      
        "organDonorClient": {
            "status": "UP",
            "details": {
                "timeOfLastExecution": "2019-07-30T17:31:13.245Z"
            }
        },
        "livingWillClient": {
            "status": "UP",
            "details": {
                "timeOfLastExecutionname": "2019-07-30T17:31:13.246Z"fsk-service",
        "group": "dk.sundhedsdatastyrelsen.stamkort",
   }
     "time": "2019-07-30T07:30:22.496Z"
    },
        "treatmentWillClienttime": {
            "statuscurrentTime": "UP"2019-07-30T13:16:18.761Z",
            "detailsdeployed": {
                "timeOfLastExecution": "2019-07-30T1730T13:3116:1310.245Z382Z"
            }
}


Overvågning

De følgende afsnit beskriver emner i servicen, der kræver opmærksomhed ift. driften.

Health-statusside

Servicen udstiller en Health-statusside (også typisk kendt som isAlive), der viser om applikationen er sund, eller om noget kræver indgriben. Health-statussiden returnerer en body med JSON-data, der beskriver sundhedsstatus for forskellig funktionalitet i applikationen.

Health-statussiden er opbygget vha. Spring Boot Actuator, som er konfigureret med nogle specialfremstillede HealthIndicators.

Actuator beregner en overordnet status for applikationens tilstand, som baseres på den HealthIndicator, der returnerer den mest fatale status. Denne overordnede status vises i JSON-property'en "$.status". Se eksempler længere nede.

Der er udover standard Actuator statusser defineret en specielfremstillet status (NEEDS_ATTENTION). Den følgende tabel viser alle statusser i rækkefølge fra sund til fatal. Tabellen viser også den HTTP statuskode, som Health-statussiden vil returnere til en given overordnet status:

HTTP statuskodeBeskrivelse
200 OKIngen fejl.
203 Non authoratative informationEn fejl kræver måske indgriben, men applikationen fungerer fortsat med nedsat funktion.
500 Internal Server ErrorApplikationen/funktionen er nede og kræver øjeblikkelig indgriben.

Opførsel for forskellige HealthIndicators

Nogle HealthIndicators anvender ikke nødvendigvis alle statusser men kun udvalgte. Følgende tabel viser, hvad de enkelte HealthIndicators tjekker, og hvornår de returnerer en specifik status.

Bemærk, at det kun er "db"-HealthIndicator'en der kan returnere statussen "DOWN" og dermed udløse HTTP statuskoden "500 Internal Server Error".

Navn (på property i JSON-response)Beskrivelse

$.details.organDonorClient
$.details.livingWillClient
$.details.treatmentWillClient
$.details.personalDataCardRegisterClient
$.details.scesClient
$.details.minLogClient

Tjekker om det seneste kald med den pågældende integration var succesfuldt. Hvis det ikke var succesfuldt, så viser "error" en toString() på den exception der opstod. Der vises eventuelt "timeOfLastExecution", som angiver det seneste tidspunkt, hvor et kald blev forsøgt (uanset om det var successfuldt eller ikke-successfuldt).

Statuskode 200: OK
Statuskode 203: Der opstod en fejl under seneste forsøg på at kalde med den pågældende integration.

$.details.db

Er baseret på Actuator's indbyggede DataSourceHealthIndicator og tjekker, at der kan udføres en "SELECT 1" query på alle applikationens datasources. Query'en udføres i det øjeblik Health-statussiden forespørges. Der vises detaljer om status for de enkelte datasources.

Statuskode 200: OK
Statuskode 500: Der opstod en fejl under forsøget på at udføre test-query'en på en af applikationens datasources.

Eksempel på response, når applikationen er sund

HTTP statuskode: 200 OK

Code Block
languagetext
{
    "status": "UP",
         },
        "personalDataCardRegisterClient": {
            "status": "UP",
            "details": {
                "timeOfLastExecution": "2019-07-30T17:31:13.246Z"
            }
        },
        "scesClient": {
            "status": "UP",
            "details": {
                "timeOfLastExecution": "2019-07-30T17:31:13.566Z"
            }
        },
        "minLogClient": {
            "status": "UP",
            "details": {
                "timeOfLastExecution": "2019-07-30T17:31:13.569Z"
            }
        },
        "syncJob": {
            "status": "UP",
            "details": {
                "timeOfLastExecution": "2019-07-30T18:00:05.321Z"
            }
        },
        "db": {
            "status": "UP",
            "details": {
      
          "primaryDataSourceorganDonorClient": {
                    "status": "UP",
            "details": {
       "details": {
        "timeOfLastExecution": "2019-07-30T17:31:13.245Z"
            }
    "database": "MySQL",
   },
        "livingWillClient": {
            "hellostatus": 1"UP",
            "details": {
       }
           "timeOfLastExecution": "2019-07-30T17:31:13.246Z"
            },
        },
        "stamdataDataSourcetreatmentWillClient": {
                    "status": "UP",
                    "details": {
                        "database"timeOfLastExecution": "MySQL",2019-07-30T17:31:13.245Z"
            }
        },
        "hellopersonalDataCardRegisterClient": 1{
            "status": "UP",
            }"details": {
                }"timeOfLastExecution": "2019-07-30T17:31:13.246Z"
            }
        },
        "scesClient": }
}

Eksempel på response, når noget i applikationen kræver indgriben

HTTP statuskode: 202 Accepted

Code Block
languagetext
{
{
            "status": "NEEDS_ATTENTIONUP",
    "details": {
        "organDonorClientdetails": {
                "statustimeOfLastExecution": "UP",2019-07-30T17:31:13.566Z"
            "}
        },
        "minLogClient": {
            "status": "UP",
            "details": {
                "timeOfLastExecution": "2019-07-30T17:31:13.245Z569Z"
            }
        },
        "livingWillClientsyncJob": {
            "status": "NEEDS_ATTENTIONUP",
            "details": {
                "error": "java.io.IOException: HTTP POST failed (404): Not Found",
                "timeOfLastExecution": "2019-07-30T1730T18:3100:1305.246Z321Z"
            }
        },
        "treatmentWillClientdb": {
            "status": "UP",
            "details": {
                "timeOfLastExecutionprimaryDataSource": "2019-07-30T17:31:13.245Z"
 {
              }
        }"status": "UP",
        "personalDataCardRegisterClient": {
            "statusdetails": "UP",{
            "details": {
                "timeOfLastExecutiondatabase": "2019-07-30T17:31:13.246Z"MySQL",
            }
        },
    "hello": 1
     "scesClient": {
              "status": "UP",
 }
             "details": {   },
                "timeOfLastExecutionstamdataDataSource": "2019-07-30T17:31:13.566Z"{
            }
         }"status": "UP",
        "minLogClient": {
            "statusdetails": "UP",{
            "details": {
                "timeOfLastExecutiondatabase": "2019-07-30T17:31:13.569Z"MySQL",
            }
        },
        "syncJobhello": {1
             "status": "UP",
      }
      "details": {
         }
       "timeOfLastExecution": "2019-07-30T18:00:05.321Z"
    }
        }
    }
}


Eksempel på response, når noget i applikationen kræver indgriben

HTTP statuskode: 202 Accepted

Code Block
languagetext
{    },
    "status": "NEEDS_ATTENTION",
    "dbdetails": {
            "organDonorClient": {
            "status": "UP",
            "details": {
                "primaryDataSourcetimeOfLastExecution": {"2019-07-30T17:31:13.245Z"
            }
        "status": "UP"},
        "livingWillClient": {
            "detailsstatus": {"NEEDS_ATTENTION",
            "details": {
           "database": "MySQL",
             "error": "java.io.IOException: HTTP POST failed (404): Not Found",
                "hellotimeOfLastExecution": 1"2019-07-30T17:31:13.246Z"
            }
        },
        "treatmentWillClient": {
        },
    "status": "UP",
            "stamdataDataSourcedetails": {
                    "statustimeOfLastExecution": "UP",2019-07-30T17:31:13.245Z"
            }
        "details": {},
        "personalDataCardRegisterClient": {
               "databasestatus": "MySQLUP",
                        "hello"details": 1{
                    "timeOfLastExecution": "2019-07-30T17:31:13.246Z"
            }
        },
        }
"scesClient": {
            "status": "UP",
            "details": }{
            }
    }
}

Fejlfinding

Servicens logfiler bør løbende tjekkes for ERROR-logninger.

Logfiler og fortolkning af disse

Alle logfiler er at finde i ”log” under Wildfly. Herunder findes en liste over logfiler, med en beskrivelse af hvilke komponenter der skriver til dem.

Alle logs benytter en rolling file appender, og indeholder derfor et postfix i filnavnet, der ikke er præsenteret i nedenstående.

    "timeOfLastExecution": "2019-07-30T17:31:13.566Z"
            }
        },
        "minLogClient": {
            "status": "UP",
            "details": {
                "timeOfLastExecution": "2019-07-30T17:31:13.569Z"
            }
        },
        "syncJob": {
            "status": "UP",
            "details": {
                "timeOfLastExecution": "2019-07-30T18:00:05.321Z"
            }
        },
        "db": {
            "status": "UP",
            "details": {
                "primaryDataSource": {
                    "status": "UP",
                    "details": {
                        "database": "MySQL",
                        "hello": 1
                    }
                },
                "stamdataDataSource": {
                    "status": "UP",
                    "details": {
                        "database": "MySQL",
                        "hello": 1
                    }
                }
            }
        }
    }
}


Fejlfinding

Servicens logfiler bør løbende tjekkes for ERROR-logninger.

Logfiler og fortolkning af disse

Alle logfiler er at finde i ”log” under Wildfly. Herunder findes en liste over logfiler, med en beskrivelse af hvilke komponenter der skriver til dem.

Alle logs benytter en rolling file appender, og indeholder derfor et postfix i filnavnet, der ikke er præsenteret i nedenstående.

Logfilnavn

Indhold

fsk_service.log

Applikationslog fra FSKservicen, som indeholder de vigtigste systemhændelser (INFO), fejl (ERROR) og advarsler (WARN).

fsk_audit.log

Auditlog fra FSK-servicen, som indeholder logning af, hvem der har kaldt, hvilken service der blev kaldt, hvordan der blev kaldt, hvornår der blev kaldt samt kaldets varighed. Bemærk, Da FSK-servicen kun udstiller én webservice, som er on-demand servicen til kald fra DDS, vil mange oplysninger være éns fra kald til kald.

Auditlog

Følgende tabel viser hvad der audit logges ved successfulde kald til fsk.

KomponentKontekstTypeNøgleInformation
FSKretrieveDocumentSetIkke Personligdocument-idID på hentet dokument
FSKretrieveDocumentSetFølsommecprCPR på borgeren
FSKretrieveDocumentSetFølsommeactor-cprCPR på aktør
FSKretrieveDocumentSetPersonligactor-usertypeTypen af aktør

Logfilnavn

Indhold

fsk_service.log

Applikationslog fra FSKservicen, som indeholder de vigtigste systemhændelser (INFO), fejl (ERROR) og advarsler (WARN).

fsk_audit.log

Auditlog fra FSK-servicen, som indeholder logning af, hvem der har kaldt, hvilken service der blev kaldt, hvordan der blev kaldt, hvornår der blev kaldt samt kaldets varighed. Bemærk, Da FSK-servicen kun udstiller én webservice, som er on-demand servicen til kald fra DDS, vil mange oplysninger være éns fra kald til kald.

Krav til backup m.m.

Servicen indeholder ikke nogen backup-mekanismer, og dette skal derfor konfigureres på database-niveau. Der bør foretages backup af data på en forsvarlig måde, i tilfælde af behov for en genetablering af data. Disse data skal opbevares på en forsvarlig måde, jfr. regler om personhenførbare data.