Netdata Community

APCUPSD plugin not picking up when in container

Environment

Fedora Linux.
Netdata on host (not Docker)
APCUPSD on Docker

Problem/Question

Hi guys,

I’ve recently moved my APCUPSD to Docker, but it seems that Netdata isn’t picking it up.

Docker-compose:

  apcupsd:
    image: gersilex/apcupsd:v1
    hostname: Apcupsd
    container_name: Apcupsd
    restart: unless-stopped
    network_mode: host
    security_opt:
      - no-new-privileges:true
    ports:
      - "3551:3551"
    privileged: true
    tty: true
    volumes:
      - /tmp/apcupsd-docker:/tmp/apcupsd-docker
      - $USERDIR/APCUPSD/apcupsd.conf:/etc/apcupsd/apcupsd.conf:ro
      - $USERDIR/APCUPSD/doshutdown:/etc/apcupsd/doshutdown:ro
      - $USERDIR/APCUPSD/apcupsd.events:/var/log/apcupsd.events

/etc/netdata/edit-config charts.d/apcupsd.conf (I’ve tried localhost as well instead of IP)

# netdata
# real-time performance and health monitoring, done right!
# (C) 2018 Costa Tsaousis <costa@tsaousis.gr>
# GPL v3+

# add all your APC UPSes in this array - uncomment it too
#declare -A apcupsd_sources=(
#    ["local"]="localhost:3551"
#)
declare -A apcupsd_sources=(
    ["local"]="192.168.0.254:3551"
)

# how long to wait for apcupsd to respond
apcupsd_timeout=3

# the data collection frequency
# if unset, will inherit the netdata update frequency
#apcupsd_update_every=10

# the charts priority on the dashboard
apcupsd_priority=90000

# the number of retries to do in case of failure
# before disabling the module
apcupsd_retries=10

What I expected to happen

For Netdata to pick up the apcupsd data

Hey, welcome to the community :slight_smile:

Can we please verify that the container is exposing the port as expected, meaning that you can access that service from port 3551 on localhost?

Afterward, is it possible to share the error.log ? (see https://learn.netdata.cloud/docs/agent/daemon) .

Don’t worry, we will figure it out :v:

Heya, thank you!

Port seems to be visible on the host with no issues.

Fresh error log:

Looks like it’s trying to find the apcupsd command locally (which it won’t find as it’s not installed on the host, but inside the container itself)

2020-12-16 03:45:12: charts.d: WARNING: apcupsd: command 'apcaccess' is not found in /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/usr/sbin:/usr/local/bin:/usr/local/sbin:/sbin:/usr/sbin:/usr/local/bin:/usr/local/sbin.
2020-12-16 03:45:12: charts.d: ERROR: apcupsd: module's 'apcupsd' check() function reports failure.

This is interesting. I am not sure if this is a feature or a bug, I am inclining towards a feature, meaning that it needs a local apcaccess running which will target the apcupsd sources to retrieve information. Can you please try to install apcaccess on the host machine and then restart netdata?

Heya,

Locally works, but in this case, I’m trying to reduce the amount of things installed locally on the host.

How would Netdata on Docker (as an example) deal with this particular issue, as apcupsd wouldn’t be installed locally on the container, or on a remote apcupsd instance?

I don’t see the reasoning why the plugin asks for an IP address if it only supports a local apcupsd instance?

Although I haven’t used it, it says that it is based on the apaccess program, which is installed with apcupsd. In essence you can use that apaccess to target any host, but you need to have that program installed on the same “host” as netdata, which incidentally means that apcupsd will be installed as well (but not necessarily used).

This seems more logical. Can you try it and report back the results?

So effectively, putting apcupsd into a container will not work with Netdata as it references a host application rather than a remote server?

The aim of this is to not have apcupsd installed on the host itself, but instead in Docker, accessed by the command “docker exec -it apcupsd apcaccess” if it must, but it also has port 3551 open as required for any info to be grabbed.

It seems redundant to require the application installed on the host when all it needs is to grab the same info from the IP address surely? I might be missing the point of the chart in this particular case?