Übersicht der Update-Hinweise

Im Zuge eines Upgrades müssen alle Elasticsearch zugehörigen Objekte wie Pipelines, Templates, Kibana Diagramme und Ingest Pipelines aktualisiert werden.

4.9

Anpassung der Datenbank-Tabellen

Durch die Erweiterung des Monitorings um eine mögliche Verzögerung der Benachrichtigung bei Fehlern muss die Tabelle SM_JOB aktualisiert werden. Bitte beachten Sie die SQL-Update-Skripte, die sich im Ordner resources\sql\upgrade\4.9 der Auslieferung befinden.

4.8

Aktualisierung von Tomcat und Java

Bitte aktualisieren Sie Ihre Tomcat-Instanz auf Version 10. Falls Sie bisher Java 11 verwendet haben, aktualisieren Sie bitte auf Version 17 oder 21.

4.7

Es müssen keine expliziten Aktionen ausgeführt werden.

4.6

Properties

Die Properties der beiden Webapplikationen monitor und monitor-analytics sind angeglichen und mit den anderen con terra Produkten harmonisiert worden. Dies betrifft die Properties des Mailing:

mail.host wird zu mailing.host.
Diese Änderung muss in externen application.properties-Dateien nachgetragen werden.

Aktualisierung von Elastic Index Lifecycle Management Policies & Templates

Wenn bereits service.monitor 4.5 eingesetzt wird, wird eine Aktualisierung der Index Lifecyle Policies und Index Templates für die eingesetzten Datenquellen nötig (resources/analytics/elasticsearch/dev-console). In den Templates wird ein Fehler mit der alias-Konfiguration behoben und das Verwenden von Elastic Ingest Pipelines verankert.

Ist seit Version 4.5 bereits die Datenquelle zu map.apps Nutzerinteraktionen aktiv, dann müssen folgende Schritte ausgeführt werden (SRVMON-718):

Aktualisierung von ILM und Index Template wie oben beschrieben
Ausführen der einzelnen Statements unten, dazu muss -000001 mit dem Wert des aktuellsten Index ausgetauscht werden (dies kann für die einzelnen Indizes unterschiedlich sein)

Update analytics usagelog indices config

POST ct-analytics-app*/_alias/analytics-usagelog-app
POST ct-analytics-app-000001/_alias/analytics-usagelog-app
{"is_write_index":true}


POST ct-analytics-map*/_alias/analytics-usagelog-map
POST ct-analytics-map-000001/_alias/analytics-usagelog-map
{"is_write_index":true}

POST ct-analytics-log*/_alias/analytics-usagelog-log
POST ct-analytics-log-000001/_alias/analytics-usagelog-log
{"is_write_index":true}

POST ct-analytics-server*/_alias/analytics-usagelog-server
POST ct-analytics-server-000001/_alias/analytics-usagelog-server
{"is_write_index":true}

POST ct-analytics-tool*/_alias/analytics-usagelog-tool
POST ct-analytics-tool-000001/_alias/analytics-usagelog-tool
{"is_write_index":true}

DELETE ct-analytics-app*/_alias/ct-analytics-app
DELETE ct-analytics-tool*/_alias/ct-analytics-tool
DELETE ct-analytics-map*/_alias/ct-analytics-map
DELETE ct-analytics-log*/_alias/ct-analytics-log
DELETE ct-analytics-server*/_alias/ct-analytics-server

Im Falle der Verwendung von service.monitor mit FME Server Jobs sind ebenso manuelle Anpassungen nötig, falls die Funktionalität bereits eingesetzt wird (SRVMON-733). Durch einen Fehler kam es hier zu einer falschen Zuordnung von Indexen, Alias und Patterns (ct-fme-jobs vs. ct-fme-job).

Die Bestandsdaten müssen in das unter ILM-Verwaltung stehende Index-Pattern ct-fme-jobs-* kopiert werden. Dies geschieht über eine Reindexierung in den Alias ct-fme-jobs. Danach kann der Alt-Index ct-fme-job entfernt werden.

Correct FME Jobs Index data location

# re-index pre-existing entries to index alias
POST _reindex?wait_for_completion=false
{
  "source": {
    "index": "ct-fme-job"
  },
  "dest": {
    "index": "ct-fme-jobs"
  }
}
# once re-indexing has finished and after verifying all fme jobs have been transfered, the old index is safe to delete
DELETE /ct-fme-job

