Fabasoft app.telemetry ArchitecturePermanent link for this heading

Fabasoft app.telemetry ServerPermanent link for this heading

The Fabasoft app.telemetry Server consists of multiple Processes providing different Services.

Fabasoft app.telemetry Server ServicePermanent link for this heading

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.

Fabasoft app.telemetry Worker ServicePermanent link for this heading

The Fabasoft app.telemetry Worker 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.

Fabasoft app.telemetry WebservicePermanent link for this heading

The Fabasoft app.telemetry Webservice receives the requests form the Fabasoft app.telemetry Clients and passes them to the worker for further processing.

Fabasoft app.telemetry Ecomm ServicePermanent link for this heading

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).

Fabasoft app.telemetry AgentPermanent link for this heading

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 on request.

Fabasoft app.telemetry SNMP AgentPermanent link for this heading

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.

Fabasoft app.telemetry ClientPermanent link for this heading

The Fabasoft app.telemetry Client connects vie http/https to the Fabasoft app.telemetry Webserver. It loads static resources from the Webserver and dynamic data through JSON requests, which the Webserver forwards to the Fabasoft app.telemetry Worker.

Secure CommunicationPermanent link for this heading

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 webserver configuration parameters.

Certificate ManagementPermanent link for this heading

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 being implemented by checking the sha2 hash of the client certificate against those permitted in the trusted_certificates.cfg file. The client certificates are automatically added to the trusted certificate of all Fabasoft app.telemetry server services.

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 will be denied.

To generate new certificates, simply remove the certificate from the file system and restart the respective service.

To create a new self-signed 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.nopass.key 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.

Trusted CertificatesPermanent link for this heading

When setting the trusted_certificates.cfg manually make sure to provide the following trusts:






Worker, Ecomm


Server, Webserver



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 adds the hash of it to the trusted_certificates.cfg files of all required services.

The remote agents automatically trust the first service connecting to the agent 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 deleted or patched on all remote agents.

Failover/Standby configurationPermanent link for this heading

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.