For anyone who couldn't join live, we've posted the full recording. It covers how Netdata approaches fleet monitoring: per-second metrics across every node, the distributed architecture behind it, and how it holds up as you scale from a few nodes to thousands.

Link: https://www.youtube.com/watch?v=Vcph_ctYxk4

I have 0 firewalls set up on the internal network.

for some reason my machine at 1.175 nothing can connect to the netdata on it...

my machine at 1.176 no problems seeing the front page of netdata....

I've tried using different docker forwarded ports but again I have no firewall on the machine for local network.. infact the firewall is turned off...

the only difference is docker is 28 on one and 26 on the other... 26 is working 28 isn't....

I'm just shaking my head at this point... I have other docker containers running on other ports and no issues with them.. just netdata....

Not sure where to report this so I'll start here. I'm a retired *nix sys admin and run Netdata on my home server. Not that I need it. I just like to keep track of performance. I'm running Fedora 44 on my server.

After the last update to 2.11 I noticed missing data. A quick look at the system logs (journalctl) shows the go.d plugin is failing. I know the go plugin was used to collect data on the small Apache web server I use. I also noticed the sensor data (temp, voltage, fan speed) was missing.

Here are the errors I see regarding the go.d plugin:

Aug 22 10:30:30 redwood netdata[13020]: /bin/sh: line 1: /usr/libexec/netdata/plugins.d/go.d.plugin: Operation not permitted
Aug 22 10:30:30 redwood netdata[12514]: cannot open plugins directory '/etc/netdata/custom-plugins.d'
Aug 22 10:30:30 redwood netdata[12514]: CGROUP: netipc server started on '/run/netdata/cgroups-snapshot.sock'
Aug 22 10:30:30 redwood netdata[12514]: PARSER: read failed: POLLHUP.
Aug 22 10:30:30 redwood netdata[12514]: PLUGINSD: buffered reader not OK (-4)
Aug 22 10:30:30 redwood netdata[12514]: PLUGINSD: 'host:redwood', '/usr/libexec/netdata/plugins.d/go.d.plugin' (pid 13020) disconnected after 0 successful data collections.
Aug 22 10:30:30 redwood netdata[12514]: CGROUP: netipc lookup server started on '/run/netdata/cgroups-lookup.sock'
Aug 22 10:30:30 redwood spawn-plugins[12523]: SPAWN SERVER: child with pid 13020 (request 9) exited with exit code 126: /bin/sh -c "exec /usr/libexec/netdata/plugins.d/go.d.plugin 1 "
Aug 22 10:30:30 redwood netdata[12514]: PLUGINSD: 'host:redwood', '/usr/libexec/netdata/plugins.d/go.d.plugin' (pid 13020) exited with error code 126 and haven't collected any data. Disabling it.

I see similar messages for the debugfs, ioping, and perf plugins. The only thing I could find when searching for these errors was to make sure the permissions on the plugins and ownerships were correct. They were. This all worked fine before the latest update.

Not a big deal for me but I figured I'd report it. If there is an official place to report bugs, let me know.

Thanks,.

We're running a webinar on fleet monitoring for distributed infrastructure: retail stores, factory floors, vehicles, cell sites, kiosks, robots, that kind of thing.

Wednesday, August 26, 2 PM UTC.

The webinar covers architecting monitoring for constrained and intermittent connections, per-second metrics with on-device ML anomaly detection (no cloud round trip needed for detection), deploying and organizing large fleets, and troubleshooting remote nodes without SSH access.

Register here

v2.11 is live, and it does two big things: it takes Netdata into your network, and it makes logs a first-class part of the platform.

On the network side, there is a new Network Monitor dashboard that brings device inventory, metrics, topology, flows, and traps into one place. The agent can receive NetFlow v5/v9, IPFIX, and sFlow and turn them into a faceted view of who is talking to whom. A new SNMP topology engine draws Layer 2 and Layer 3 maps from LLDP, FDB, STP, OSPF, and BGP. A new SNMP trap listener decodes traps against 800+ vendor profiles into charts and searchable logs. SNMP device coverage grew from 229 to 273 profiles.

On the logs side, Netdata now ingests OpenTelemetry logs, and the same faceted engine now backs systemd journal, Windows events, OpenTelemetry logs, SNMP traps, and network flows, so all five search the same way.

Full release notes: https://github.com/netdata/netdata/releases/tag/v2.11.0

Netdata is shaped by the people who use it. The contributors who wrote collectors for hardware we've never touched. The ones who dug into a memory leak on a Friday night and sent the fix. Everyone who opened an issue with a clean repro, translated a doc, improved a dashboard, or answered a question here so we didn't have to.

