GSB 7.0 Standardlösung

Springe direkt zu:

Zielgruppe BetriebVersion: GSB10.0Betriebliche Aspekte

Zum Starten und Stoppen der Service-Instanzen per Systemd sind einige Voraussetzungen nötig.

Starten/Stoppen der Komponenten

Einrichten der Unit-Files

Um das Starten und Stoppen der Komponenten zu vereinfachen, sin im Release exemplarische Systemd Unit-Files enthalten, welche für die Einrichtung entsprechender Start- und Stopp-Services verwendet werden können. Zusätzlich ermöglicht die Verwendung zugehöriger Targets das Starten und Stoppen kompletter Umgebungen oder Teilen davon, über einen einzigen Aufruf.

Die Nutzung von Systemd erfordert entweder Systemadministratorenrechte (root) oder eine entsprechende Sudoers-Konfiguration.

Diese Vorlagen sind im GSB Kern im infrastructure-Artefakt unterhalb des Verzeichisses infrastructure/systemd zu finden.

Die dort bereitgestellte Datei servicetyp@.service und servicetyp.target kann für alle Tomcat-Server basierten GSB Dienste genutzt werden. D.h. die betreffenden Dateien können als delivery@.service und delivery.target nach /etc/systemd/system kopiert werden, um den delivery Service-Typen unter die Kontrolle von Systemd zu stellen. Anschließend können die Delivery-Tomcat-Instanzen mit Hilfe von Systemd gestartet und gestoppt werden..

Voraussetzung dafür ist natürlich, dass die Standardverzeichnisse während der Installation verwendet wurden. Andernfalls ist die Service-Datei vorher entsprechend anzupassen.

Auf einem Server müssen Service-Units und Service-Targets für alle Service-Typen angelegt werden, die auf diesem Server betrieben werden.

Die Solr basierte Suche im GSB wird mit Hilfe der Standalone Solr-Applikation betreiben, d.h. die Solr-Applikation wird nicht in einem Tomcat-Server betrieben sondern wird als Self-Contained Applikation mit einem Embedded Jetty-Server ausgeführt. Im Release stehen mit den Dateien solr@.service und solr.target spezielle Vorlagen für die Systemd-Einbindung der GSB Solr-Server zur Verfügung. Diese sind ebenfalls im Ordner /etc/systemd/system abzulegen, um Solr unter die Kontrolle von Systemd stellen zu können.

Starten und Stoppen per systemctl

Nach der Einrichtung der Service-Units können die einzelnen Instanzen mittels des Befehls systemctl gestartet oder gestoppt werden:

Starten und Stoppen von GSB Diensten

  sudo systemctl start delivery@delivery1-preview.service

  sudo systemctl stop delivery@delivery1-preview.service

 

  sudo systemctl start delivery@delivery2-preview.service

  sudo systemctl stop delivery@delivery2-preview.service

Der erste Teil der Service-Bezeichnung vor dem ‚@‘ gibt den Namen des Service-Typen an welcher gestartet oder gestoppt werden soll. Dieser wird verwendet um das Installationsverzeichnis des Service-Typs zu ermitteln. Bei Verwendung der Standardpfade wäre im oben genannten Fall das Verzeichnis

  • /opt/gsbos/delivery

Der zweite Teil delivery1-preview oder delivery2-preview gibt den Namen der Instanz an welche gestartet oder gestoppt werden soll. Dieser wird sowohl für die Identifikation der zugehörigen Runtime-Konfiguration

  • /opt/gsbos/delivery1-preview
  • /opt/gsbos/delivery2-preview

als auch für die Festlegung des data-Verzeichnisses der Service-Instanz verwendet (Speicherung von Bewegungsdaten). Bei Verwendung der Standardpfade ergibt sich für die obigen Beispiele:

  • /space/gsbos/data/delivery1-preview
  • /space/gsbos/data/delivery2-preview

Über das Target des Service-Typs können alle gestarteten Service-Instanzen gleichzeitig gestoppt werden. Für den Service-Typ „delivery“ ist dies das folgendes Kommando:

Stoppen aller Delivery-Tomcats

sudo systemctl stop delivery.target

Loadbalancer Integration

Die folgenden Unterkapitel beschreiben wie eine Loadbalancer Anbindung bzw. Integration einer GSB Infrastruktur erfolgen muss.

Https-Terminierung

Typischerweise wird es in einer Betriebsinfrastruktur einer Hostingplattform einen vorgeschalteten Loadbalancer geben, der das Routing der einkommenden http-Requests vornimmt.

Dabei wird in der Regel der Zugriff per HTTPS auch direkt dort terminiert.

Damit das dahinterliegende Backend Kenntnis davon hat über welches Protokoll der ursprüngliche Request eingetroffen ist, muss diese Information entsprechend weitergegeben werden. Die geschieht über folgende http-Header Information:

HTTP:X-Forwarded-Proto mit dem Wert https

Dieser Header wird dann von den ausliefernden Apache Web bzw. Tomcat-Servern genutzt, um den Delivery-Instanzen zu signalisieren, dass es sich ursprünglich um einen HTTPS Request gehandelt hat. Detailinformationen zum X-Forwarded-Proto-Header finden sich auf https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Forwarded-Proto.

Handhabung von Sticky Sessions

Für bestimmte Anwendungsfälle, wie beispielweise geschützte Zugriffsbereiche, ist es notwendig, dass ein Benutzer, der sich an der Webseite angemeldet hat, immer mit derselben Delivery-Instanz kommuniziert. Das heißt alle nach einer Anmeldung angefragten Requests müssen immer an dieselbe Delivery-Instanz weitergeleitet werden. Dazu müssen alle Komponenten der relevanten und beteiligten Infrastruktur Sticky-Sessions unterstützen. Die Information von welcher Delivery-Instanz die Requests des aktuellen Benutzers bedient werden findet sich im jvmroute-Parameter der von den ausliefernden Delivery-Tomcat Instanzen gesetzt wird und von davorliegenden Komponenten (bspw. Loadbalancer) entsprechend genutzt wird. Gesetzt und gespeichert wird dieser in der JSESSIONID (Cookie/ Parameter) des jeweiligen Clients.

Beispiel:

Cookie JSESSIONID Wert 374749A8D2DFE3C98800BC69A3C21387.delivery1-live

Healtchecks der Delivery-Instanzen

Die Signalisierung der Delivery-Instanzen, ob diese für die Auslieferung aktuell genutzt werden können, erfolgt mit Hilfe der bereitgestellten Healthcheck-Requests. Diese liefern den http Response Code „200“, also OK, wenn die angefragte Instanz zur Verfügung steht und alle für die Auslieferung relevante Komponenten erfolgreich eingebunden sind (zum Beispiel die genutzte Repository-Instanz).

Exemplarischer Healthcheck Aufruf

http://preview.standardlsg.example.com/healthcheck

Kann der Healthcheck nicht erfolgreich durchgeführt werden, wird der Repsonse Code „500“ zurückgeliefert, der eine Einbindung der Instanz in die Auslieferung verhindern soll.

Monitoring / Debugging

Die GSB Service-Instanzen legen Bewegungsdaten in einem instanzspezifischen Verzeichnis ab. Hierzu zählen auch Logdateien, die bspw. für die Instanz delivery1-preview unterhalb des Verzeichnisses /space/gsbos/data/delivery1-preview/logs abgelegt werden.

Das logs-Verzeichnis enthält mit der Datei catalina.out die Log-Datei des Tomcat-Servers. Jede Webapplikation, die in der Service-Instanz deployed und geladen ist verfügt darüber hinaus über eine Webapplikationsspezifische Logdatei. Die Logdatei einer Webapplikation liegt ebenfalls im logs-Verzeichnis und heißt webapp-<WEBAPP_NAME>.log.

Die GSB Komponenten loggen mit Hilfe des Loggingframeworks logback. Die Logback-Konfiguration einer Webapplikation liegt innerhalb der Applikation in der Datei WEB-INF/classes/logback.xml. Die Logback Konfiguration der Site-Applikation des Delivery Service-Typs findet sich bspw. unterhalb von /opt/gsbos/software/delivery/webapps/site/WEB-INF/classes/logback.xml.

Durch Anpassung der LogLevel einzelner Klassen oder gesamter Java-Packages in der Logback-Konfiguration kann eine Problemanalyse auf Basis von Logausgaben bei Bedarf durchgeführt werden. Die Logback-Konfiguration wird zyklisch auf Änderungen geprüft und durch die Webapplikationen geladen, so dass Änderungen an der Logging-Konfiguration im laufenden Tomcat-Server vorgenommen werden können.

