Probes

Probes are the heart of the monitoring requests. Probes are made out of an array of "requests" and some controls. The control parameters determine how the probes are performed, such as repetition intervals, probe name, identification and text descriptions. Requests are either Ping, TCP or HTTP(S) requests to some location. Monika goes through each probe object in the monika.yml config file, sends it out, and determines whether an alert or notification needs to be sent out.

1 probes:
2   - id: '1'
3     name: Name of the probe
4     description: Probe to check GET time
5     interval: 10 # in seconds
6     requests:
7       - method: GET
8         url: https://github.com
9     alerts: []
10   - id: '2'
11     name: Name of the probe 2
12     description: Probe to check GET health
13     interval: 10 # in seconds
14     requests:
15       - method: GET
16         url: https://github.com
17     alerts: []

Basically probes are arranged as arrays of request objects.

HTTP Request Anatomy

1 probes:
2   - id: '1'
3     name: 'Example: get Time'
4     description: Probe
5     interval: 10 # in seconds
6     requests:
7       - method: POST
8         url: https://mybackend.org/user/login
9         timeout: 7000 # in milliseconds
10         saveBody: true
11         headers:
12           Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkhlbGxvIGZyb20gSHlwZXJqdW1wIiwiaWF0IjoxNTE2MjM5MDIyfQ.T2SbP1G39CMD4MMfkOZYGFgNIQgNkyi0sPdiFi_DfVA
13         body:
14           username: someusername
15           password: somepassword
16         alerts:
17           - assertion: response.status != 200
18             message: Status not 2xx
19         allowUnauthorized: true
20         followRedirects: 1
21     incidentThreshold: 3
22     alerts:
23       - assertion: response.status != 200
24         message: HTTP response status is {{ response.status }}, expecting 200

Details of the field are given in the table below.

Good to know

To reduce network usage, HTTP responses are cached with 5 time-to-live by default. This cache is then reused for requests with identical HTTP request config, e.g. headers, method, url.

This cache is usable for probes which does not have chaining requests.

Request Body

By default, the request body will be treated as-is. If the request header's Content-Type is set to application/x-www-form-urlencoded, it will be serialized into URL-safe string in UTF-8 encoding. Body payloads will vary on the specific probes being requested. For HTTP requests, the body and headers are defined like this:

1 requests:
2   - method: POST
3     url: https://example.com/auth/login
4     timeout: 7000 # in milliseconds
5     saveBody: true
6     headers:
7       Authorization: Bearer __your_token_here__
8     body:
9       username: someusername
10       password: somepassword

You can use responses from previous http requests in the body of your next request, see how requests chaining work in the sections further below. It is also possible to automatically generate data in your payload. See the fake data payload section here.

Content-Type header

Currently, Monika only supports Content-Type value application/x-www-form-urlencoded and application/json with UTF-8 encoding.

Mariadb or MySQL Probes

To monitor the connectivity and the health of your MariaDB database, you can use the following monika configuration:

1 probes:
2   - id: 'id-mariadb'
3     name: maria_probe
4     description: testing maria db
5     mariadb:
6       - host: 172.11.0.1
7         port: 3306
8         database: mydatabase
9         username: myuser
10         password: password

You can also use the mysql keyword for your Mysql database like below. The mariadb and mysql probe types are interchagnable.

1 probes:
2   - id: 'id-mariadb'
3     name: maria_probe
4     description: testing maria db
5     mysql:
6       - host: 172.11.0.1
7         port: 3306
8         database: mydatabase
9         username: myuser
10         password: password

MongoDB Request

You can check if your MongoDB instance is running and accessible by adding a probe with mongo configuration as follows.

1 probes:
2   - id: 'mongo-test'
3     name: MongoDB health check
4     interval: 30 # in seconds
5     mongo:
6       - host: localhost
7         port: 27017

If your MongoDB configuration uses authentication settings, you can pass the username and password field like below:

1 probes:
2   - id: 'mongo-test'
3     name: MongoDB health check
4     interval: 30 # in seconds
5     mongo:
6       - host: localhost
7         port: 28017
8         username: mongoadmin
9         password: secret

If you have a connection URI, you can pass it to the uri field like below:

1 - id: 'mongo-test'
2   name: MongoDB health check
3   interval: 30 # in seconds
4   mongo:
5     - uri: mongodb://mongoadmin:secret@localhost:28017

PING Request

You can send an ICMP echo request to a specific url by specifying a ping probe. In this mode the a PING echo request is sent to the specified url.

1 probes:
2   - id: 'ping_test'
3     name: ping_test
4     description: requesting icmp ping
5     interval: 10 # in seconds
6     ping:
7       - uri: http://google.com

Postgres Request

Monika provides a way to check your postgres database's health with a 'postgres' type probe. You can define the host, port and user and password like this:

1 probes:
2   - id: 'postgres-01'
3     name: database health
4     description: ensure db health
5     interval: 30 # in seconds
6     postgres:
7       - host: 172.15.0.1
8         port: 5432
9         user: user
10         password: password
11         database: mydb

Or alternatively you may provide a postgresql connection URI like below:

1 probes:
2   - id: 'postgres-01'
3     name: database health
4     description: ensure db health
5     interval: 30 # in seconds
6     postgres:
7       - uri: postgresql://user:password@172.15.0.1:5432/mydb

If uri is provided along with host, port, user and password fields, connection will be derived from the uri string and the other fields will be ignored.
Please see the postgres connection specification for details on uri formatting.

Redis Request

You can check if your redis instance is running and accessible by adding a probe with redis configuration as follows.

1 probes:
2   - id: 'redis-test'
3     name: redis health
4     description: requesting redis PONG
5     interval: 30 # in seconds
6     redis:
7       - host: 172.15.0.2
8         port: 6379

If your redis configuration include AUTH settings, you might get some error like Error: NOAUTH Authentication required. You can pass a password field like below:

1 probes:
2   - id: 'redis-ping'
3     name: redis check with password
4     description: requesting redis PONG
5     interval: 30 # in seconds
6     redis:
7       - host: 172.15.0.2
8         port: 6379
9         password: mypassword

You may also add a username property as needed. An alternative format that you can provide is a uri connection string for redis with the following specification redis://[[username][:password]@][host][:port][/db-number]:

1 probes:
2   - id: 'redis-ping'
3     name: redis check with password
4     description: requesting redis PONG
5     interval: 30 # in seconds
6     redis:
7       - uri: 'redis://alice:mypassword@172.15.0.2:6379'

See the full redis client configurations here.

TCP

You can send a TCP request to a specific host and port with data by using the socket field.

1 probes:
2   - id: 'tcp-example'
3     socket:
4       host: localhost
5       port: 3333
6       data: Hello from Monika

Probe Response Anatomy

The default shape of a response when Monika has successfully fetched a request is as the following.

1 status: 200
2 statusText: OK
3 headers:
4   test-header: ...
5 config:
6   url: https://reqres.in/api/users
7   method: GET
8   data:
9     mydata: value
10   headers:
11     Accept: application/json, text/plain, */*
12     User-Agent: axios/0.21.1
13 data: ...

Details of the fields are shown in the table below.

Probe response data could be used for Request Chaining.

Custom HTTP Responses

To make it easier to troubleshoot HTTP requests, we have mapped low-level errors returned by the HTTP library to numbers between 0 and 99. These custom errors are returned as the HTTP status code and can be used to trigger alerts in the same way as regular HTTP status codes.

Execution order

In a configuration with multiple probes, Monika will load the requests in the order that they are entered, one after another. However, probes may be performed out of sequence depending on their interval setting, network latency and response times. By default Monika loops through all the probe configurations in the order they are entered, but you can use the --id or the --repeat flags to specify or repeat a particular sequence. See the cli options here for more information.

In general, Monika will sleep until the next interval timer to repeat a probe. If no interval time is specified for a probe, the default value will be used. If the configured probe interval is shorter than the amount of time to dispatch all the requests, then Monika will immediately repeat after the last response and any notification alerts sent.

Fake Data

You can use fake data to pass through your URLs, request body, and request headers. Here is the list of available fake data:

To use the fake data, all you need to do is to wrap them in the double curly brackets like the example below:

1 probes:
2   - id: '6'
3     name: '6'
4     interval: 10
5     requests:
6       - url: http://github.com?timestamp={{ timestamp }}
7         # This will be rendered as https://github.com?timestamp=1661159139803
8 
9   - id: '15'
10     name: '15'
11     interval: 10
12     requests:
13       - url: http://github.com/user?id={{ uuid }}
14         # This will be rendered as http://github.com/user?id=d8ffd51c-88cd-453e-906e-389b145891e7

If you want to use it as a request body, you can use it like this:

1 probes:
2   - id: '0'
3     name: '0'
4     interval: 10
5     requests:
6       - url: https://httpbin.org/post
7         method: POST
8         body:
9           timestamp: '{{ timestamp }}'
10           id: '{{ uuid }}'
11           # This will be rendered as { timestamp: 1661159139803, id: d8ffd51c-88cd-453e-906e-389b145891e7 }

The same goes for the request headers, you can use it like this:

1 probes:
2   - id: '0'
3     name: '0'
4     interval: 10
5     requests:
6       - url: https://httpbin.org/post
7         method: POST
8         body:
9           timestamp: '{{ timestamp }}'
10           id: '{{ uuid }}'
11         headers:
12           'X-USER-ID': '{{ uuid }}'
13           # This will be rendered as { X-USER-ID: d8ffd51c-88cd-453e-906e-389b145891e7 }

Postman JSON file support

NOTE: We only support Postman collection v2.0 and v2.1 files.

To run monika using a Postman JSON file, use --postman flag as follows:

 monika --postman <path_to_postman_file>

Insomnia file support

Monika supports Insomnia collection file in version 4 format. Both json and yaml files are supported. To run Monika using an Insomnia collection file, use --insomnia flag as follows:

 monika --insomnia <path_to_insomnia_file>

HAR file support

HAR HTTP-Archive format was created by the Web Performance Working Group and has become the standard in browser archive request data definition. To run monika using a HAR file, use --har flag as follows:

 monika --har <path_to_HAR_file>

Further reading

1. Alerts
2. Notifications