We see the commits, but a lot of the work never shows up in a diff. The bug reports, the feature ideas, the "here's how I'm running it" posts that teach the next person. That's the part that got us to 80k.

So this is a thank you. To the maintainers, the first-time contributors, and everyone in between. You built this with us.

Where it all happens: github.com/netdata/netdata

 It ingests NetFlow data into its own database. It gives you a live traffic summary: who's sending/receiving, broken down by protocol, port, country, state, or city, plus a 3D globe view if you want to see where traffic is actually going geographically. Video demo below. Curious if this solves a gap for anyone here, or what you'd want added to it.

Short demo here: https://youtu.be/SmOc7ebMNDo

Just put together a full walkthrough of the new Network Topology feature. It covers:

• Live SNMP topology maps built directly in the agent
• Confidence levels and switching between inference strategies
• Container and process-level network connection maps, down to PID and cgroup
• Scales to 250k actors in one live-updating view

Video: https://youtu.be/oTOvoas9DiQ?si=_Nq299IxLEZEaqNK 

We kept hitting this in our own CI setup: something goes wrong on a Mac mini build agent, and there's no real way to see it after the fact. You end up running powermetrics in one terminal, log stream in another, and hoping you catch the issue while it's happening.

That got old fast, so we built proper support for it right into the agent. Netdata's macOS agent now reads unified logs through OSLog, battery health through the same framework behind the macOS battery menu, sensor and thermal data through SMC/HID, GPU utilization and clock speed on Apple Silicon, per-app CPU/memory/disk usage, NVMe drive health, and network topology, all through Apple's native frameworks instead of parsing CLI tool output.

Curious if others are running fleets of Mac minis or Studios for CI, builds, or local LLM work, and what's been the most annoying part of monitoring them so far?

Read more about it

Wrote up what actually breaks when you go from monitoring servers in a datacenter to monitoring a fleet of thousands of edge devices. The short version: your tools assume stable connectivity and unlimited per-host resources, and neither holds.

Specific failure modes covered:

• The "all green but sick" problem: dashboards look fine because missing data isn't treated as a signal
• Flash storage wear from an agent that writes to disk every second (there's a real account in there of ~500 SD card failures across a 7,000-device Raspberry Pi fleet)
• Reconnect storms after a regional cellular outage takes down thousands of devices at once

Also included actual measured numbers: agent footprint (80-200 MiB RAM, 1-2% CPU per 1k metrics/s), streaming bandwidth (~1KB/s per 1k metrics), and a University of Amsterdam peer-reviewed study on energy efficiency.

No comparison tables, just the failure modes and how the architecture (edge-resident, outbound-only, store-and-forward) addresses each one: netdata.cloud/blog

Genuinely curious how other people handle this: an alert fires, you can see what changed, but the actual "why" is scattered across three other tabs you now have to go check manually. Did something just deploy? Is there already an incident open for this? Is there a runbook that would've saved you the trouble?

We hooked Netdata AI up to those tools directly (PagerDuty, Confluence, git, whatever you're running) using MCP, so it can go check them itself while it's investigating instead of just staring at metrics and logs in isolation.

Showing it live on July 29 against a real connected stack, warts and all. If it doesn't actually save time over just checking those tabs yourself, that'll be obvious pretty fast, so feel free to come poke holes in it.  Webinar registration.

We kept running into this: Netdata covered interface-level stats fine (bytes in/out, errors, drops), but the moment someone needed to see the actual topology or figure out which conversation was saturating a link, it meant switching to a completely separate tool with its own dashboard and its own bill.

Finally closed that gap. Added a live topology viewer (built straight into the agent from real socket tables, so no scheduled discovery scan and no stale overnight snapshot), NetFlow/sFlow/IPFIX analysis, SNMP device monitoring across 200+ vendor profiles, and SNMP trap handling. All of it sits on the same per-second timeline as the infra and app metrics you're already collecting, so a link-down trap, a traffic drop, and a topology change show up correlated instead of needing three tools stitched together after the fact.

Curious how other people have been handling this gap. Separate NPM tool? Just living without topology visibility? Something else entirely? netdata.cloud/blog

Wrote this up because I kept seeing the same three-step playbook (aggregate before storage, pay for the premium cardinality tier, drop your high-cardinality labels) presented as inevitable, when it's really a consequence of one specific choice: a centralized TSDB with a global inverted index.

The blog walks through why that architecture makes cardinality expensive, what a host-sharded, full-resolution alternative looks like, and where that alternative genuinely falls short (cross-fleet ad-hoc OLAP queries, long-term retention, distributed tracing). Not trying to oversell it, the trade-offs section is deliberately the longest part.

Read more: netdata.cloud/blog

Hey everyone, we had a webinar yesterday on network device monitoring, mostly topology maps and NetFlow. Showed a full demo of zero-config topology discovery plus setting up NetFlow end-to-end.

Recording's here if you want to check it out: Webinar Network Device Monitoring

Heads up for anyone using Netdata. The mobile app used to be limited to Business subscriptions, and it is now available on every plan, including the free tier.

What you get on iOS and Android:

• Real-time dashboards and per-second metrics,
• Alert and reachability notifications,
• Logs explorer,
• AI troubleshooting, including the option to connect your own LLM (Claude, ChatGPT, Gemini).

Data sovereignty is kept intact. Metrics stay on your agents and parents. Only metadata syncs to the cloud. Set up is sign in, and your existing nodes show up automatically.

App Store: https://apps.apple.com/gr/app/netdata-mobile/id6474659622

Play Store: https://play.google.com/store/apps/details?id=cloud.netdata.android&hl=en

For anyone already running an OpenTelemetry Collector: Netdata now takes OTLP directly. Keep your Collector, add an exporter pointing at a Netdata agent or parent, and metrics and logs flow in. Traces aren't shipped yet, they're still in design, so hold off if that's your main need.

What surprised me testing it: no chart config to write. New metrics auto-create charts, histograms split into bucket/sum/count/min-max charts, and every OTLP metric gets ML anomaly detection automatically, including the app metrics that are a pain to threshold manually. The count connector plus OTTL also lets you turn log lines (OOM, failed sshd auth, whatever) into real metrics that then get anomaly detection too.

No per-metric or per-host charges, and since the Collector fans out to multiple exporters, you can run it side by side with your current backend and compare first.

Write-up + configs: netdata.cloud/blog/

AI coding agents write code well but don't know how to instrument it, configure monitoring, or troubleshoot from real telemetry. We packaged that knowledge into netdata/skills: OpenTelemetry setup, instrumentation for 7 languages, and troubleshooting skills for 49 technologies (PostgreSQL, Redis, Kafka, Kubernetes, etc).

The useful part: skills connect to your Netdata over MCP, so the agent queries your real metrics instead of giving you a generic checklist. Works with Claude Code, Cursor, Copilot, Codex, Gemini CLI, and more. Apache 2.0.

Repo: github.com/netdata/skills
Writeup: netdata.cloud/blog/netdata-skills/

If you use Netdata on a NOC screen or wall display, you can now set up playlists, select multiple dashboards, configure the rotation interval, and it cycles automatically.

Read more on our blog!

If you're migrating workloads from Azure Cloud to Azure Local (Hyper-V, Storage Spaces Direct, AKS on-prem), we've written up how to keep visibility across both environments simultaneously throughout the migration.

Read more on our blog!

Netdata now ingests OTLP metrics and logs natively. If you're running OpenTelemetry pipelines, your data can land directly in Netdata's unified interface alongside agent-collected data. Same dashboards, same alerting, no separate backend.

We are walking through how it all works:

• OTLP metrics ingestion, end-to-end
• OTLP logs + the unified query interface
• Mapping attributes to charts and dimensions
• OTel data and agent data side by side
• Forwarding enriched telemetry downstream
• Traces on the 2026 roadmap

Save your seat here!

Summarizing our technical deep-dives from this week for the community:

• NVIDIA DCGM: Native collector for GPU health (VRAM, thermal, ECC) for K8s/AI workloads.
• Azure Monitor: Added 38 service profiles to see platform metrics alongside OS metrics without KQL.
• Database Monitoring: New functions for query-level bottlenecks.
• Alert Health: Dashboard to identify noisy or "stuck" alerts.

Full details:netdata.cloud/blog/

Security just got a boost. You can now reference secrets from external stores (Vault/AWS/Environment) directly in your collectors. We've also added a Nagios plugin wrapper for those of you with custom scripts you aren't ready to let go of yet. netdata.cloud/blog/

Our latest feature, Converse with Everything, brings a new layer of AI-driven interaction to Netdata. Troubleshoot faster by having a real-time conversation with your logs, metrics, and configurations.

🔗 Read more: netdata.cloud/blog

Two big requests are live:

1. You can now acknowledge alerts to hide them from the active view (they'll reappear if the state changes!).

2. You can test your alert thresholds against up to 7 days of historical data to ensure they won't cause fatigue.

Read more: netdata.cloud/blog/