BUG: NFR 5.3.3 - Output security server and central server status using json format

[VitaliStupin]

Affected components: - Affected documentation: - Estimated delivery: - External reference: -

Problem Source code must conform to NFR (https://github.com/vrk-kpa/xroad-joint-development/blob/master/NFR.md)

Acceptance criteria

• Source code conforms to NFR

[ToomasMolder]

Security server environmental monitoring status is available through JMXMP (see also https://github.com/ria-ee/X-Road/blob/develop/xtee6/doc/EnvironmentalMonitoring/Monitoring-architecture.md, getSecurityServerMetrics). Convertible into JSON.

Security server operational monitoring status is available over X-road messages (see also https://github.com/ria-ee/X-Road/blob/develop/xtee6/doc/OperationalMonitoring/Protocols/pr-opmon_x-road_operational_monitoring_protocol_Y-1096-2.md, methods getSecurityServerOperationalData and getSecurityServerHealthData) or JMXMP (see also https://github.com/ria-ee/X-Road/blob/develop/xtee6/doc/OperationalMonitoring/Protocols/pr-opmonjmx_x-road_operational_monitoring_jmx_protocol_Y-1096-3.md, method getSecurityServerHealthData only). Convertible into JSON.

Central server status using similar methods is not available as far as I know.

[iluwatar]

The proposed functionality is closely related to health check implemented in external load balancing project. Here is additional information about the health check that we have already implemented.

Health check service The health check service is a new feature of xroad-proxy for load balancing support. It is disabled by default but can be configured and enabled via configuration options under [Proxy]:

• health-check-interface is the network interface the service listens to. The default value is 0.0.0.0 (listening every interface)
• health-check-port is the TCP port the service listens to. The default value is 0 which disables the health check service entirely.

The service can be accessed using plain HTTP. It will return HTTP 200 OK if the proxy should be able to process messages and HTTP 500 Internal Server Error otherwise. An error condition will add a short message about the failure reason to the body of the response.

The health checks currently checks that:

• KeyConf.getInstance().getAuthKey() is accessible and that the authentication key OCSP response status for the "end entity certificate" is "good".
• ServerConf.getIdentifier() is accessible (it will not be accessible if the database is down)

Each of these checks currently has a separate timeout of 5 seconds. If the check fails to produce a response in this time, it will be considered as a health check failure and will cause a HTTP 500.

Each of the results of the above listed separate checks will be cached for a short while to avoid excess resource usage by the health check. The results are cached for a short time, though:

• Successful check results will be cached for 2 seconds before a new check is triggered. This is to make sure the OK results are as fresh as possible without constant checking.
• Check failures will be cached for 30 seconds before a new check is triggered. This should allow for a system to get up and running after a failure before checking again.

Known check result inconsistencies vs. actual state:

• The health check will detect if the Tokens have not been signed into after Signer startup. It will however, not detect immediately if the Tokens are logged out of after usage. As long as the AuthKey is cached in KeyConf, the health check will return OK. At this point in time, message sending might fail already if the necessary signing context values for sending the message are not cached. As the caches expire (after max 5 mins), the health check will start returning failures.

[iluwatar]

The functionality is also related to diagnostics offered by the security server UI.

[JyrgenSuvalov]

Thanks for the info. And I agree that this is closely related to the diagnostics page. Reusing existing resources is definitely planned. And I do think the output should be available in both human-readable form in the diagnostics section as well as machine-readable in the intended /heartbeat.json form.

[JyrgenSuvalov]

Transferred to X-Road Service Desk as an enhancement request. Can be closed.