Systemanforderungen

Die service.monitor Installations-Dokumentation gibt auch Hinweise zur Installation von Drittkomponenten, die von service.monitor verwendet werden (z.B. Elasticsearch oder Apache Tomcat). Die individuelle, betriebliche Konfiguration kann davon abweichen und hier nicht vollständig beschrieben werden. Eine Unterstützung kann im Rahmen von individuellen Beratungsleistungen bei con terra angefragt werden.

Systemanforderungen der Webapplikationen (/monitor und /monitor-analytics)

Java

Die folgenden Java Distributionen werden unterstützt:

OpenJDK (JDK und JRE), Versionen 17* und 21
Oracle JDK, Versionen 17* und 21

Anwendungsserver

Apache Tomcat 10

Stellen Sie sicher, dass eine aktuelle Version von Apache Tomcat installiert ist und HTTPS-Verbindungen akzeptiert, z.B. unter https://tomcat-host. HTTPS kann wie im Tomcat User Guide beschrieben konfiguriert werden.

Betriebssystem

Windows
Linux

Datenbank (nur Monitoring)

Oracle Database 18c*, 19c
Microsoft SQL Server 2019*, 2022
PostgreSQL 13*, 14

Browser

Die letzte stabile Version der folgenden Browser wird unterstützt:

Google Chrome
Firefox
Microsoft Edge
Safari

Generelle Hinweise

Die mit einem * versehenen Versionen werden ggf. in einem der nächsten Releases zugunsten einer neueren ersetzt.
Falls Sie andere als die oben genannten Plattformen verwenden, wenden Sie sich an den con terra Support .

Systemanforderungen Elasticsearch Stack

Die Produkte Elasticsearch und Logstash empfangen, verarbeiten und speichern die erhobenen Events, um diese danach in Kibana einer gezielten Recherche und Analyse unterziehen zu können.

Aktuell werden folgende Versionen benötigt:

Elasticsearch 7.17.x (OS , Java )
Logstash 7.17.x
Kibana 7.17.x

Vollständige Übersicht der Elasticsearch System Requirements .

Aus Sicherheits- und Verteilungsgründen wird empfohlen, diese Komponenten unabhängig von der Applikationsinfrastruktur auf einem eigenen Host zu betreiben.

Systemanforderungen Python APIs

Für die Installation von service.monitor und die Abfrage von FME Daten stehen Python APIs zur Verfügung, die eine Installation von Python voraussetzen.

Python Client (Version >=3.6)

Kompatibilität mit con terra Produkten

Nutzerinterkationsdatenerhebung in map.apps Applikationen

Alle map.apps Linie 4 Applikationen können durch die service.monitor Bundles zum Senden von Nutzerinterktionsdaten befähigt werden.

Nutzerinterkationsdatenerhebung in map.apps (Server)

Aktuell liegen Integrationsdaten zur Protokollierung von Nutzerinteraktionsdaten mit den Server-Komponenten von map.apps zwischen map.apps Version 4.7.0 und 4.13 vor.

Nutzerinterkationsdatenerhebung security.manager EE

Aktuell liegen Integrationsdaten zur Protokollierung von Nutzerinteraktionsdaten mit den Server-Komponenten von security.manager EE zwischen den Version 4.15 und 4.19 vor.

Single-Sign-On (SSO) mit security.manager EE

Um ein möglichst hohes Maß an Sicherheit zu gewährleisten, nutzen Sie bitte immer die aktuellste security.manager Version, wenn die Anmeldung in der /monitor-Webapp auf security.manager Authentifizierung umgestellt werden soll.

Architekturentscheidungen

Bitte beachten Sie diese grundsätzlichen Empfehlungen bei der Verwendung von service.monitor:

service.monitor soll von den übrigen Applikationen der IT-Landschaft getrennt betrieben werden. Wenn der Applikationsserver vollständig ausfällt, fällt auch das Monitoring aus.
Elasticsearch und Logstash sollten von den Internet exponierten Applikationen getrennt betrieben werden. Beide führen Speicher und CPU konsumierende Operationen aus.
Die Verteilung der Daten in Elasticsearch über mindestens zwei Knoten in Betracht ziehen oder bei steigendem Datenvolumen vorausplanen.

Speicher

Die Elasticsearch-Komponenten benötigen Ressourcen für den Betrieb. Je mehr Daten verarbeitet, gespeichert und recherchiert werden können müssen, desto großzügiger muss das System dimensioniert sein. Es ist nicht sinnvoll unterhalb der hier genannten Minimalwerte zu bleiben. Die Empfehlungswerte stellen jedoch auch nur eine Empfehlung auf Basis von aktuellen uns bekannten Kunden-Setups dar. Der Betrieb des Elasticsearch Clusters muss daher in der Inbetriebnahmephase insbesondere hinsichtlich dieser Ressourcenanforderungen begleitet werden. Für die langfristige Sicherstellung des Betriebs wird das Index Lifecycle Management verwendet.

	Hauptspeicher (minimal)	Hauptspeicher (empfohlen)	Festplattenspeicher (Startwert)
Elasticsearch	4GB	8GB+	300GB
Logstash	1GB	2GB+	1GB
Kibana	1GB	2GB+	-

Hauptspeicher (minimal)

Hauptspeicher (empfohlen)

Festplattenspeicher (Startwert)

Elasticsearch

4GB

8GB+

300GB

Logstash

1GB

2GB+

1GB

Kibana

1GB

2GB+

Siehe auch Set JVM options .

Port-Freigaben

Die hier genannten Ports sind entweder die Default-Ports der genutzten Komponenten (Tomcat, Elasticsearch) oder die Ports, die service.monitor als Default-Ports verwendet (z.B. Logstash-Pipelines).

Product / component	server issueing the request	request receiving server	port & protocol	description
map.apps	mapapps-host.example.com	logstash-host.example.com	12201/udp	user interactions w/ mapapps (server side)
			12202/udp	log data from map.apps application
security.manager EE	securitymanager-host.example.com	logstash-host.example.com	12201/udp	user interactions w/ security.manager EE
			12202/udp	log data from security.manager EE application
ArcGIS Enterprise	arcgisserver-host.example.com	elastic-host.example.com	9200/tcp or 443/tcp	log data via Elastic Filebeat
		elastic-host.example.com	9200/tcp or 443/tcp	metric data via Elastic Metricbeat
FME Flow	elastic-host.example.com	fmeflow-host.example.com	443/tcp	FME jobs & jog logs requested by Python API
	fmeflow-host.example.com	elastic-host.example.com	9200/tcp or 443/tcp	FME Flow log data via Elastic Filebeat
			9200/tcp or 443/tcp	metric data via Elastic Metricbeat
Monitoring web application	monitoring-host.example.com	db-host.example.com	i.e. 1521,5432/tcp	connection to database by monitoring webapp
		mail-host.example.com	25/tcp	sending e-mails via monitoring-webapplication
		elastic-host.example.com	9200/tcp or 443/tcp	sending information about monitoring events
		kibana-host-.example.com	5601/tcp or 443/tcp	querying for Kibana Rules
		logstash-host.example.com	12202/udp	log data from monitoring application
		webhook-host.example.com	<any>/tcp	Endpoint from Teams/Slack/custom webhook
		monitoring-target.example.com	<any>/tcp	Endpoint of a server/service to be monitored by service.monitor
Analytics web application	analytics-host.example.com	logstash-host.example.com	12201/udp	any interaction data
			12202/udp	log data from analytics application
	client-host.example.com	analytics-host.example.com	443/tcp	sending user interaction data (i.e. map.apps clients)

Product / component

server issueing the request

request receiving server

port & protocol

description

map.apps

mapapps-host.example.com

logstash-host.example.com

12201/udp

user interactions w/ mapapps (server side)

12202/udp

log data from map.apps application

security.manager EE

securitymanager-host.example.com

logstash-host.example.com

12201/udp

user interactions w/ security.manager EE

12202/udp

log data from security.manager EE application

ArcGIS Enterprise

arcgisserver-host.example.com

elastic-host.example.com

9200/tcp or 443/tcp

log data via Elastic Filebeat

elastic-host.example.com

9200/tcp or 443/tcp

metric data via Elastic Metricbeat

FME Flow

elastic-host.example.com

fmeflow-host.example.com

443/tcp

FME jobs & jog logs requested by Python API

fmeflow-host.example.com

elastic-host.example.com

9200/tcp or 443/tcp

FME Flow log data via Elastic Filebeat

9200/tcp or 443/tcp

metric data via Elastic Metricbeat

Monitoring web application

monitoring-host.example.com

db-host.example.com

i.e. 1521,5432/tcp

connection to database by monitoring webapp

mail-host.example.com

25/tcp

sending e-mails via monitoring-webapplication

elastic-host.example.com

9200/tcp or 443/tcp

sending information about monitoring events

kibana-host-.example.com

5601/tcp or 443/tcp

querying for Kibana Rules

logstash-host.example.com

12202/udp

log data from monitoring application

webhook-host.example.com

<any>/tcp

Endpoint from Teams/Slack/custom webhook

monitoring-target.example.com

<any>/tcp

Endpoint of a server/service to be monitored by service.monitor

Analytics web application

analytics-host.example.com

logstash-host.example.com

12201/udp

any interaction data

12202/udp

log data from analytics application

client-host.example.com

analytics-host.example.com

443/tcp

sending user interaction data (i.e. map.apps clients)

Bei der Realisierung von Firewall-Regeln zwischen zwei Hosts ist zu beachten, dass keine Kontrolle über den Quell-Port des Clients der Verbindung besteht, sondern nur der Ziel-Port klar definiert werden kann.