On the Barometer project (FKA SFQM) call today, I made the following suggestion that was welcomed by the team. Basically the Barometer project will be developing the "frontend" (i.e. agent) data source aspects of analytics collection (i.e. interfacing with hosts and VMs etc to collect analytics), and delivering it to "backends" (i.e. collectors such as VIMs/monitoring systems) via protocols such as REST/HTTP, Kafka, SNMP etc. I think this is a good development, as most of the frontend heavy lifting will be done in the collectd upstream, and specific projects in OPNFV such as Barometer and VES just need to take care of the mapping to the backend interfaces and data models.
To minimize development/maintenance of the mapping between the collectd plugin data sources and the specific backend protocol/data model, I suggested that we consider a mapping table as a static or manageable attribute of the configuration for the agent. For example, as you can see in Maryam's team implementation of the ves_plugin.py<https://github.com/maryamtahhan/OpenStackBarcelonaDemo/blob/master/ves_plugin/ves_plugin.py>, values for the data source items are mapped to fields in the JSON-based VES message structure in individual code statements. Even in this early demo version, there are many monitored data items, and this can be expected to expand greatly. It would be nice if we can automate as much of this as possible through a table with rows such as: { plugin_name, plugin_instance, type_name, type_instance }, { domain.property.property.property... } Theoretically, it should be possible in many cases to simply run thru such a table and copy the source data to the proper place in the target event structure. If calculations are needed on the source, they might still require a discrete statement, but many of the fields could be just copied. For target properties which are lists, that would need to be considered as well, but I think we could indicate that through some variable reference or "property[x]". Any input on this idea, experience implementing such mapping systems etc, is appreciated. Thanks, Bryan Sullivan | AT&T
_______________________________________________ opnfv-tech-discuss mailing list opnfv-tech-discuss@lists.opnfv.org https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss
