[ironic] Should we add ironic-prometheus-exporter under Ironic umbrella?
Greetings Ironicers!
I would like to have your input on the matter of moving the ironic-prometheus-exporter to Ironic umbrella.
*What is the ironic-prometheus-exporter? * The ironic-prometheus-exporter[1] provides a way to export hardware sensor data from Ironic project in OpenStack to Prometheus [2]. It's implemented as an oslo-messaging notification driver to get the sensor data and a Flask Application to export the metrics to Prometheus. It can not only be used in metal3-io but also in any OpenStack deployment which includes Ironic service.
*How to ensure the sensor data will follow the Prometheus format?* We are using the prometheus client_python [3] to generate the file with the metrics that come trough the oslo notifier plugin.
*How it will be tested on the gate?* Virtualbmc can't provide sensor data that the actual plugin supports. We would collect sample metrics from the hardware and use it in the unit tests.
Maybe we should discuss this in the next ironic weekly meeting (10th June)?
[1] https://github.com/metal3-io/ironic-prometheus-exporter [2] https://prometheus.io/ [3] https://github.com/prometheus/client_python
Hi Iury,
This seems pretty awesome. I threw in some comments
On Fri, Jun 7, 2019 at 11:08 AM Iury Gregory iurygregory@gmail.com wrote:
Greetings Ironicers!
I would like to have your input on the matter of moving the ironic-prometheus-exporter to Ironic umbrella.
What is the ironic-prometheus-exporter? The ironic-prometheus-exporter[1] provides a way to export hardware sensor data from Ironic project in OpenStack to Prometheus [2]. It's implemented as an oslo-messaging notification driver to get the sensor data and a Flask Application to export the metrics to Prometheus. It can not only be used in metal3-io but also in any OpenStack deployment which includes Ironic service.
This seems really neat. From my perspective, it seems like it waits for notifications, and then writes it out to a file. The flask server seems to do nothing but pretty much serve the contents at /metrics. I think we should be doing more of this inside OpenStack to be honest and this can be really useful in the perspective of operators.
I don't want to complicate this more however, but I would love for this to be a pattern/framework that other projects can adopt.
How to ensure the sensor data will follow the Prometheus format? We are using the prometheus client_python [3] to generate the file with the metrics that come trough the oslo notifier plugin.
How it will be tested on the gate? Virtualbmc can't provide sensor data that the actual plugin supports. We would collect sample metrics from the hardware and use it in the unit tests.
Maybe we should discuss this in the next ironic weekly meeting (10th June)?
[1] https://github.com/metal3-io/ironic-prometheus-exporter [2] https://prometheus.io/ [3] https://github.com/prometheus/client_python
-- Att[]'s Iury Gregory Melo Ferreira MSc in Computer Science at UFCG Part of the puppet-manager-core team in OpenStack Software Engineer at Red Hat Czech Social: https://www.linkedin.com/in/iurygregory E-mail: iurygregory@gmail.com
Hi Mohammed,
Thanks for your feedback =).
Em sex, 7 de jun de 2019 às 19:43, Mohammed Naser mnaser@vexxhost.com escreveu:
Hi Iury,
This seems pretty awesome. I threw in some comments
On Fri, Jun 7, 2019 at 11:08 AM Iury Gregory iurygregory@gmail.com wrote:
Greetings Ironicers!
I would like to have your input on the matter of moving the
ironic-prometheus-exporter to Ironic umbrella.
What is the ironic-prometheus-exporter? The ironic-prometheus-exporter[1] provides a way to export hardware
sensor data from
Ironic project in OpenStack to Prometheus [2]. It's implemented as an
oslo-messaging notification driver to get the sensor data and a Flask Application to export the metrics to Prometheus. It can not only be used in metal3-io but also in any OpenStack deployment which includes Ironic service.
This seems really neat. From my perspective, it seems like it waits for notifications, and then writes it out to a file. The flask server seems to do nothing but pretty much serve the contents at /metrics. I think we should be doing more of this inside OpenStack to be honest and this can be really useful in the perspective of operators.
The notifications are the sensor data of each baremetal node, each node will have a file with the sensor data as metrics in the Prometheus format. Since Prometheus is pull-based the Flask application wlil merge the content of all files to provide to the Prometheus when necessary.
I don't want to complicate this more however, but I would love for this to be a pattern/framework that other projects can adopt.
Agree, maybe we should talk in the IRC how the pattern/framework would look like and this can be done before moving the project or something to be done trough reviews after the project is moved.
How to ensure the sensor data will follow the Prometheus format? We are using the prometheus client_python [3] to generate the file with
the metrics that come trough the oslo notifier plugin.
How it will be tested on the gate? Virtualbmc can't provide sensor data that the actual plugin supports. We
would collect sample metrics from the hardware and use it in the unit tests.
Maybe we should discuss this in the next ironic weekly meeting (10th
June)?
[1] https://github.com/metal3-io/ironic-prometheus-exporter [2] https://prometheus.io/ [3] https://github.com/prometheus/client_python
-- Att[]'s Iury Gregory Melo Ferreira MSc in Computer Science at UFCG Part of the puppet-manager-core team in OpenStack Software Engineer at Red Hat Czech Social: https://www.linkedin.com/in/iurygregory E-mail: iurygregory@gmail.com
-- Mohammed Naser — vexxhost
D. 514-316-8872 D. 800-910-1726 ext. 200 E. mnaser@vexxhost.com W. http://vexxhost.com
participants (2)
-
Iury Gregory
-
Mohammed Naser