[RFC] Metrics Interface and Aggregation

[lasley]

I included some of this in my recent PR #157, but that was really just so I had some models to connect the billing to. This RFC is to outline what I am thinking on the metrics, gather thoughts, and make sure I'm not missing something that already exists before continuing further.

We have already determined that we will be using the ELK stack to harvest and store our metric data, and that we will simply query the data from our Odoo billing instance(s) when needed. I think this is a good plan because that data is pretty expansive, and most isn't needed.

I do think we will need to in-house some aggregate data snapshots for purposes of billing, however. If we work directly from the live data, it is possible that data could change out from under us and render an inconsistency between metrics billing views and the billing itself.

With that in mind, the following data schema is planned:

• clouder.metric.type - Defines high levels of metric types and the logic necessary for retrieving/aggregating them
• clouder.metric.interface - Glue model to define Clouder Services for billing aggregation via clouder.metric.type.
• clouder.metric.value - Aggregated billing value retrieved for clouder.metric.interfaces. Will also contain start/end dates in order to define aggregation interval

TBD is how we're actually ingesting the metrics, but that is out of scope for this RFC. I'm still planning out the best way for our ElasticConnector.

[lasley]

Elasticsearch connector - OCA/server-tools#645

[rafaelbn]

Maybe not related @lasley but... take a look in https://github.com/camptocamp/odoo-elasticsearch-kibana

[lasley]

Thanks @rafaelbn - I think that's something like what I want to do for bringing Kibana dashboard into Odoo, but I want to eliminate the SQL if at all possible. I added a CRUD interface to base_external_dbsource in OCA/server-tools#642, so I'm hoping to maybe leverage that and allow some sort of object oriented dataset definitions.

@jbeficent pointed me to bi_view_editor, which seems like a pretty good strategy for reporting. Maybe some sort of mixture of the two methodologies.

An interesting feature I just realized of this plan is that if the CRUD interface is integrated into any of the other base_external_dbsource adapters, we would be able to define things in the same way.