GSB Webapplikationen

Die GSB Webapplikationen unterstützten eine interne Statusermittlung der Applikation. Der Status wird über ein Java Management Bean (JMX) bereitgestellt und kann so für ein Monitoring der Applikationen genutzt werden.

Das Monitoring unterstützt die folgenden Status:

  • Online: Die Applikation ist arbeitsfähig (Online = 0)
  • Warning: Die Applikation ist arbeitsfähig aber es gibt Einschränkungen. Dies ist bspw. dann der Fall, wenn zwei von drei konfigurierten Solr-Servern ausgefallen oder für die Applikation nicht erreichbar sind. Die Suche ist in diesem Fall weiterhin gewährleistet, aber sie steht nicht mehr ausfallsicher zur Verfügung (Warning = 1)
  • Offline: Die Applikation ist nicht arbeitsfähig (Offline = 2)
  • Unknown: Eine Ermittlung des Status der Applikation kann aktuell nicht durchgeführt werden.

Neben dem eigentlichen Status wird noch eine Status-Beschreibung zur Verfügung gestellt. Die Beschreibung enthält eine kurze Zusammenfassung des Status und gibt bei Problemen einen Hinweis auf die Ursache (s.o. Ausfall von einigen Solr-Servern).

Unterstützte Checks

Der Status einer GSB Applikation ergibt sich als Aggregation einzelner Checks. D.h. der Healthcheck prüft die von einer Applikation benötigten Resourcen über entsprechende Resourcen-Checks und aggregiert die ermittelten Einzelstatus der einzelnen Checks zu einem Gesamtstatus für die Applikation.

Der GSB unterstützt die folgenden Resourcen-Checks:

  • Database: Überprüft, ob die der Applikation zugrundeliegende Datenbank zur Verfügung steht. Der Check
  • LDAP: Überprüft die Verfügbarkeit des in der Applikation genutzten LDAP-Serers
  • Maildistributor: Prüft die Erreichbarkeit des Maildistributors
  • Repository: Prüft die Verfügbarkeit des genutzten CMS-Repositories
  • Solr: Prüft die Verfügbarkeit der in der Applikation definierten Solr-Server

Healthcheck der Applikationen

Die GSB Applikationen nutzen die im vorherigen Kapitel vorgestellten "unterstützten Checks" für den Healtcheck der jeweiligen Applikation. Die Applikation hat den Status Online, wenn alle Checks ebenfalls den Status Online ergeben. Meldet eine Applikation einen anderen Status, dann ist der Gesamtstatus ebenfalls entweder Warning,`Offline oder ggf. Unknown.

Site

Die Site-Applikation implementiert die folgenden Checks:

  • Database: Prüft die Verfügbarkeit der Applikations-Datenbank (OnlineDB)
  • Ermittelt die Verfügbarkeit des in der Site definierten Content-Repository
  • Solr: Prüft die Erreichbarkeit der in der Site definierten Solr-Server
Konfiguration

Die Definition der Site-Healtchecks erfolgt in der Site-Applikation in der Spring-Konfiguration cms-healthcheck.xml.

Konfigurationsdatei Site-Healthchecks

<!--
  ~ Copyright (c) 2018 Materna GmbH, Germany
  -->
 
<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xsi:schemaLocation="http://www.springframework.org/schema/beans
                           http://www.springframework.org/schema/beans/spring-beans.xsd">
 
  <bean class="org.springframework.jmx.export.MBeanExporter" lazy-init="false">
    <property name="beans">
      <map>
        <entry key="de.bund.gsb.site.healthcheck:name=Healthcheck_Site" value-ref="healthCheck"/>
        <entry key="de.bund.gsb.site.healthcheck:name=Healthcheck_Repository" value-ref="siteRepositoryHealthCheck"/>
        <entry key="de.bund.gsb.site.healthcheck:name=Healthcheck_Solr" value-ref="siteSolrHealthCheck"/>
        <entry key="de.bund.gsb.site.healthcheck:name=Healthcheck_Database" value-ref="siteDatabaseHealthCheck"/>
      </map>
    </property>
  </bean>
 
  <bean id="healthCheck" class="de.bund.gsb.util.healthcheck.impl.HealthCheckExecutorImpl"
        factory-method="getInstance"
        scope="singleton">
    <property name="activated" value="${site.healthchecks.activated}"/>
  </bean>
 
  <bean id="siteRepositoryHealthCheck" class="de.bund.gsb.site.healthcheck.SiteRepositoryHealthCheck">
    <property name="componentName" value="repository"/>
    <property name="checkFolder" value="${site.healthcheck.repository.checkFolder}"/>
    <property name="activated" value="${site.healthchecks.repository.activated}"/>
  </bean>
 
  <bean id="siteSolrHealthCheck" class="de.bund.gsb.site.healthcheck.SiteSolrHealthCheck">
    <property name="componentName" value="solr"/>
    <property name="activated" value="${site.healthchecks.solr.activated}"/>
  </bean>
 
  <bean id="siteDatabaseHealthCheck" class="de.bund.gsb.site.healthcheck.SiteDatabaseHealthCheck">
    <property name="componentName" value="database"/>
    <property name="activated" value="${site.healthchecks.onlinedb.activated}"/>
  </bean>
 
 
  <import resource="classpath:spring/customers/*-healthcheck.xml"/>
 
</beans>

Die Konfiguration der Healthchecks erfolgt über die folgenden Properties in der Runtime-Konfiguration der Site (Datei site.properties):

·         site.healthchecks.activated Boolescher Wert der definiert, ob ein Healthcheck der Site-Applikation bereitgestellt wird (Default false)

·         site.healthchecks.onlinedb.activated definiert, ob eine Prüfung der Online-Datenbank durchgeführt werden soll (Boolescher Wert, Defalut true)

·         site.healthchecks.repository.activated definiert, ob eine Prüfung des Repositories durchgeführt werden soll (Boolescher Wert, Defalut true)

·         site.healthchecks.solr.activated definiert, ob eine Prüfung der Solr-Server durchgeführt werden soll (Boolescher Wert, Defalut true)

Repository

Die Repository-Applikation implementiert die folgenden Checks:

  • Database: Prüft die Verfügbarkeit der Repository-Datenbank
  • LDAP: Prüft die Verfügbarkeit des im Repository konfigurierten LDAP-Servers
Konfiguration

Die Definition der Repository-Healtchecks erfolgt in der Repository-Applikation in der Spring-Konfiguration cms-healthcheck.xml.

Konfigurationsdatei Repository-Healthchecks

<!--
  ~ Copyright (c) 2018 Materna GmbH, Germany
  -->
 
<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xsi:schemaLocation="http://www.springframework.org/schema/beans
                           http://www.springframework.org/schema/beans/spring-beans.xsd">
 
  <bean class="org.springframework.jmx.export.MBeanExporter" lazy-init="false">
    <property name="beans">
      <map>
        <entry key="de.bund.gsb.repository.healthcheck:name=Healthcheck_Repository" value-ref="healthCheck"/>
        <entry key="de.bund.gsb.repository.healthcheck:name=Healthcheck_Database" value-ref="repoDatabaseHealthCheck"/>
        <entry key="de.bund.gsb.repository.healthcheck:name=Healthcheck_Ldap" value-ref="repoLdapHealthCheck"/>
      </map>
    </property>
  </bean>
 
  <bean id="healthCheck" class="de.bund.gsb.util.healthcheck.impl.HealthCheckExecutorImpl"
        factory-method="getInstance"
        scope="singleton">
    <property name="activated" value="${repository.healthchecks.activated}"/>
  </bean>
 
  <bean id="repoDatabaseHealthCheck" class="de.bund.gsb.repository.healthcheck.RepoDatabaseHealthCheck">
    <property name="componentName" value="database"/>
    <property name="activated" value="${repository.healthchecks.database.activated}"/>
  </bean>
 
  <bean id="repoLdapHealthCheck" class="de.bund.gsb.repository.healthcheck.RepoLdapHealthCheck">
    <property name="componentName" value="ldap"/>
    <property name="activated" value="${repository.healthchecks.ldap.activated}"/>
  </bean>
 
</beans>

Die Konfiguration der Healthchecks erfolgt über die folgenden Properties in der Runtime-Konfiguration des Repository (Datei repository.properties):

·         repository.healthchecks.activated Boolescher Wert der definiert, ob ein Healthcheck der Repository-Applikation bereitgestellt wird (Default false)

·         repository.healthchecks.database.activated definiert, ob eine Prüfung der Repository-Datenbank durchgeführt werden soll (Boolescher Wert, Defalut true)

·         repository.healthchecks.ldap.activated definiert, ob eine Prüfung des LDAP-Servers durchgeführt werden soll (Boolescher Wert, Defalut true)

Indexer

Die Indexer-Applikation implementiert die folgenden Checks:

  • Ermittelt die Verfügbarkeit des im Indexer definierten Content-Repository
  • Solr: Prüft die Erreichbarkeit des im Indexer definierten Solr-Servers
Konfiguration

Die Definition der Indexer-Healtchecks erfolgt in der Indexer-Applikation in der Spring-Konfiguration cms-healthcheck.xml.

Konfigurationsdatei Indexer-Healthchecks

<!--
  ~ Copyright (c) 2018 Materna GmbH, Germany
  -->
 
<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xsi:schemaLocation="http://www.springframework.org/schema/beans
                           http://www.springframework.org/schema/beans/spring-beans.xsd">
 
  <bean class="org.springframework.jmx.export.MBeanExporter" lazy-init="false">
    <property name="beans">
      <map>
        <entry key="de.bund.gsb.indexer.healthcheck:name=Healthcheck_Indexer" value-ref="healthCheck"/>
        <entry key="de.bund.gsb.indexer.healthcheck:name=Indexer_Healthcheck_Repository" value-ref="indexerRepositoryHealthCheck"/>
        <entry key="de.bund.gsb.indexer.healthcheck:name=Indexer_Healthcheck_Solr" value-ref="indexerSolrHealthCheck"/>
      </map>
    </property>
  </bean>
 
  <bean id="healthCheck" class="de.bund.gsb.util.healthcheck.impl.HealthCheckExecutorImpl"
        factory-method="getInstance" scope="singleton">
    <property name="activated" value="${indexer.healthchecks.activated}"/>
  </bean>
 
  <bean id="indexerRepositoryHealthCheck" class="de.bund.gsb.indexer.healthcheck.IndexerRepositoryHealthCheck">
    <property name="componentName" value="repository"/>
    <property name="activated" value="${indexer.healthchecks.repository.activated}"/>
  </bean>
 
  <bean id="indexerSolrHealthCheck" class="de.bund.gsb.indexer.healthcheck.IndexerSolrHealthCheck">
    <property name="componentName" value="solr"/>
    <property name="activated" value="${indexer.healthchecks.solr.activated}"/>
  </bean>
 
</beans>

Die Konfiguration der Healthchecks erfolgt über die folgenden Properties in der Runtime-Konfiguration des Indexers (Datei indexer.properties):

·         indexer.healthchecks.activated Boolescher Wert der definiert, ob ein Healthcheck der Indexer-Applikation bereitgestellt wird (Default false)

·         indexer.healthchecks.repository.activated definiert, ob eine Prüfung des Repositories durchgeführt werden soll (Boolescher Wert, Defalut true)

·         indexer.healthchecks.solr.activated definiert, ob eine Prüfung des Solr-Servers durchgeführt werden soll (Boolescher Wert, Defalut true)

Eventdispatcher

Die Eventdispatcher-Applikation implementiert die folgenden Checks:

  • Repository: Ermittelt die Verfügbarkeit des im Eventdispatcher definierten Content-Repository
  • Maildistributor: Ermittelt die Verfügbarkeit des im Eventdispatcher definierten Maildistributors
Konfiguration

Die Definition der Eventdispatcher-Healtchecks erfolgt in der Eventdispatcher-Applikation in der Spring-Konfiguration cms-healthcheck.xml.

Konfigurationsdatei Eventdispatcher-Healthchecks

<!--
  ~ Copyright (c) 2018 Materna GmbH, Germany
  -->
 
<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xsi:schemaLocation="http://www.springframework.org/schema/beans
                           http://www.springframework.org/schema/beans/spring-beans.xsd">
 
  <bean class="org.springframework.jmx.export.MBeanExporter" lazy-init="false">
    <property name="beans">
      <map>
        <entry key="de.bund.gsb.eventdispatcher.healthcheck:name=Healthcheck_Eventdispatcher" value-ref="healthCheck"/>
        <entry key="de.bund.gsb.eventdispatcher.healthcheck:name=Eventdispatcher_Healthcheck_Repository" value-ref="eventdispatcherRepositoryHealthCheck"/>
        <entry key="de.bund.gsb.eventdispatcher.healthcheck:name=Eventdispatcher_Healthcheck_Maildistributor" value-ref="maildistributorHealthCheck"/>
      </map>
    </property>
  </bean>
 
  <bean id="healthCheck" class="de.bund.gsb.util.healthcheck.impl.HealthCheckExecutorImpl"
        factory-method="getInstance" scope="singleton">
    <property name="activated" value="${eventdispatcher.healthchecks.activated}"/>
  </bean>
 
  <bean id="eventdispatcherRepositoryHealthCheck" class="de.bund.gsb.eventdispatcher.healthcheck.EventdispatcherRepositoryHealthCheck">
    <property name="componentName" value="repository"/>
    <property name="activated" value="${eventdispatcher.healthchecks.repository.activated}"/>
  </bean>
 
  <bean id="maildistributorHealthCheck" class="de.bund.gsb.eventdispatcher.healthcheck.MaildistributorHealthCheck">
    <property name="componentName" value="maildistributor"/>
    <property name="restUrl" value="${eventdispatcher.healthchecks.maildistributor.resturl}"/>
    <property name="activated" value="${eventdispatcher.healthchecks.maildistributor.activated}"/>
  </bean>
 
</beans>

Die Konfiguration der Healthchecks erfolgt über die folgenden Properties in der Runtime-Konfiguration des Eventdispatchers (Datei eventdispatcher.properties):

·         eventdispatcher.healthchecks.activated Boolescher Wert der definiert, ob ein Healthcheck der Eventdispatcher-Applikation bereitgestellt wird (Default false)

·         eventdispatcher.healthchecks.repository.activated definiert, ob eine Prüfung des Repositories durchgeführt werden soll (Boolescher Wert, Defalut true)

·         eventdispatcher.healthchecks.maildistributor.activated definiert, ob eine Prüfung des Maildistributors durchgeführt werden soll (Boolescher Wert, Defalut true)

·         eventdispatcher.healthchecks.maildistributor.resturl definiert den REST-Endpunkt für den Maildistributor Check (Default http://maildistributor.service.example.com:9801/MailDistributor_Input/rest/healthcheck)

Editor

Die Editor-Applikation implementiert die folgenden Checks:

  • Ermittelt die Verfügbarkeit des im Editor definierten Content-Repository
  • Solr: Prüft die Erreichbarkeit der im Editor definierten Solr-Server
Konfiguration

Die Definition der Editor-Healtchecks erfolgt in der GSBEditor-Applikation in der Spring-Konfiguration rest-service-healthcheck-context.xml.

Konfigurationsdatei Editor-Healthchecks

?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
        xmlns:p="http://www.springframework.org/schema/p" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xmlns:cache="http://www.springframework.org/schema/cache"
        xmlns:context="http://www.springframework.org/schema/context"
        xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd
     http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context.xsd
        http://www.springframework.org/schema/cache http://www.springframework.org/schema/cache/spring-cache.xsd">
 
        <bean class="org.springframework.jmx.export.MBeanExporter" lazy-init="false">
                <property name="beans">
                        <map>
                                <entry key="de.bund.gsb.util:name=Healthcheck_GsbEditor" value-ref="healthCheck" />
                                <entry key="de.bund.gsb.util:name=Healthcheck_Repository" value-ref="repositoryHealthCheck" />
                                <entry key="de.bund.gsb.util:name=Healthcheck_Solr" value-ref="solrHealthCheck" />
                        </map>
                </property>
        </bean>
 
        <bean id="healthCheck" class="de.bund.gsb.util.healthcheck.impl.HealthCheckExecutorImpl"
                factory-method="getInstance" scope="singleton">
                <property name="activated" value="${gsbeditor.healthchecks.activated}" />
        </bean>
 
        <bean id="repositoryHealthCheck" class="de.bund.gsb.webeditor.server.jcr.healthcheck.RepositoryHealthCheck">
                <property name="componentName" value="repository" />
                <property name="checkFolder" value="${gsbeditor.healthcheck.repository.checkFolder}" />
                <property name="activated" value="${gsbeditor.healthchecks.repository.activated}" />
        </bean>
 
        <bean id="solrHealthCheck" class="de.bund.gsb.webeditor.server.jcr.healthcheck.SolrHealthCheck">
                <property name="componentName" value="solr" />
                <property name="activated" value="${gsbeditor.healthchecks.solr.activated}" />
        </bean>
 
</beans>

Die Konfiguration der Healthchecks erfolgt über die folgenden Properties in der Runtime-Konfiguration des GSBEditors (Datei gsbeditor.properties):

·         gsbeditor.healthchecks.activated Boolescher Wert der definiert, ob ein Healthcheck der Editor-Applikation bereitgestellt wird (Default false)

·         gsbeditor.healthchecks.repository.activated definiert, ob eine Prüfung des Repositories durchgeführt werden soll (Boolescher Wert, Defalut true)

·         gsbeditor.healthchecks.solr.activated definiert, ob eine Prüfung der Solr-Server durchgeführt werden soll (Boolescher Wert, Defalut true)

Maildistributor

Die Maildistributor-Applikation implementiert die folgenden Checks:

  • Database: Prüft die Verfügbarkeit der Maildistributor-Datenbank
Konfiguration

Die Definition der Maildistributor-Healtchecks erfolgt in der Maildistributor-Applikation in der Spring-Konfiguration cms-healthchecks.xml.

Konfigurationsdatei Maildistributor-Healthchecks

<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xsi:schemaLocation="http://www.springframework.org/schema/beans
                           http://www.springframework.org/schema/beans/spring-beans.xsd">
 
    <bean class="org.springframework.jmx.export.MBeanExporter" lazy-init="false">
        <property name="beans">
            <map>
                <entry key="de.bund.gsb.util:name=MailDistributor_Healthcheck" value-ref="healthCheck"/>
                <entry key="de.bund.gsb.util:name=MailDistributor_Healthcheck_Database" value-ref="mailDistributorDatabaseHealthCheck"/>
            </map>
        </property>
    </bean>
 
    <bean id="healthCheck" class="de.bund.gsb.util.healthcheck.impl.HealthCheckExecutorImpl" factory-method="getInstance">
        <property name="activated" value="${maildistributor.healthchecks.activated}"/>
    </bean>
 
    <bean id="mailDistributorDatabaseHealthCheck" class="de.bund.gsb.maildistributor.input.mbeans.MailDistributorDatabaseHealthCheck">
        <property name="componentName" value="database"/>
        <property name="activated" value="${maildistributor.healthchecks.database.activated}"/>
    </bean>
 
</beans>

Die Konfiguration der Healthchecks erfolgt über die folgenden Properties in der Runtime-Konfiguration des Maildistributors (Datei maildistributor.properties):

·         maildistributor.healthchecks.activated Boolescher Wert der definiert, ob ein Healthcheck der Editor-Applikation bereitgestellt wird (Default false)

·         maildistributor.healthchecks.database.activated definiert, ob eine Prüfung der Maildistributor-Datenbank durchgeführt werden soll (Boolescher Wert, Defalut true)

Überwachung TEMP-Verzeichnisse

Der GSB 10.0.0 schreibt bei der Publikation von Dokumenten die zu publizierenden Dokumente in das TEMP-Verzeichnis der Repository-Tomcats, um die Dokumente dann vom Content- an den Master- und abschließend an die Replication-Server zu übertragen.

Die Dokumente verbleiben anschließend in den TEMP-Verzeichnissen, so dass diese Verzeichnisse in einer produktiv genutzten Installation gesondert betrachtet werden sollten.

Das TEMP-Verzeichnis wird in der Systemd Service-Unit /etc/systemd/system/repository@.service über die Variable CATALINA_TMPDIR definiert. Der Standard sieht die folgenden Verzeichnisse für die drei Repositories vor:

  • Content-Server: /space/gsbos/data/repository-preview/temp
  • Master-Server: /space/gsbos/data/repository-master/temp
  • Replication-Server: /space/gsbos/data/repository-replication/temp

Das Filesystem in denen sich die TEMP-Verzeichnisse befinden sollte hinreichend groß dimensioniert sein, so dass mehrfache umfangreiche Publikationen durchgeführt werden können, ohne dass das Filesystem vollläuft.

Weiterhin sollten alte Dateien in den TEMP-Verzeichnissen regelmäßig gelöscht werden. Das folgende Kommando kann bspw. genutzt werden, um Dateien im TEMP-Verzeichnis des Content-Servers zu löschen, die älter als 5 Tage sind:

find /space/gsbos/data/repository-preview/temp/ -type f –mtime +5 –exec rm {} \;

nach oben