Configuration¶
ExaCheck reads from a YAML or JSON configuration file containing the list of checks. By default, the configuration file will be loaded from /etc/exabgp/exacheck.yaml. If the configuration file extension is json, the file will be loaded as a JSON file rather than YAML.
Base Structure¶
A (minimal) configuration schema looks like this:
---
# The list of health checks
checks:
- name: Example DNS Service
description: Perform a basic SOA query for example.com to 192.0.2.255. If the query returns a response, 192.0.2.255 would be advertised with BGP.
args:
method: dns
host: 192.0.2.255 # Note DNS queries are being sent to 192.0.2.255 which should be bound to loopback
query: example.com
prefixes:
- 192.0.2.255
nexthop: self
# An optional list of notification targets
notifications:
- name: Microsoft Teams Example
description: This target will only receive route withdraw/announce events.
url: msteams://organisation/TokenA/TokenB/TokenC/
Configuration Keys¶
The following top level configuration keys are available:
| Key | Type | Default |
|---|---|---|
exacheck |
Dict | undef |
checks |
List[Check] | undef |
logging |
Optional List[LogMethods] | undef |
notifications |
Optional List[Notifications] | undef |
sentry |
Optional Dict | undef |
ExaCheck¶
The exacheck key contains the various internal configuration for ExaCheck. Configuration to enable/disable live reloading and the monitoring interval can be adjusted using this key.
For the list of available configuration options sett the ExaCheck internal configuration page.
Checks¶
The checks key contains a list of the health checks that should be executed. For the configuration of individual checks see the health checks configuration page.
Logging¶
The logs key contains a list of log targets. These may be file based or remote syslog (UDP/TCP) servers. For configuration options see the logging configuration page.
Notifications¶
The notifications key contains a list of notification targets. See the notifications configuration page.
Sentry¶
Sentry error reporting/profiling can be configured with the sentry key. See the Sentry configuration page.
Validation¶
The configuration file is validated using Pydantic. The configuration file is parsed into a dictionary from YAML or JSON which is then loaded into the Pydantic model.
Validation is as strict as possible while also being safe - ExaCheck will not start if the configuration is invalid and live reloads are skipped if the configuration becomes invalid.
Configuration Schema¶
A JSON schema for the configuration is available in schema.json. Alternatively the schema can be generated by the command line interface directly.
The JSON schema can be used by certain IDEs (VS Code as an example) to validate the configuration as you edit it. It can also be used to visualize the list of available options using a tool such as JSON Crack.
VS Code¶
If using VS Code with the YAML Language Server the following header may be set in the configuration file: