prometheus
added exporter
I'm not familiar with this system, is it doing the same thing as the knxd exporter on the line above it? Why is this using the pushgateway rather than being an exporter?
Hi Brian, thanks for your Message. i will try to answer your questions:
I'm not familiar with this system, is it doing the same thing as the knxd exporter on the line above it?
Depends. I was inspired by the present script and tried to solve some of its backdraws and add some helpful features into my implementation.
On the input side it is using the same source (knxtool binary) In addition my solution is fully configurable (via Env-Vars) for the basic configuration - no hard coded values. Also the configuration for the Items attachted to the smarthome bus (like lights or shutters) is externalized, so a user can just insert his own smarthome setup. These features are not present at the knxd exporter on the line above.
My solution is written entirely in Bash not in Perl. Further i am doing data format conversions (1 Bit, 1 Byte and 2 Byte) in the script according to the specification of KNX/EIB - the present Script in the line above is just proxying raw HEX values to the Push Gateway.
Why is this using the pushgateway rather than being an exporter?
I wanted to create an easy solution and got inspired by the present knxd exporter the line above that is also using the push gateway. It was the first time that i worked with prometheus and was surprised how easy u can get super cool results.
Also it is more in the nature of things of these async knx/eib bus events. It is in my opinion a good design, to post the events to the push gateways as they arrive. And let the push gateway be scraped by prometheus.
True, in further sprints i can wrap the script inside a web-server being able to be scraped from prometheus directly. But as i said, the perl script the line above was my inspiration and blueprint for an improved solution.
:) Regards Clem
On the input side it is using the same source (knxtool binary)
It is the same thing then, we should list at most one of these to try and encourage the community working on one solution rather than reinventing the wheel. The current one looks like a one-off which hasn't been touched since though.
to post the events to the push gateways as they arrive.
This sounds like event logging rather than metrics monitoring. Are these really metrics?
On the input side it is using the same source (knxtool binary)
It is the same thing then, we should list at most one of these to try and encourage the community working on one solution rather than reinventing the wheel. The current one looks like a one-off which hasn't been touched since though.
Agree, and thats why i created my own implementation for it. I am not an expert in perl and i saw a lot of problems with the current implementation. And its not fair just judge only based on the input side, as the throughput and the output is completely different (not raw values, enriched with context and transformed, to reflect the reality of KNX/EIB)
to post the events to the push gateways as they arrive.
This sounds like event logging rather than metrics monitoring. Are these really metrics?
Yes, these are pure metrics like the temperature or humidity or the state of a sensor or actor in the smarthome. And its super cool, to see these metrics over time with grafana --> https://raw.githubusercontent.com/clemi2408/Knx2Prometheus/master/img_grafana_dashboard_example.png
With the solution above, this would not be possible that easy, because its based on raw HEX data posted to the push gateway. No one would use a solution like this, because on the one side, the dataformats for float values are special to handle in EIB/KNX and on the other side this will not create value to the user because he will just plot raw HEX data in grafana without meaning.
My question is more, why does this involve the pushgateway at all?
One business driven reason could be:
Imagine the case, that youre operating multiple buildings. Your prometheus stack is running in the cloud. If i use a traditional scenario, all endpoints within the buildings need to be NATed/Firewalled to be accessable from the scraper in the cloud.
With my approach, the customer side is able to push the metrics to the cloud. Without the need of enabling a Firewall.
Regards Clem
For those usecases you can use https://github.com/RobustPerception/PushProx
Guys, what do you want to achieve? If you want to find reasons to reject the PR its your thing. But then just reject :) I just wanted to add my solution to your page. If you're not fine with it, please just reject that PR and dont waste your and my time. You could for sure continue with the already present, outdated and incomplete solution that obviously made it on your list.
Regards Clem
Sorry if that is your feeling.
This page contains exporters that follow our best practices. We always carefully review and comment about the exporters that are added to that page. This is how we work, and by cooperating with the community in that way, we want to help making the ecosystem better.
You can read more about the pushgateway usage here: https://prometheus.io/docs/practices/pushing/ I hope that this page will explain better why we do not accept exporters that push metrics to pushgateway.
Sorry if that is your feeling.
This page contains exporters that follow our best practices. We always carefully review and comment about the exporters that are added to that page. This is how we work, and by cooperating with the community in that way, we want to help making the ecosystem better.
You can read more about the pushgateway usage here: https://prometheus.io/docs/practices/pushing/ I hope that this page will explain better why we do not accept exporters that push metrics to pushgateway.
https://github.com/RichiH/knxd_exporter/blob/master/knxd_exporter.pl check line 20... ...of the "exporter" that made it on your list. Btw. the Page is called "Exporters and integrations"
Regards Clem