The Fabasoft app.telemetry Server consists of multiple Processes providing different Services.
The Fabasoft app.telemetry Configuration service is responsible for managing the configuration and providing a shared view thereof to all Fabasoft app.telemetry services.
The Fabasoft app.telemetry Server service is responsible for the Communication with all Fabasoft app.telemetry Agents, which includes the collection of counter, service-check and telemetry data. Counter and service-check data are processed to provide a system status view and are persisted on a database as configured. Telemetry data are persisted, analyzed to provide a log pool based view of requests. These request data are persisted to the database as configured.
The Fabasoft app.telemetry Worker service is responsible for providing Information to the Fabasoft app.telemetry Client through the Fabasoft app.telemetry Webservice. The Fabasoft Worker Service reads telemetry data from disk written by the Fabasoft app.telemetry Server and it can load requests in memory.
The Fabasoft app.telemetry Webservice receives the requests form the Fabasoft app.telemetry Clients and passes them to the worker for further processing.
The Fabasoft app.telemetry Ecomm service is responsible for handling outgoing communication requests using http/https transfer (e.g. sending a session to a service desk).
The Fabasoft app.telemetry Sync service enables redundant storage of telemetry data.
The Fabasoft app.telemetry Service Analyzer service processes telemetry data to analyze it from a service oriented perspective to be provided in the Service View in the app.telemetry Client.
The Fabasoft app.telemetry Agent collects counter- and servicecheck-data and receives telemetry data from local applications. All data is buffered and streamed to the Fabasoft app.telemetry Server service.
The Fabasoft app.telemetry SNMP Agent provides access to agent and status information through the use of the SNMP-daemon to allow for example another Fabasoft app.telemetry Agent to query the information.
The Fabasoft app.telemetry Client uses the Fabasoft app.telemetry Webserver to load static resources and dynamic data through JSON requests, which the Webserver forwards to the appropriate Fabasoft app.telemetry Service.
The communication between all the Fabasoft app.telemetry services is encrypted using TLS protocol with ciphers currently stated as secure. The communication between the Fabasoft app.telemetry Client and the Fabasoft app.telemetry Webserver uses http or https as provided by the webserver in use (Microsoft Internet Information Server or Apache Webserver). Configure http/https security as required using the standard webserver configuration parameters.
By default, all Fabasoft app.telemetry Services create 2048 bit RSA self-signed certificates for secure communication. The certificates are stored locally as cli_certificate.pem and/or srv_certificate.pem on the machine under /etc/app.telemetry/<servicename> respectively “C:\ProgramData\Fabasoft app.telemetry\<servicename>”. Validation of client certificates is implemented by checking the SHA-256 hash of the client certificate against those permitted in the trusted_certificates.cfg file or the cli_certificate.fingerprint of known dependent services. The client certificates are automatically trusted because services trust known dependent services automatically to ease configuration.
Be careful when updating the Fabasoft app.telemetry Server service client certificate, because the trusted_certificates.cfg file on all agents has to be removed or rolled out, because the agent only adds the hash of the client certificate of the first server connecting to the app.telemetry Agent to the trusted_certificates.cfg. All connections with different certificates are rejected.
To generate new certificates, simply remove the certificate from the file system and restart the respective service.
To create a new self-signed certificate for the use as a client certificate:
openssl genrsa -out key.pem 2048
openssl req -new -key key.pem -out key.csr
… provide organization parameters requested
openssl x509 -req -days 3650 -in key.csr -signkey key.pem -out certificate.pem
cat key.pem certificate.pem > cli_certificate.pem
To compute the hash needed for the trusted_certificates.cfg file:
openssl x509 -fingerprint -in cli_certificate.pem -noout -sha256
Insert the fingerprint value at the beginning of a new line in the trusted_certificates.cfg file of the service that should trust that client certificate.
When setting the trusted_certificates.cfg manually make sure to provide the following trusts:
Server, Webserver, Service Analyzer
Server, Worker, Ecomm, Service Analyzer
Each service has to include the hashes of the cli_certificates.pem of all trusted servers in their trusted_certificates.cfg. For example, the server/trusted_certificates.cfg has to include the hashes of worker/cli_certificate.pem, ecomm/cli_certificate.pem and webserver/cli_certificate.pem.
The default way to provide this is that each service checks its own certificates on startup. If the certificate is absent or invalid it creates a new self-signed certificate and writes the certificate fingerprint to the cli_certificate.fingerprint which dependent services read to automatically allow valid connections.
The remote agents automatically trust the first Fabasoft app.telemetry Server service connecting to them by adding its client certificate hash to the new trust file. When changing the server/cli_certificate.pem, the agent/trusted_certificates.cfg has to be removed or patched on all remote agents.
When setting up a Standby server, you have to deal with the problem, that your agents will only accept one server identified by its client certificate. So you either copy your server client certificate to the failover server or you have to distribute a trusted_certificates.cfg file containing all hashes of the server/cli_certificates.pem of all servers to all agents. The most common way to deal with this is to replace all certificates and trusted_certificates.cfg of the backup server with those of the original server.