[IMP] monitoring: Prometheus/OpenMetric support

[fkantelberg]

This PR adds an option to configure the output format of the monitoring and adds support for Prometheus which can just fetch the metric file via the controller.

[pedrobaeza]

Thanks for this. It seems interesting. For the commit name, it should be [ADD], not [IMP], and the name should be monitoring_prometheus for letting space to have other tools.

[fkantelberg]

The monitoring module is already there and the PR extends it to support other output formats. (before it was just a JSON format).

[pedrobaeza]

OK, sorry, then it's totally correct. My fault. I didn't see the files changes. Anyway, maybe it makes sense to have it apart in a new module monitor_prometheus. If not, migrators will have to dealt with several formats that may not properly check.

[fkantelberg]

I'll try to explain the current flow of the module:

• You configure different (reusable) snippets (python snippets with a defined result interface) which will run on the database and should return if the system is in an expected state
• You configure monitoring groups where you specify the output format (e.g. JSON, Prometheus) depending on the one which works for you
• It's basically a look into the Odoo for the monitoring BUT not on of the OS/server

How we are currently using it:

• We defined various snippets
  • Monitoring the number of failed queue.job or mails in exception state against a threshold
  • Monitoring the gaps in the invoice numbers because usually something weird happend in these cases
• We defined 2 monitoring groups (one for our older monitoring and one for our prometheus) to fetch the state of the system and alert the responsible users

If you don't need the other formats don't configure them. It's only using/doing what you configure and the only prometheus specific thing is the output format which is hardly enough to split the generic module in my view. It would be something different if you would include a node exporter etc. within the module to get hardware stats through an Odoo but nowadays with dockerized Odoo this should happen directly on the OS level.

[pedrobaeza]

OK, I don't know enough the module. It was just to avoid frictions when a migrator migrates this module containing several things that are difficult to be checked if not having the correct tools.

[fkantelberg]

No worries. I understand the point for migrators. I have to look into the unittests anyways and try to include the output format with some validation there to ease the duty during migration. For the Odoo side it should be generic enough to only depend on the ORM API and be easier portable as long as you can provide the correct snippets during the configuration.

For the migration: 16.0 is trivial. I'll try to open the PR with the migrated version soon too.