# same procedure for fme jobroutes
POST _reindex?wait_for_completion=false
{
  "source": {
    "index": "ct-fme-jobroute"
  },
  "dest": {
    "index": "ct-fme-jobroutes"
  }
}
DELETE /ct-fme-jobroute

Benachrichtigungen: Aktualisierung des Monitoring Datenbankschemas

Bitte führen Sie das SQL-Skript für Ihre Datenbank unter resources/sql/upgrade/4.6 aus.

Monitoring: Oracle DB Datentyp-Prüfung

Falls Soe Oracle DB nutzen: Bitte prüfen Sie, ob bereits mit dem letzten Upgrade resources/sql/upgrade/4.5/oracle-schema-changes.sql ausgeführt wurde.

Analytics Bundles für map.apps

Die Bundles zur Erhebung der Nutzerinteraktionen folgen nun einem eigene Release Zyklus und sind von z.B. usagelog_restservice nach analytics_restservice umbenannt worden. Dies muss bei der Referenzierung der Bundles in der app.json oder den application.properties von map.apps beachtet werden.

4.5

Monitoring

Migration Oracle DB Datentyp von LONG RAW zu BLOB

Um den nicht mehr empfohlenen Datentyp LONG RAW bei Oracle Datenbanken durch Um den nicht mehr empfohlenen Datentyp LONG RAW bei Oracle Datenbanken durch den Datentyp BLOB zu ersetzen, führen Sie das unter resources\sql\upgrade\4.5 liegende SQL-Skript aus.

Die Migration erzwingt das Setzen des application.property-Wertes db.type auf den Wert oracle.

4.4

Analytics

Elasticsearch 7

Mit der service.monitor Version 4.4 wurde ein großer Versionssprung bei der in Analytics verwendeten Basistechnologie Elasticsearch vorgenommen. Bitte befolgen Sie folgende Updatehinweise.

Monitoring

Anpassung der Datenbank-Tabellen

Durch die Erweiterung des Monitorings um das Passwort-Management, muss für bestehende Installation eine neue Tabellen erzeugt werden. Bitte beachten Sie die SQL-Update-Skripte, die sich im Ordner update des SQL-Verzeichnisses des Installationspaketes fürs Monitoring befinden.

Konfigurationsänderungen

Java Version

service.monitor unterstützt Java Runtime Environments in der Version 8 und 11.

application.properties

Die Konfiguration des Datenbankherstellers hat sich in der Konfiguration des Monitoring vereinfacht. Statt aller Angaben zu Treiber, Dialekt usw machen zu müssen, reicht nun die Setzung einer einzelnen Property (hier PostgreSQL als Beispiel):

db.type=postgresql

4.3

In diesem Abschnitt werden alle Änderungen aufgeführt, die bei der Durchführung von Updates zu berücksichtigen sind.

Anpassung der Datenbank-Tabellen

Durch die Erweiterung des Monitorings um die Dienst-Expectations, müssen für bestehende Installation zwei neue Tabellen erzeugt werden. Bitte beachten Sie die SQL-Update-Skripte, die sich im Ordner update des SQL-Verzeichnisses des Installationspaketes fürs Monitoring befinden.

Striktere Zertifikats-Validierung bei HTTP SSL Verbindungen (seit Monitoring 4.3.3)

Seit Version 4.3.3 findet aus Sicherheitsgründen eine striktere Zertifikats-Validierung von HTTP SSL-Verbindungen statt. Dies bedeutet, dass in der Standardeinstellung invalide, ungültige oder nicht vertraute Zertifikate durch service.monitor nicht mehr akzeptiert werden. service.monitor wird eine Benachrichtigung senden, sollte ein Zertifikat nicht (mehr) valide sein. Dies gilt auch für (valide) Zertifikate, die nicht im Keystore der Java Virtual Machine des Servlet Containers vorliegen. Bitte lesen Sie die Dokumentation, um den Import durchzuführen.

Dieses Verhalten kann durch eine Konfigurationseinstellung verändert werden. Siehe dazu das Kapitel Übersicht der Konfigurationsoptionen und das Kapitel SSL Konfigurationsoptionen und -hinweise der Installationsanleitung.

Konfigurationsänderungen

Manuelle Anpassung des Mail Subjects

Über die Konfigurationswerte mail.subject.de und mail.subject.en können in der Datei application.properties nun Präfixe definiert werden, die dem üblichen Mail-Subject vorangestellt werden.