System requirements
| The service.monitor installation documentation also provides information on the installation of third-party components used by service.monitor (e.g. Elasticsearch or Apache Tomcat). The individual, operational configuration may differ from this and cannot be fully described here. Support can be requested from con terra as part of individual consulting services. |
System requirements of web applications (/monitor and /monitor-analytics)
Java Runtime Environment
The following Java distributions are supported:
-
OpenJDK (JDK or JRE), versions 17* and 21
-
Oracle JDK, versions 17* and 21
Application server
-
Apache Tomcat 10
Make sure a recent version of Apache Tomcat is installed, accepting HTTPS connections at e.g. https://tomcat-host. HTTPS can be configured as described in the Tomcat User Guide .
Database (only Monitoring)
-
Oracle Database 18c*, 19c
-
Microsoft SQL Server 2019*, 2022
-
PostgreSQL 13*, 14
Browser
Latest stable version:
-
Google Chrome
-
Firefox
-
Microsoft Edge
-
Safari
|
General Hints
|
System requirements Elasticsearch
The products Elasticsearch and Logstash receive, process and store the collected events so that they can then be subjected to targeted research and analysis in Kibana.
Currently, these versions are required:
Full overview of Elasticsearch system requirements .
| For security and distribution reasons, it is recommended that you run these components on a separate host, independent of the application infrastructure. |
System requirements Python APIs
Python APIs are available for installing service.monitor and querying FME data, which require Python to be installed.
-
Python client (version >=3.6)
Compatibility with other con terra products
User interaction data collection in map.apps applications.
All map.apps line 4 applications can be enabled to send user interaction data through service.monitor bundles.
User interaction data collection in map.apps (server)
Currently, integration data for logging user interaction data with the server components of map.apps is available between map.apps version 4.7.0 and 4.13.
Architectural Considerations
Here are some basic recommendations you may follow when setting up service.monitor.
-
Run service.monitor applications separately from your applications - if your application server fails completely you are going to recognize this too late
-
Separate Elasticsearch and Logstash from your internet exposed applications - these are performing memory and cpu consuming operations.
-
Run Elasticsearch cluster with at least two nodes or be at least prepared for growing requirements
Memory and hard disk memory
The Elasticsearch components require resources for operation. The more data that needs to be processed, stored and searched, the more generously the system must be dimensioned. It does not make sense to stay below the minimum values mentioned here. However, the recommended values are only a recommendation based on current customer setups known to us. The operation of the Elasticsearch cluster must therefore be accompanied during the commissioning phase, especially with regard to these resource requirements. Index Lifecycle Management is used to ensure long-term operation.
| Memory (minimal) | Memory (recommended) | Hard disk (initial value) | |
|---|---|---|---|
Elasticsearch |
4GB |
8GB+ |
300GB |
Logstash |
1GB |
2GB+ |
1GB |
Kibana |
1GB |
2GB+ |
- |
Please see Set JVM options .
Port shares
| The ports mentioned here are either the default ports of the components used (Tomcat, Elasticsearch) or the ports that service.monitor uses as default ports (e.g. 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) |
| When implementing firewall rules between two hosts, it should be noted that there is no control over the source port of the client of the connection, only the destination port can be clearly defined. |