Synology NAS monitoring: options and limits

You can monitor a Synology NAS with inping in two ways: a runner checks over HTTP(S) whether it responds, and on models with Container Manager the agent, running as a container, reports CPU, memory, volumes and all containers. inping does not see the state of the RAID and disks; DSM continues to report that.

What does inping see on a NAS and what not?

On a NAS, inping reports vulnerabilities only for projects whose directory with lock files you additionally mount into the agent. How to do that is explained in the guide Monitor Docker containers.

Route 1: check availability

This is the simplest route and works on every model, because nothing has to be installed on the NAS. By default DSM responds on port 5000 (HTTP) and 5001 (HTTPS). Better than the login page is often the service that really matters, such as a website or an application behind the DSM reverse proxy. Add the address to the project and set the expected status code; the default is 200.

The certificate is the most common trap

The runner always checks certificates. A self-signed certificate, which Synology describes as a cause of the browser warning, counts as a TLS error and therefore as an outage. There is no setting to switch the check off. A detour through HTTP does not help either if DSM redirects to HTTPS: the runner follows redirects to the same hostname, and the check again ends at the certificate.

NAS reachable from the internet

If the address has a public name and a valid certificate, for example from Let's Encrypt through the DSM Control Panel, inping's runners check it with no further setup. But do not expose DSM just for monitoring: a login page on the open internet is a greater risk than this check is worth.

NAS on the local network only

inping's runners cannot reach private addresses. For this you need your own runner on the same network: a Linux device with amd64 or arm64, for example a Raspberry Pi. The Free plan includes 1 own runner. If possible do not use the NAS itself for this, otherwise the check fails along with it.

1. Create the runner as a team admin, under Runners → Add runner or in the project under Runners → Add runner. The dialog shows the command with the token. The details are in the installation guide.
2. Allow private networks for the runner. In Docker operation, set INPING_PRIVATE_NETWORKS=true in the .env instead. Then restart the runner.
3. Enter the address as a private IP or with an internal suffix (.lan, .local, .internal, .home.arpa or with no dot), for example http://192.168.1.10:5000/.

# /etc/inping/runner.toml on the device with the runner
private_networks = true

The third rule is important: only such addresses are never handed to inping's runners. A public name that only resolves internally or points to a private IP continues to be checked by them. They then report an error, and because the majority of runners decides, a false outage results.

For such internal addresses only HTTP remains in practice, because a certificate from your own certificate authority cannot be stored in inping. For that, DSM must not redirect the check address to HTTPS (Control Panel → Login Portal → DSM). Whether you want that on your network is your call; the check itself sends no login details.

Note the limit: if the internet connection or the runner fails, no results arrive and the status stays at its last state. There is currently no alert for a silent runner. The agent from route 2 partly closes this gap, because its offline alert is raised by the platform.

Route 2: agent through Container Manager

This route has not been tested by us on this hardware. It uses the normal Docker image of the agent. The connection only goes outwards to inping over port 443, and no port has to be opened on the NAS.

Requirements

• Container Manager. Package Center shows whether your model gets it. It is common on Plus and xs models. Synology's release notes also name individual ARMv8 models such as DS223 and DS420j, as well as DSM 7.2 as a requirement of newer versions.
• Architecture. The image exists for amd64 and arm64. uname -m must output x86_64 or aarch64; 32-bit ARM is not supported.
• SSH under Control Panel → Terminal & SNMP, with an administrator account. The token is passed once on the command line. You can switch SSH off again afterwards.
• An agent in inping. Under Agents → Add agent you get the token, visible once and valid for 24 hours. The image version and digest are in the release notes under /agents/install in the app. The Free plan includes 2 agents.

1. Create the files

In File Station, create the folder /volume1/docker/inping-agent and in it the files docker-compose.yml and agent.toml. Fill in the version and digest and never use a moving tag.

name: inping-agent

services:
  inping-agent:
    image: ghcr.io/medienakzent/inping-agent:<version>@sha256:<digest>
    restart: unless-stopped
    read_only: true
    cap_drop: [ALL]
    security_opt:
      - no-new-privileges:true
    volumes:
      - ./agent.toml:/etc/inping/agent.toml:ro
      - inping-agent-state:/var/lib/inping-agent
      - /proc:/host/proc:ro
      - /sys:/host/sys:ro
      - /:/host/root:ro
    networks: [default, inping]
    depends_on: [inping-docker-proxy]

  inping-docker-proxy:
    image: tecnativa/docker-socket-proxy:0.3.0
    restart: unless-stopped
    environment:
      CONTAINERS: 1
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock:ro
    networks: [inping]

volumes:
  inping-agent-state:

networks:
  inping:
    internal: true

api_url = "https://www.inping.io"
state_dir = "/var/lib/inping-agent"

[docker]
endpoint = "tcp://inping-docker-proxy:2375"
all = true

The configuration deliberately sits in its own file here. Our general template writes it straight into the Compose file, but that needs Compose 2.23.1 or newer, and which version your Container Manager brings only shows in sudo docker-compose version. The file agent.toml contains no secret. all = true reports all containers on the NAS instead of only those of one Compose project.

The socket proxy only lets read access to /containers through, so it protects the host from the agent. But it does allow reading all container data, including the logs. The variant with no proxy at all is described in the installation guide; it is less secure, because the Docker socket has no read-only mode.

2. Register once

Log in over SSH and run the following. The token comes from the dialog in the app.

cd /volume1/docker/inping-agent
chmod a+r agent.toml
echo "<token>" | sudo docker-compose run --rm -T inping-agent register --token -

The agent runs as user 65532 and must be able to read agent.toml, hence the chmod. In shared folders on DSM, additional access rights can apply. The commands use docker-compose because Container Manager ships it. If it is missing, try docker compose.

3. Start the project in Container Manager

Open Container Manager → Project → Create, as Synology describes it. Name the project inping-agent so that it uses the same name and volume as the registration, choose the folder as the path and the existing docker-compose.yml as the source.

The agent should be Online in inping within a minute. The containers appear under Services after two measurements; if necessary, switch the metric on under Settings → Collected metrics. Assign the agent to a project under Agents → (agent) → Settings → Projects so that the project's notification rules apply.

Updates

The agent does not update itself in a container. Enter the new version and the new digest in the docker-compose.yml and run the following:

cd /volume1/docker/inping-agent
sudo docker-compose pull inping-agent
sudo docker-compose up -d inping-agent

When nothing arrives

• The container does not start and reports the configuration: user 65532 cannot read agent.toml. Check the permissions of the file and the folder.
• cannot start: the agent was not registered, or the registration and the project use different volumes. Compare the project name with name: in the file.
• registration failed: the token has expired or has already been used.
• docker source unusable: the proxy cannot be reached. The host values still arrive.
• The values do not match the NAS: one of the host mounts is missing, and the agent then measures only its container. The log names the missing one.
• Kernel older than 5.13: the additional file system lock through Landlock then does not apply, but the agent still runs. The container stays read-only.

What should you monitor on a NAS?

In inping

• The agent's offline alert. It tells you when the NAS or its connection to the internet is gone, without you exposing anything. A DSM update with a restart also triggers it, so choose the number of missed reports accordingly.
• Volume usage. New servers start with the rule "every disk above 90%". For a data volume, a separate, earlier threshold for /volume1 makes sense, because space on a NAS can rarely be extended at short notice. What is reported is the file system, not the free space in the storage pool.
• CPU over a longer period. Backups and RAID scrubbing keep a NAS busy for longer. Extend the time window of the CPU rule if the default of 5 minutes fires too often.
• Services. A stopped container triggers the Service down alert. Add an HTTP check for important applications, because a running container does not tell you that the application responds.

In DSM: RAID and disks

A degraded RAID is the most important event on a NAS, and inping does not see it: the volume stays mounted, the usage unchanged, all values look normal. So set up the following in DSM:

• Notifications by email, push or webhook, and check that the test message arrives.
• S.M.A.R.T. tests in Storage Manager, scheduled as a recurring task.
• For several devices: Active Insight, Synology's cloud service. Check its licence and privacy terms yourself.
• For existing network monitoring: SNMP in DSM, with Synology's MIB files for drives and RAID. SNMP-capable tools take care of that; inping does not query SNMP.

Why not the normal install script?

On a Linux server the install script sets up a service account, files under /etc and an update timer. It is built for common Linux distributions, not for DSM, which Synology maintains as its own appliance. We do not support it there, not even with --user. The container keeps the NAS free of changes and sits entirely in the volume and the project folder.

What does it cost?

Both routes work on the Free plan: 2 agents, 1 own runner and 10 URLs per project, checked as often as every 60 seconds. The other plans are listed under Pricing, further installation routes under Integration.

Frequently asked questions