as many others (searched the forum, few requests with different information but all without a solution) I struggle to successfully define an InfluxDB sensor to be used in Home Assistant.
I want to get the current InfluxDB database size of homeassistant .
My query is:
SELECT sum("diskBytes") FROM "_internal".."tsm1_filestore" WHERE time >= now() - 7d AND "database"='homeassistant' GROUP BY time(30s), "database"
What does the sensor definition in my configuration.yaml need to look like?
2) Is looking at the “_internal” database the right way?
I have a dedicated database “homeassistant”:
I think the better approach will be to create a dashboard of that filesize query, visualize it with Grafana and embedd that in Home Assistant. Don´t know nothing bout Grafana yet, I guess for a nice graph it would be sufficient but to get the actual database size as a number to work with in Home Assistant it might not be sufficient.
Also took a look into the folder sensore approach - also does not work because of the docker environment on the HASS OS. And I believe a InfluxDB database is spread over several files (as I can see from the HA snaphots) so it would be not quite accurate.
### shard
The `shard` measurement statistics are related to working with shards in InfluxDB OSS and InfluxDB Enterprise.
#### diskBytes
The size, in bytes, of the shard, including the size of the data directory and the WAL directory.
### tsm1_filestore
The tsm1_filestore measurement statistics are related to the usage of the TSM file store.
#### diskBytes
The size, in bytes, of disk usage by the TSM file store.
My second question is kinda wrong: you´re not looking for the database “_internal” but the retention policy “_internal”, that´s a difference. So:
using your definition gives the whole size used by all databases (_internal, chronograf, homeassistant in my case)
which is fine if InfluxDB is exclusively running for Home Assistant and there are no other use cases/databases on that Influx DB instance
Otherwise (looking at ONE specific database) I think we´d need to specify this in the where: clause by adding something like AND "database"='homeassistant'.
Additionally I excluded this sensor in my general InfluxDB integration part to not have redundant information in the InfluxDB (same information two times with different names - nope, I don´t need that :-))
Alright I double checked the information. The information (value) reported from the sensor definition is very strange. I have absolutely no idea where that value comes from cause it does not match the results given when performing the same SELECT statement on the InfluxDB Admin page.
Sensor gives 54,9 MB
Actual file size is 185 MB [*]
So I can´t use that at all. Tried everything, tested a lot, wasted more than 2 hours on this.
Finally decided to simply not use that purely WRONG piece of information for anything. Therefore I removed that sensor from my .yaml file.
Just a preview on the shard table which gives just some kind of garbage. File sizes should increase constantly and not vary that much, that graph is not useful at all.:
[*] To manually get actual filesize information without using the folder integration:
Made a snapshot, restored the InfluxDB-addon data to my client and checked the size of the data folder - Same can be achieved accessing the influxdb docker container I think, in @tom_l linked thread is the correct “du -sh” command.
I don’t think so. Although it’s one of the easiest way to get at least any InfluxDB database size estimation… still looking for an acurate data source easy to get.
I’m having issues getting accurate data from the sensor. On disk my HA DB is about 120MB according to du -h. Portable full backup is 14MB. Yet in HA the sensor reports 1387.0 MB. What’s going on?
I finally managed to realize this (obviously the need was not that high looking at the amount of time since the OP ).
Basically when using HA OS there needs to be ANY workaround to make this work reliably. The best one with fewest downsides I could find and tend to recommend is using the community SSH addon as tool/information source. Two implementation options: