Netdata: Installation and Real-Time Node Monitoring

Netdata's selling point is resolution: one second per metric, per node, with hundreds
of charts already built and no configuration required. That same default is its operational
risk — a one-second retention database on a busy server is a real resource commitment, and the
agent listens on port 19999 by default. This article installs it, tunes it, secures it, and
explains the two ways to centralise many agents (a parent node, or Netdata Cloud) so you are
not opening a browser tab per server.

Install

wget -O /tmp/netdata-kickstart.sh https://get.netdata.cloud/kickstart.sh && sh /tmp/netdata-kickstart.sh

The kickstart script detects the distribution and prefers native packages, falling back to a
static build and then to compiling from source. It prompts for four decisions:

• Automatic updates — default enabled. Reasonable, but pin it if you have a change control
  process.
• Release channel — nightly versus stable. Stable for production.
• Anonymous statistics — opt out if your policy requires it.
• Connect to Netdata Cloud — needs a claim token from the Cloud UI
  (Space settings > Nodes > Add node).

# Non-interactive, stable, no anonymous stats
sh /tmp/netdata-kickstart.sh --stable-channel --disable-telemetry --no-updates

# Uninstall later if you change your mind
sh /tmp/netdata-kickstart.sh --uninstall

Verify:

systemctl status netdata
ss -lntp | grep 19999
curl -s http://localhost:19999/api/v1/info | head -20

Secure the Agent Before You Do Anything Else

The default configuration binds to all interfaces and has no authentication. On a server
with a public IP, that is an open metrics endpoint.

# /etc/netdata/netdata.conf  (generate with: /etc/netdata/edit-config netdata.conf)
[web]
    bind to = 127.0.0.1
    # or, for a private management network:
    # bind to = 10.10.50.10

    # If you must expose it, require authentication:
    #   create /etc/netdata/netdata.conf with an [web] section plus
    #   HTTP basic auth via a reverse proxy — see the Traefik / nginx guides

[global]
    run as user = netdata
    memory mode = dbengine
    page cache size = 64
    dbengine multihost disk space = 512

Then restart and confirm the port is no longer externally reachable:

systemctl restart netdata
ss -lntp | grep 19999
curl -sI http://PUBLIC-IP:19999    # should fail

Tune the Retention vs Memory Trade-Off

memory mode = dbengine is the modern backend: it keeps recent data in RAM and
spills to disk. The two numbers that matter are the page cache size and the disk budget.

[global]
    memory mode = dbengine
    page cache size = 128                    # MB of RAM for the cache
    dbengine multihost disk space = 2048     # MB of disk per node
    update every = 1                         # seconds; 2-5 on busy hosts

• On a heavily loaded web or database server, raise update every to 2 or 3. The
  resolution loss is usually invisible and the CPU saving is real.
• Disk retention grows with node count when you run a parent. Budget per child node, not per
  parent.
• Watch netdata.pages_cache and the dbengine chart itself — Netdata
  monitors its own storage behaviour, which is how you know whether your numbers are sane.

Alerts Without a Cloud Account

Netdata ships hundreds of health checks enabled by default, and you review them in the
Alerts tab. To customise, edit the health configuration files rather than the built-in
ones:

/etc/netdata/edit-config health.d/ram.conf

# Example: page on sustained high memory instead of the default threshold
 alarm: ram_in_use_high
    on: system.ram
 lookup: average -5m percentage of used
  every: 1m
   warn: $this > 85
   crit: $this > 95
   info: RAM in use
     to: sysadmin

Confirm your syntax by reloading and watching the log:

systemctl reload netdata
journalctl -u netdata -n 50 | grep -i health

Centralising Many Nodes

Two supported patterns:

• Netdata Cloud — the agent streams to Cloud over an outbound connection, so
  no inbound firewall rule is required. Data stays on the agent; Cloud queries it in
  real-time.
• A parent node — one agent acts as a parent and stores the child nodes'
  data, giving you a single local dashboard with retained history. Configure children with
  stream.conf and a shared API key.

# child: /etc/netdata/stream.conf
[stream]
    enabled = yes
    destination = 10.10.50.10:19999
    api key = 11111111-2222-3333-4444-555555555555

# parent: also needs the same API key defined in stream.conf under that UUID

For a handful of nodes either works. For a large estate, a parent avoids the per-node
dashboard problem and keeps the data inside your network.

Where Netdata Fits

• Use it for — fast interactive troubleshooting at one-second resolution,
  zero-config host metrics, and a per-node dashboard you can open without writing a query.
• Do not use it as your only alerting system. Its strengths are local and
  visual; a fleet-wide alerting strategy built on Prometheus or Zabbix is easier to reason about
  at scale — see Zabbix SNMP switch monitoring with LLD and Alertmanager routing and notification configuration.
• If you already collect logs centrally, keep hosts and logs together:
  Grafana Loki and Promtail log pipeline setup covers the log side.

原文链接：https://learn.netdata.cloud/docs/netdata-agent/installation/linux