Configuring and Monitoring Service Apps

Configuration Parameters

Service Apps typically read there configuration from their oConfig.json file. The default setup provides such a sample file in res/oConfigNode.json. When building the service app, the file is copied into the dist folder, and renamed to oConfig.json.

tip

Parameters can be set either in the oConfig.json file, or on the command line parameter using the -- syntax. The two examples below are therefore equivalent:

• oConfig.json syntax: "myparameter": "somevalue"
• command line parameter: npm run serve:node -- myparameter=somevalue

Parameter	Sample value	Documentation
defaultHost	myinstance.olympe.io	The instance to connect to, with good default values for all parameters. This must be set for local development (for both UI Apps as well as Service Apps), as well as for Service Apps deployed outside of the Olympe Cloud. For Olympe Cloud deployments, UI Apps should not define defaultHost (it's taken from the hostname in the URL), and Service Apps should use defaultHost=<env-name>-frontend.
sc.app	01888abcd8e4e5fa301c	For Service Apps: the tag of the Service App to be launched. For UI Apps: the tag of the app to launch by default.
sc.production	true	Set to true to enable some optimizations relevant in production. In particular, when true apps no longer subscribe to changes to the application graph (which is not supposed to happen in production).
sc.remoteactiontimeout	20000	The number of milliseconds after which a remote action will timeout. Increase this value if the Remote Actions have some slow processing.
bus.vhost	myinstance	The bus vhost to connect to.
auth.autoLogin	true	Whether to use auth.autoUser and auth.autoPassword for authentication.
auth.autoUser	username	The username to use to connect to the Olympe Orchestrator.
auth.autoPassword	password	The password to use to connect to the Olympe Orchestrator.
host.processProbe	true	Whether to enable the /readiness probe for automatic restart (see below). Set to true by default.

Custom Network Configurations

The following parameters are available for advanced configurations, and override the defaultHost defaults.

Parameter	Sample value	Documentation
server.host	myinstance.olympe.io	The hostname or IP address where to reach the Olympe Orchestrator.
server.port	443	The port to be used.
server.ssl	true	Whether to enable HTTPS / WSS or not.
bus.host, bus.port, bus.ssl, bus.path		Enable configuring the connection to the message broker used for UI App - Service App and Service App - Service App communications.
data.httpHost, data.httpPort, data.httpSSL, data.httpPath		For advanced datasource configuration.

Ensuring that Service Apps are running

Olympe service apps have a default endpoint that Kubernetes or other infrastructure managers can use to monitor their well being. The healthcheck endpoints are /readiness and /liveness on port 3141. Upon success, the endpoint returns a code 200, with details in the response body. If something goes wrong, the endpoint returns a 500 code, with details in the response body. Infrastructure managers can use those probes probes to automatically restart failing processes.

The semantics of the probes are the same as their Kubernetes counterparts

• readiness: returning the status of the application to indicate when it's "ready" to be used
• liveness: returning the status of the application to indicate whether the application is still in a good shape or should be taken down

Default Checks

The default health checks validate the following elements:

• The connection to the Olympe Orchestrator is active
• The service app is authenticated (i.e. not running as guest)
• The service app is connected to the bus
• (If applicable) Data sources are accessible

Additional checks can be implemented within applications, e.g. to verify connectivity to external services, databases, storage, etc. You can leverage these both from code and from Draw:

Implementing Custom Health Checks in DRAW

DRAW provides a Register Health Check brick, to be used within a Service running in the Service App to be monitored. The brick shall output either a Control Flow if all is well, or an Error Flow otherwise. It has a Probe Type input to react to the right probe. The value can be either All, Liveness or Readiness.

See the brick documentation for more details.

Implementing Custom Health Checks in CODE

Use the Process.onHealthCheck() hook to implement custom health checks. An example can be found in the RegisterHealthCheck brick implementation.

Process.onHealthCheck(() => {/* handler method */}, {type: "<probeType>"})

<probeType> can be

• ProbeType.ALL
• ProbeType.LIVENESS
• ProbeType.READINESS