madjlzz / madprobe

Simple aliveness probes written in Go with ❤️

🤓 Hey. Welcome aboard!

Thanks for joining my page!
I'm Julien, Cloud architect from 🇫🇷 Metz, France, currently working in 🇱🇺 Luxembourg.

Things I code with

OSS projects

🎁 Projects	⭐ Stars	📚 Forks	🛎 Issues	📬 Pull requests
MadProbe
MadProbe CLI
Gopypi
Chaloperie

Where to find me

All credits to Thomas Guibert for his neat blog post on Medium.

---

This README file is generated every 6 hours!
Last refresh: Tuesday, 4 June, 08:22 CEST

madprobe's Issues

Be able to persists probe state

Is your feature request related to a problem? Please describe.
If madprobe is killed, we are unable to restart easily every probe that were running before the shutdown.

Describe the solution you'd like
Use a simple and lightweight database to store probe's state and restart every probe if madprobe has restarted.

New type of probe: PID

Is your feature request related to a problem? Please describe.
This feature is about providing probes a way to check a living PID on a local/remote hostname.

Describe the solution you'd like
Whenever a probed service PID is not existing anymore, the status of the probe should be set to DOWN.
To connect to a remote host, consider using SSH with either username:password and public and private keys.
Also, refactor the existing to allow a more flexible way to implement new probe types.

Provide a simple way to authenticate clients

Is your feature request related to a problem? Please describe.
Actually, there is no security build into the http server to protect calls from unknown people. It would be better to provide a way to secure the service by providing a way to authenticate clients.

Describe the solution you'd like
I thought of using certificate and mTLS to provide an authentication. The server would allow calls only from clients that shared they're public certificate. A manual task is required from someone to add this public certificate to madprobe trustore.
I do not want to complexy to much the security layer by providing too much way to authenticate.
Any other simple solution is welcome!

Additional context
If madprobe has security enable, we should follow this steps to allow a client to connect to talk with madprobe:

• provide madprobe's public certificate
• provide madprobe's private key
• provide a trustore containing each public client certificate we trust

Support TLS for HTTP check requests

Is your feature request related to a problem? Please describe.
If we have a look here, we can see that requests are made only with HTTP.

Describe the solution you'd like
It could be interesting to allow each HTTP probe to define it's own client certificate. We could add a property in the configuration file for each entry to give the path to the public certificate.

e.g:

http:
  - name: simple-https-probe
    url: https://my.loved.api.dev/health
    cert: /etc/ssl/certs/my-loved-api.crt
    delay: 30

Describe alternatives you've considered
As an alternative, we could add a new option when launching the complete probe application.

For example:
$ madprobe -client-cert /path/to/client/cert

should override any defined cert in configuration file for HTTP probes and use the CLI one to configure any of this probes.

Additional context
Wireshark capture to prove that HTTPS is not handled yet.

Write unit tests for prober package

At the moment the project is poorly covered by unit test. This must be fixed before adding new feature so that people can safely rely on the working features of the project.

Support TLS for Webserver

Is your feature request related to a problem? Please describe.
For now, the application is only serving in HTTP. (see http.ListenAndServe)
In order to provide a more secure service, encryption using TLS is recommended.

Describe the solution you'd like
See issue #3. Add new entry to configuration file.

Describe alternatives you've considered
New property server-keyfor TLS server private key and other property server-cert for TLS server public key.

Additional context
N/A

Missing status in GET response

Is your feature request related to a problem? Please describe.
After doing a GET request, we do not retrieve the actual probe status.

Describe the solution you'd like
Return the probe details with a new property "status" saying if the API reached by the probe is "UP" or "DOWN".

Refactor current architecture

For now, the current architecture doesn't allow to create, delete or update probe on the fly. Eveything is loaded when the app boots.

In order to provide a more flexible way of managing probes, a REST API should be exposed that allow basic CRUD operations.

PID probe should work with remote hosts

Is your feature request related to a problem? Please describe.
As we can see here, PID probe only works locally.

Describe the solution you'd like
It could be nice by setting a PID probe like:

pid:
  - name: simple-remote-pid-probe
    hostname: remote.dev
    service-account: madjlzz
    pid: 1
    delay: 30

to connect to the concerned hostname and launch the check from here.
A solution could be to connect with SSH to the given server with the given username if SSH keys are configured on both client and server.
The response should then be visible from the UI.

Describe alternatives you've considered
No alternatives have been considered.

Additional context
No additional context.

Alert clients whenever probed services becomes down.

Is your feature request related to a problem? Please describe.
It could be also interresting to be able to get some notification when probe's service becomes down. It will allow people to gain time by not having to call manually the APIs.

Describe the solution you'd like
Something simple. Whenever a probed service becomes down, send an notification to the configured destination.
Destination can be multiple.
Destination can be thirdparty services like Slack, Discord, SMTP, callbacks, [...]
Also for now, alerting will be disabled by default (to avoid spam) and cannot be turned on/off without restarting entirely madprobe.

Additional context
This issue can be splitted into several: one for each thirdparty we implement. Consider implementing one for this issue. (whatever)