Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[BUG] too many sensors for Docker #320

Open
Erreur32 opened this issue Oct 27, 2024 · 3 comments
Open

[BUG] too many sensors for Docker #320

Erreur32 opened this issue Oct 27, 2024 · 3 comments
Labels
bug Something isn't working

Comments

@Erreur32
Copy link

Erreur32 commented Oct 27, 2024

Go Hass Agent Version
Since v10 with .deb installation

Describe the bug
The number of sensors detected for Docker containers is excessive; I currently have over 3,293 entities.
Firefox_Screenshot_2024-10-27T10-00-52 199Z
This high volume of entities is causing performance issues, as the client/server setup with Home Assistant struggles with the traffic load. My CPU usage spikes significantly whenever all data is pulled.

I have 15 Dockers running, and i guessing a lot entry was generated from Docker sensors.
Example sensor entries:

sensor.machine_br_xxxxxx_bytes_received_throughput
sensor.machine_vethxxxxx_link_state

To Reproduce
Install Docker with go-hass-agent and observe sensor entity counts.

Expected Behavior
It would be ideal to have the ability to disable specific sensors directly from the client (possibly in /preferences.toml) to reduce the load on Home Assistant.

Screenshots
Example of entry
Firefox_Screenshot_2024-10-27T09-42-44 951Z

Desktop (please complete the following information):

  • OS: [Debian 12]
  • Distribution [server no desktop]

For now i have no choice to stop go-hass-agent cause all machine load is to high.

Other missing sensor
I sow some other entry missing since V10. , it is normal ?
distribution_name , distribution_version kernel_version and ** current_users**

@Erreur32 Erreur32 added the bug Something isn't working label Oct 27, 2024
@joshuar
Copy link
Owner

joshuar commented Oct 29, 2024

Hey @Erreur32 that's quite a few sensors!

So regarding the number of sensors:

I'm also running the agent on some machines running Podman, but I don't see nearly as many sensors. Something seems amiss. I have 31 containers running and I only have just over 200 entities total from the agent. Mind you, I do have some containers running in pods, which reduces the number of entities created.

For each network device, I would expect at most 7 entities created:

  • 2 network throughput sensors.
  • 2 network total sensors.
  • 2 ip address sensors.
  • 1 network state sensor.

For Podman, which creates 2 network devices per container for a single running container, that would be about 14 entities. I am unsure that Docker would be creating more. So in your case, the 15 containers with 7 network entities should only generate around 100 network entities, maybe 200 if it does something similar to Podman.

Is it possible some of these sensors are from previous installs of Go Hass Agent? In such a case, they wouldn't be generating sensor updates and should not affect Home Assistant load, other than increasing database storage size. If they are old sensors, the Repairs functionality in Home Assistant should offer to clean them up?

So regarding the ability to disable some sensors:

Yes indeed! This has been requested before (see also #171). I will try to carve out some more time to work out how this can be done. Some of the recent refactoring I've done should make it easier to do.

I don't unfortunately have a current workaround for you sorry! However, I do think it would be worth looking into whether Home Assistant Repairs reports some entities can be removed, which at least will help for display purposes!

@joshuar
Copy link
Owner

joshuar commented Oct 30, 2024

Hey @Erreur32, I've spent some time looking into the ability to filter sensors, and I have something that might be useful. I've merged some code that now allows for exposing user preferences for some sensors, that will add some control to what data they generate.

For example, the code that generates network sensors (bytes received/sent, connection status, addresses) now has a preferences file in which you add some device prefixes that will be matched against devices that should be ignored. In this particular case, the configuration file is located at ~/.config/go-hass-agent/network_sensors_preferences.toml and will have the following content:

  # list of prefixes to match for devices to ignore, for e.g., 'eth' will ignore all devices starting with eth
  ignored_devices = []

You can add devices to ignore to that toml list, for example: ignored_devices = ['br'] would probably work for you to avoid generating sensors for all the bridge devices from your containers.

This will be in the next release of the agent, but if you are keen, you can try it out in the build here. Grab the build-linux-* archive for your required architecture in the artifacts section (scroll down that page), and the archive will contain all packages for that architecture. You need to run the agent at least one time before the preferences file will appear, then shut the agent down, adjust the file and restart for it to pick up your preferences.

If you do try it out, please let me know your feedback!

@Erreur32
Copy link
Author

Erreur32 commented Oct 30, 2024

Thanks a lot for checking that request, sound very good :).
I'll try and let you know soon !

  • Reagrding your first reply, when i disabled sensors from HA , and then restart the machine which have go-hass-agent , it recreate all new sensors each time.

I have redoing all cleaning in HA , and reset + renistall go-hass-agent with your build , change the settings in network_sensors_preferences.toml
ignored_devices = [veth,br-]

And "Voilà" it's working like a charme now :)))
no more bad thousand sensors count ...

you can close this "bug" (i guess not really a bug)
Thanks again

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants