SOSI-DCC driftsvejledning
Indledning
Nærværende dokument udgør driftsvejledningen for SOSI-DCC komponenten, som også er kendt som Afkoblingskomponenten. SOSI-DCC fungerer som webservice gateway og dens hovedfunktioner er routning af requests og håndhævelse af timeout-grænser på webservice kald.
Komponenten er udviklet som en Java 8 webapplikation og understøttes på JBoss Application Server version 8 (Wildfly)
Denne driftsvejledning er gældende for SOSI-DCC version 2.4.X.
Eksterne afhængigheder
På NSP er der pt. ingen eksterne afhængigheder.
Placering af logfiler
Komponenten logger til sin egen rullende log som hedder 'decoupling.log'.
Komponents SLA logninger havner i 'nsputil-sla.log'.
På JBoss 8 platformen ligger logfilerne i:
$JBOSS_HOME/standalone/log/
hvor '$JBOSS_HOME' udpeger roden på JBoss Application Server.
Indgange i loggen indeholder en kort beskrivelse af hændelsen, tidspunktet samt hændelsens alvorlighedsgrad ('Severity').
Ved drift bør der ikke være indgange af alvorlighedsgrad 'ERROR' i loggen. Se overvågningsvejledning nedenfor.
Placering af konfigurationsfiler
Komponentens konfiguration udgøres af filerne 'dcc-config.xml' og 'log4j-dcc.properties'.
Afvikles komponenten på en NSP er det der ydermere to konfigurationsfiler til SLA-loggen: 'nspslalog-sosidcc.properties' og 'log4j-nspslalog.properties'.
På JBoss platformen er konfigurationen placeret i:
$JBOSS_HOME/standalone/configuration/
hvor '$JBOSS_HOME' udpeger roden på JBoss Application Server.
Optionelt er det muligt at placere komponentens routings-konfiguration i en (MySQL) database, hvor komponenten med konfigurerbart jævne mellemrum kan indlæse nyeste konfiguration fra database. Det er ydermere muligt at konfigurere DCC, således at genindlæsning af routningskonfiguration kan tvinges til at køre. Dette gøres ved udfylde RoutingConfigurationRefreshParameters-elementet i dcc-config.xml. Det følgende er et eksempel på denne konfiguration:
<RoutingConfigurationRefreshParameters> <Location>/config</Location> <Filename>refresh</Filename> </RoutingConfigurationRefreshParameters>
Konfigurationen betyder, at DCC kigger efter en fil ved navn refresh på stien /config. Hvis filen findes, genindlæses konfigurationen og filen slettes. Genindlæsning kan nu igangsættes med
touch /config/refresh
Ændringer i den fil-baserede statiske konfiguration af komponenten træder først i kraft efter genstart af komponenten. Se vejledning nedenfor.
Start/stop vejledning
Komponenten stoppes og startes gennem en docker container.
Efter genstart bør der verificeres at der ikke er nogen indgange med alvorlighedsgrad 'ERROR' i komponentens log.
Under stop eller undeploy af komponenten ses følgende typer warnings i loggen, som kan ignoreres:
_WARN \[org.jboss.msc.inject\] (MSC service thread 1-5) MSC000100: Unexpected failure to uninject public void net.sf.jbosscommonj.timermanager.TimerManagerService.setMinThreads(int): java.lang.IllegalArgumentException_
Overvågning
Udover at overvåge selve applikationsserveren for ressourceknaphed og generelle fejl kan man overvåge SOSI-DCC ved at:
- Sikre, at endpointet svarer, ved at foretage simple HTTP GET kald mod komponents 'check' status sider:
http://<HOST>:<PORT>/decoupling/dcccheck
Viser en simple status side med IP-adressen og dato, øverste linje på siden viser 'OK'
http://<HOST>:<PORT>/decoupling/dcccheckall
Som 'dcccheck' men viser også konfigurationsparametre for komponenten.
2. Overvåge komponentens logfil for 'ERROR' indgange
Backup
Der bør foretages backup af komponentens egne konfigurationsfiler hver gang konfigurationen ændres.
For at gøre eventuelt fejlfinding nemmere anbefales det, at der ligeledes tages backup af komponentens logfiler.
Baggrundsjob til genindlæsning af DCC konfiguration
ReloadConfiguration baggrundsjobbet for DCC gør det muligt at genindlæse den konfiguration som DCC er konfigureret til at bruge.
Baggrundsjobbet overholder husregler for baggrundsjobs (version v64 af husreglerne i seneste udgave af baggrundsjobbet). Den bryder dog reglen om at køre i egen container, da den skriver til konfiguration der ligger in-memory, som læses af DCC.
Konfiguration af hvilken mappe DCC finder konfigurationsfilen i, indstilles ved at sætte en system property. Flere properties prøves af DCC, indtil den finder en som er sat.
Det gøres i følgende rækkefølge:
dk.sosi.dcc.config.dir - det er typisk denne man selv vil sætte
jboss.server.config.dir
was.repository.root - hvis denne er sat søges der i stien defineret i property 'user.home' - dvs. at 'was.repository.root' blot bruges til at afgøre om programmet afvikles på en WAS
catalina.home
Herefter vil DCC kigge i mappen efter en fil med navnet angivet i property 'dk.rsd.dcc.configfile'. Hvis den ikke er sat bruges filnavnet 'dcc-config.xml'.
ReloadConfiguration-jobbet vil genlæse konfigurationsfilen in-memory når den kaldes, som medfører at DCC får den nye konfiguration, næste gang den tilgår in-memory konfigurationen.
Jobbet har følgende HTTP GET operationer, som kan tilgås med angivne URL path:
Start
decoupling/reloadConfiguration/start
Status
decoupling/reloadConfiguration/status
Succes og fejl skrives til loggen - "Configuration reloaded" skrives hvis udførslen går godt, ellers "Configuration reload failed" efterfulgt af fejlen, hvis udførslen fejler.
Hvis der er fejl i den nye konfiguration logges dette og den tidligere korrekt indlæste bibeholdes.
Kendte fejl
Der pt. ingen kendte fejl.