Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Support pushing all sensors and fix wrong metrics (prometheus). #11159
For example all metrics with unit % match humidity.
Related issue (if applicable): fixes #
Pull request in home-assistant.github.io with documentation (if applicable): home-assistant/home-assistant.github.io#<home-assistant.github.io PR number goes here>
Example entry for
Dec 15, 2017
changed the title from
Support pushing all sensors and fix wrong metrics.
Support pushing all sensors and fix wrong metrics (prometheus).
Dec 15, 2017
Jan 8, 2018
I'd like to object quite strongly to this change, this is not the correct way to solve this problem, it completely messes up statistics and it is not the correct way to deal with statistics in prometheus.
This should have been solved by improving labelling, not creating a hundred new metrics. A much better way to solve this would be to add labels/type to devices in the prometheus configuration. We have gone from a situation where we had a selection of available types in Home Assistant / Prometheus to no longer being able to select and graph a set of devices based on type.
Please revert urgently and if necessary do a complete rewrite of the prometheus component.
No, you do not have a metric per device type. You have a metric per device name. I have for example named my z-wave devices. Consider also that all z-wave devices that I have report energy consumption. They are not all the same type.
Just to make it clear, I don't disagree with the prometheus module being improved. I'm all for that as I'm suffering with the same issue with regards to f.ex. battery % vs humidity %. It can be solved in several ways for the short term by either customizing the unit_of_measurement (thought that will drop it out of prometheus) or you can exclude (using regex if you want) in prometheus when you query.
I imagine a proper fix for the prometheus component would be to be able to create your own metrics and include devices in that.
Though to be fair that will cause a fair amount of manual work. I would have preferred to be able to set a type on all Home Assistant devices which would be useful for more than Prometheus I think.
With the new changes I have adjusted all my queries to work as needed. Rather than selecting by metric name directly and filters further with labels, I am wildcarding the metric names just like any label.
Example for batteried devices:
While I agree with @tcastberg it would be nice to have a type in HA to use for the metric but we don't. Luckily Prometheus doesn't really care if you have a lot of metrics with few labels. Or few metrics with lots of labels. It treats them all the same in the end and queries haven't taken a hit nor has storage.
https://prometheus.io/docs/practices/naming/ - From this, the way before and the new way is not following their recommended practices. In terms of making a full series aggregation meaningful the new way checks that box while the old way didn't at all.
I like the new changes strictly for the fact that I get everything and I can change my query to get what I want. If this is changed to something else that is also fine by me as long we still get all metrics.
But as it stands IMO it's not horrible at all. Yes it is against the recommended prometheus best practices. But like I said, prometheus is smart enough to not actually care in the backend.
I see what you're saying and to be fair I've never had to wildcard the metric so I was not aware of that. I'll downgrade my estimation of it from horrible to ugly. :) I still don't think this is an appropriate way to solve this and I would have preferred to reject this PR to wait for a proper fix.
Please take this discussion in an RFC issue where you can discuss the future of the prometheus integration.
Merged PRs should not be used for discussion or bug reports. If you've found a bug it's ok to make a review with inline comments and link to an issue that reports the bug.