wxt9861/esxi_stats

Values don't get updated for a long time / leading to unavailable data in Grafana/InfluxDB

egandro opened this issue · 4 comments

Got this data from Developer Menu

sensor.esxi_datastore_datastore1

name: datastore1
type: vmfs
free_space_gb: 47.41
total_space_gb: 110.25
connected_hosts: 1
virtual_machines: 3
unit_of_measurement: Free (GB)
friendly_name: ESXi datastore datastore1

Last changed: August 27, 2021, 1:22:41 AM
Last updated: August 27, 2021, 1:22:41 AM

The time is now: August 28, 2021, 5:47:24 PM

So the stats wasn't updated for a very very long time. This doesn't put data into my InfluxDB.

Would it be ok for you, if I add a fixed update intervall e.g. 60 sec into this?

I semi "solved" that. It looks like that stats only gets updated when the UI was triggered by a refresh button. So I ended up with a super crap solution :(

  1. Create a shells script on ESXi (that requires SSH + keys set up)

That script creates a 200mb file, waits 2 min, the ESXi Sensor triggers the update, we remove the 200mb file.

We also have to fire up "whatever I found" to trigger that thing, that the UI does on the Reload button. If anybody with more ESXi knowledge knows what to fire, please tell me.

#!/bin/sh
GARBAGE_DIR1=/vmfs/volumes/datastore1
GARBAGE_FILE1=$GARBAGE_DIR1/.garbage-200mb
 
dd if=/dev/zero of=$GARBAGE_FILE1 bs=1024 count=102400 >/dev/null 2>&1
ls -la $GARBAGE_FILE1
du -hs $GARBAGE_FILE1
 
esxcli storage filesystem list
esxcli storage core path list
esxcli storage core device list
esxcli storage nmp device list
vdf
vdu
esxcfg-scsidevs -a
esxcli storage core adapter rescan --all
vmkfstools -V
esxcli storage core device smart get -d t10.ATA_____SAMSUNG_SSD_PMxxx # fix this for your disk
 
sleep 2m
rm -f $GARBAGE_FILE1
 
esxcli storage filesystem list
esxcli storage core path list
esxcli storage core device list
esxcli storage nmp device list
vdf
vdu
esxcfg-scsidevs -a
esxcli storage core adapter rescan --all
vmkfstools -V
esxcli storage core device smart get -d t10.ATA_____SAMSUNG_SSD_PMxxx # fix this for your disk
  1. create a command in HA configuration.yaml
shell_command:
  esxi_datastore_helper: "ssh -i /config/ssh_keys/id_rsa -p 22 -o StrictHostKeyChecking=no root@esxi-whatever-host /vmfs/volumes/datastore1/scripts/noise_for_grafana.sh"
  1. create a HA automation

This runs the command every 5 min.

alias: ESXi Datastore Helper
description: ''
trigger:
  - platform: time_pattern
    minutes: /5
condition: []
action:
  - service: shell_command.esxi_datastore_helper
mode: single

Conclusion: Dirty, ugly hack..

Sorry, I don't understand why you're doing this.

Would it be ok for you, if I add a fixed update intervall e.g. 60 sec into this?

The component already updates every 45 seconds, what other 60 second interval are you looking for?

Last changed: August 27, 2021, 1:22:41 AM
Last updated: August 27, 2021, 1:22:41 AM
The time is now: August 28, 2021, 5:47:24 PM

This is not an error. If your datastore usage did not change, the sensor will not update. This is not driven but the ESXi component, this is a feature of Home Assistant. Home Assistant will not update a sensor whose value or attribute did not change - and why would it? You don't gain anything, instead you end up using more storage by growing your database size having all of that redundant data in there.

It looks like what you did was force a change on the ESXi datastore by writing a 200mb file to it, thus triggering a change in usage and then removing that 200mb file. Given what I said above, I don't really see the point in doing so.

Going back to your original issue - influxDB. I am assuming you're using grafana to make a chart? If so, to solve your problem, you should set fill to previous under the Group By block

image

This way, your chart will keep the previous value where the value is null and update to a new value when a new value is generated.

I semi "solved" that. It looks like that stats only gets updated when the UI was triggered by a refresh button. So I ended up with a super crap solution :(

Sorry - missed this. This could be a bug either in ESXi or pyVmomi SDK. Your solution makes more sense now.

Well I debugged this with lots and lots of debug messages.

ESPi sends back the information - Home Assistand wont save sensor data if they are equivalent to the last update.

What the bad script is doing ... add a significant file... trigger whatever updates the UI in ESXi... your driver picks up that - sends the stat to HA ... then the script is triggered again ... it removes the dummy file ... you driver pics it up and HA triggers the update.

That is stupid. But that's how HA works.