Settings layout guide

Morio will look for its settings in different locations:

Location	Files	Documentation
/etc/morio/moriod	settings.[json|yaml]	The main settings files
/etc/morio/moriod/settings.d	*.[json|yaml]	The settings.d folder
/etc/morio/moriod/healthchecks.d	*.[json|yaml]	The healhchecks.d folder
/etc/morio/moriod/policy.d	*.[json|yaml]	The policy.d folder

Read on to learn how exactly the settings in these locations are loaded.

The Main settings files

Morio will look for its main settings file by reading:

• /etc/morio/moriod/settings.yaml

If that file is not on disk, Morio will attempt to read its JSON equivalent:

• /etc/morio/moriod/settings.json

Any settings found in this file will be used as the starting point to assemble the settings.
If neither file exists, Morio will use an empty settings object as its starting point.

note

The settings in this file should adhere to the settings schema.

tip

We recommend not using a main settings file, but use the settings.d folder instead.

warning

When both files are on disk, the settings.json file will not be read or taken into account.

The settings.d folder

After reading the main settings file, Morio will scan the /etc/morio/moriod/settings.d folder for:

• *.json
• *.yaml

In other words, any JSON or YAML files in this folder will be read.

Understanding file names and settings structure

The files in the settings.d folder will not be added to the top-level of the settings object. Instead, their base file name the file name without the .json or .yaml extension) will determine where the file contents will be added to the settings object.

For example, if you place a file named tokens.vars.yaml in the settings.d folder, its contents will be loaded as the tokens.vars property of the settings object.

This allows you to fan out your settings into multiple files, rather than having to maintain a large settings file, as that can get unwieldy.

note

The settings in these files should adhere to the settings schema.

warning

JSON files will be read first, then YAML files. So when their settings overlap, the YAML file will win.

The healthchecks.d folder

After reading the settings in the settings.d folder, Morio will scan the /etc/morio/moriod/healthchecks.d folder for:

• *.json
• *.yaml

In other words, any JSON or YAML files in this folder will be read.

For health checks only

The healthchecks.d folder is a more convenient way to populate the services.watcher.instances.single.monitors settings.

In other words, this is where you can define your healthchecks (the term monitors is what is used by Elastic Heartbeat which underpins this service).

File structure

These files can be structured in three different ways:

A single healthcheck configuration object

The file can hold a single healthcheck configuration object:

id: some_id # ID is optional and will be auto-generated when missing
type: http
name: Example Healthcheck
hosts: 
  - "http://morio.it/style.css"
check.response.status: 
  - 200

An array of healthcheck configuration objects

The file can hold an array (list) of healthcheck configuration objects:

# Example 1 (with ID)
- id: some_id # ID is optional and will be auto-generated when missing
  type: http
  name: Example Healthcheck 1
  hosts: 
    - "http://apt.morio.it/"
  check.response.status: 
    - 200

# Example 2 (no ID)
-  type: http
  name: Example Healthcheck 2
  hosts: 
    - "http://rpm.morio.it/"
  check.response.status: 
    - 200

An object with multiple healthcheck configurations

In this case, the file holds an object where the object’s (top-level) properties hold the healthcheck ID, and the value is the healthcheck configuration object:

# Example 1
this_becomes_the_ID_for_1:
  type: http
  name: Example Healthcheck 1
  hosts: 
    - "http://apt.morio.it/"
  check.response.status: 
    - 200

# Example 2
this_becomes_the_ID_for_2:
  type: http
  name: Example Healthcheck 2
  hosts: 
    - "http://rpm.morio.it/"
  check.response.status: 
    - 200

The health check ID

Each health check must have a unique ID in Morio.

You can set the ID explicitly — either as a field in the healthcheck configuration, or as the key in a an object with multiple healthceck configurations — or skip it.

When no ID is set, Morio will auto-generate the healthcheck ID by using the SHA-256 hash of the healthcheck configuration.

warning

This means that when the healthcheck configuration is changed, the ID will also change. If you want this behaviour, do not specify an ID. If you do not want it, make sure to set the ID explicitly.

The policy.d folder

Last but not least, Morio will scan the /etc/morio/moriod/policy.d folder for:

• *.json
• *.yaml

In other words, any JSON or YAML files in this folder will be read.

For access policy rules only

The policy.d folder is a more convenient way to populate the iam.policy settings.

In other words, this is where you can define your access policy rules.

File structure

These files can be structured in three different ways:

A single policy rule

The file can hold a single policy rule:

id: some_id # ID is optional and will be auto-generated when missing
when:
  method: GET
  role: user
  url: /some/url/example
then: allow

An array of policy rules

The file can hold an array (list) of policy rule objects:

# Example 1 (with ID)
- id: some_id # ID is optional and will be auto-generated when missing
  when:
    method: GET
    role: user
    url: /some/url/example/1
  then: allow

# Example 2 (no ID)
-  when:
    method: GET
    role: user
    url: /some/url/example/2
  then: allow

An object with multiple policy rules

In this case, the file holds an object where the object’s (top-level) properties hold the policy rule ID, and the value is the policy rule itself:

# Example 1
this_becomes_the_ID_for_1:
  when:
   method: GET
   role: user
   url: /some/url/example/1

# Example 2
this_becomes_the_ID_for_2:
  when:
   method: GET
   role: user
   url: /some/url/example/1

The access poliocy rule ID

Each access policy rule must have a unique ID in Morio.

You can set the ID explicitly — either as a field in the rule configuration, or as the key in a an object with multiple policy rules configurations — or skip it.

When no ID is set, Morio will auto-generate the rule ID by using the SHA-256 hash of the rule configuration.

warning

This means that when the rule is changed, the ID will also change. If you want this behaviour, do not specify an ID. If you do not want it, make sure to set the ID explicitly.