Page History
...
| Anchor | ||||
|---|---|---|---|---|
|
SOSI-DCC driftsvejledning
Indledning
Eksterne afhængigheder
Placering af logfiler
Placering af konfigurationsfiler
Start/stop vejledning
Overvågning
Backup
Kendte fejl
| Table of Contents |
|---|
| Anchor | ||||
|---|---|---|---|---|
|
...
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.
...
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 - Se Installationvejledningen. Så kan DCC indlæse nyeste konfiguration fra database. Indlæsningen sker ved genstart og periodisk, som angivet i DCCConfigReloadInterval - Se afsnittet Baggrundsjob til genindlæsning af DCC konfiguration.
Ændringer i den fil-baserede statiske konfiguration af komponenten træder først i kraft efter genstart af komponenten. Se vejledning nedenfor.
| Anchor | ||||
|---|---|---|---|---|
|
...
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_| Anchor | ||||
|---|---|---|---|---|
|
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:
på 2 måder:
- Status: på URL /decoupling/status (eller http://<HOST>:<PORT> /decoupling/dcccheck
Viser en simple status side med IP-adressen og dato, øverste linje på siden viser 'OK'
Som 'dcccheck' men viser også konfigurationsparametre for komponenten.
...
- for bagudkompatibilitet)
- Alarm: på URL /decoupling/alarm (eller /decoupling/dcccheckallfor bagudkompatibilitet)
9.1. Status
Status-siden viser en beskrivelse af tilstanden af flere parametre i DCC.
Siden vil returnere 500 i følgende tilfælde (ellers 200):
- DCC er ikke korrekt initialiseret
9.2. Alarm
Alarm-siden viser alarmer, hvis der er nogen. Ovenstående scenarier fra status-siden, samt følgende scenarier, vil forårsage en alarm:
- DCC er ikke korrekt initialiseret
Der returneres 500 ved alarm, ellers 200.
| Anchor | ||||
|---|---|---|---|---|
|
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
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'.
Hvis der er fejl i den nye konfiguration logges dette og den tidligere korrekt indlæste bibeholdes.
DCCConfigReloadService
DCCConfigReloadService baggrundsjobbet for DCC genindlæser konfigurationen periodisk.
I f.eks. dcc-config.xml skrives følgende for at angive perioden mellem genindlæsninger:
| Code Block | ||
|---|---|---|
| ||
<!-- Her er perioden mellem genindlæsningerne angivet til 270 sekunder (4 minutter og 30 sekunder) -->
<DCCConfigReloadInterval>270</DCCConfigReloadInterval> |
Baggrundsjobbet overholder ikke husregler for baggrundsjob, da den skeduleres i koden. Hvis perioden ikke er angivet i konfigurationen for DCCConfigReloadInterval så bruges værdien 300, hvilket gør, at der genindlæses hvert 5. minut.
DCCConfigReloadInterval skal angives som et positivt heltal, som angiver perioden indtil næste genindlæsning i sekunder. Denne værdi kan sættes meget højt, hvis man ikke ønsker at genindlæse konfigurationen automatisk, hvorefter det kun kan aktiveres igen ved genstart af DCC.
| Anchor | ||||
|---|---|---|---|---|
|
...