| 1 | # Welcome to Netdata |
| 2 | |
| 3 | ## Who we are |
| 4 | |
| 5 | Netdata is a distributed, real-time observability platform that monitors metrics and logs from systems and applications, built on a foundation designed to seamlessly extend to distributed tracing. It collects data at per-second granularity, stores it at (or as close to) the edge where it's generated, provides automated dashboards, machine learning anomaly detection, and AI-powered analysis without requiring configuration or specialized skills. |
| 6 | |
| 7 | Instead of centralizing the data, Netdata **distributes the monitoring code** to each system, **keeping data local** while providing **unified access**. This architecture enables **linear scaling** to millions of metrics per second and terabytes of logs, **automated root cause analysis**, faster UX and significantly **lower total cost of ownership**. |
| 8 | |
| 9 | We have designed this platform for operations teams, sysadmins, DevOps engineers, and SREs who need comprehensive real-time, low-latency visibility into their infrastructure and applications. Netdata is opinionated — it collects everything, visualizes everything, runs machine learning anomaly detection on everything, with several innovations that make modern observability accessible to lean teams, without the need for specialized skills. |
| 10 | |
| 11 | The system consists of three components: |
| 12 | |
| 13 | - [**Netdata Agent**](/docs/deployment-guides/standalone-deployment.md): Monitoring software installed on each system |
| 14 | - [**Netdata Parents**](/docs/deployment-guides/deployment-with-centralization-points.md): Optional centralization points for aggregating data from multiple agents (Netdata Parents are the same software component as Netdata Agents, configured as Parents) |
| 15 | - [**Netdata Cloud**](/docs/netdata-cloud/README.md): A smart control plane for unifying multiple independent Netdata Agents and Parents, providing horizontal scalability, role based access control, access from anywhere, centralized alerts notifications, team collaboration, AI insights, and more. |
| 16 | |
| 17 | The following diagram shows how Netdata components connect: |
| 18 | |
| 19 | ```mermaid |
| 20 | flowchart TB |
| 21 | C1("Child Agent 1") |
| 22 | C2("Child Agent 2") |
| 23 | C3("Child Agent 3") |
| 24 | |
| 25 | P1("**Parent 1**") |
| 26 | P2("**Parent 2**") |
| 27 | |
| 28 | NC("**Netdata Cloud**<br/>Dashboards, Alerts, AI") |
| 29 | |
| 30 | C1 -->|streaming| P1 |
| 31 | C2 -->|streaming| P1 |
| 32 | C3 -->|streaming| P2 |
| 33 | C2 -.->|failover| P2 |
| 34 | P1 <-->|replication| P2 |
| 35 | P1 <-->|ACLK| NC |
| 36 | P2 <-->|ACLK| NC |
| 37 | |
| 38 | classDef child fill: #e8f5e8, stroke: #27ae60, stroke-width: 2px, color: #2c3e50, rx: 10, ry: 10 |
| 39 | classDef parent fill: #f3e8ff, stroke: #9b59b6, stroke-width: 2px, color: #2c3e50, rx: 10, ry: 10 |
| 40 | classDef cloud fill: #e8f4fd, stroke: #4a90e2, stroke-width: 2px, color: #2c3e50, rx: 10, ry: 10 |
| 41 | |
| 42 | class C1 child |
| 43 | class C2 child |
| 44 | class C3 child |
| 45 | class P1 parent |
| 46 | class P2 parent |
| 47 | class NC cloud |
| 48 | ``` |
| 49 | |
| 50 | ## Performance at a Glance |
| 51 | |
| 52 | | Aspect | Netdata | Industry Standard | |
| 53 | |----------------------------:|:----------------------------------------:|:-------------------------:| |
| 54 | | **Real-Time Monitoring** | | | |
| 55 | | Data granularity | 1 second | 10-60 seconds | |
| 56 | | Collection to visualization | 1 second | 30+ seconds | |
| 57 | | Time to first dashboard | 10 seconds | Hours to days | |
| 58 | | **Automation** | | | |
| 59 | | Configuration required | Minimal to none | Extensive | |
| 60 | | ML anomaly detection | All metrics automatically | Selected metrics manually | |
| 61 | | Pre-configured alerts | 400+ out of the box | Build from scratch | |
| 62 | | **Efficiency** | | | |
| 63 | | Storage per metric | 0.6 bytes/sample | 2-16 bytes/sample | |
| 64 | | Agent CPU usage | 5% single core | 10-30% single core | |
| 65 | | Scalability | Linear, unlimited | Exponential complexity | |
| 66 | | **Coverage** | | | |
| 67 | | Metrics collected | Everything available | Manually selected | |
| 68 | | Built-in collectors | 800+ integrations | Basic system metrics | |
| 69 | | Hardware monitoring | Comprehensive | Limited or none | |
| 70 | | Live monitoring | processes, network connections, and more | Limited or none | |
| 71 | |
| 72 | ## Design Philosophy and Implementation |
| 73 | |
| 74 | ### Data at the Edge |
| 75 | |
| 76 | :::note |
| 77 | |
| 78 | Netdata keeps the observability data at the edge (Netdata Agents), or as close to the edge as possible (Netdata Parents). |
| 79 | |
| 80 | ::: |
| 81 | |
| 82 | :::tip |
| 83 | |
| 84 | Keeping data at the edge eliminates egress charges, ensures compliance by default, and transforms observability from an unpredictable cost center into a fixed operational expense while delivering sub-second query performance. |
| 85 | |
| 86 | ::: |
| 87 | |
| 88 | **Implementation**: Each Netdata Agent is a complete monitoring system with collection, storage, query engine, visualization, machine learning, and alerting. This isn't just an agent that ships data elsewhere — it's a full observability stack. The distributed architecture provides: |
| 89 | |
| 90 | - **Data sovereignty**: Data is always stored on-premises and only leaves the servers when viewed. This ensures compliance with GDPR, HIPAA, and regional data residency requirements. |
| 91 | - **Linear scalability**: Adding more Netdata Agents and Parents does not affect the existing ones. |
| 92 | - **Monitoring in isolation**: Observability works even when internet connectivity faces difficulties. |
| 93 | - **Universal capture**: All observability data exposed by systems and applications are important and are collected, enriching the views and the depth of the possible analysis available. |
| 94 | - **High-fidelity insights**: High-resolution (per-second) data capture the micro world at which our infrastructures operate, surfacing the breadth and pulse of our applications and the sequence of cascading effects. |
| 95 | |
| 96 | ### Complete Coverage |
| 97 | |
| 98 | :::note |
| 99 | |
| 100 | Most observability solutions are usually selective to control cost, complexity and the time and skills required to set up. Organizations are frequently instructed to select only what is important for them, based on their understanding and needs. |
| 101 | |
| 102 | This creates two fundamental problems: |
| 103 | |
| 104 | - missing just one uncollected metric can obscure the root cause of an issue, leading to frustration and incomplete visibility during crisis |
| 105 | - the observability quality organizations get reflects the skills and experience of their people. |
| 106 | |
| 107 | ::: |
| 108 | |
| 109 | Netdata's design allows it to capture everything exposed by systems and applications — every metric, every log entry, every piece of telemetry available. |
| 110 | |
| 111 | The comprehensive approach ensures: |
| 112 | |
| 113 | - **No blind spots**: The metric you didn't know to monitor is already collected and visualized. |
| 114 | - **Skill-independent quality**: Junior and senior engineers get the same comprehensive visibility. |
| 115 | - **Crisis-ready coverage**: When incidents occur, all relevant data is available. |
| 116 | - **Full context for AI**: Machine learning and AI assistants have complete data to identify patterns and correlations. |
| 117 | |
| 118 | ### Real-Time, Low-Latency Visibility |
| 119 | |
| 120 | :::note |
| 121 | |
| 122 | Most observability solutions collect data every 10-60 seconds with additional pipeline delays of seconds to minutes, making them statistical analysis tools rather than real-time monitoring. This forces engineers to SSH into servers for accurate, timely data during incidents. |
| 123 | |
| 124 | ::: |
| 125 | |
| 126 | Netdata collects everything per-second and has a fixed one-second data collection to visualization latency. Netdata works on a beat. Every sample needs to be collected on time. Delays in data collection indicate that the monitored component or application is under stress, and Netdata shows gaps on the charts. This strict real-time approach delivers: |
| 127 | |
| 128 | - **True real-time visibility**: See what's happening now, not what happened 30 seconds ago. |
| 129 | - **Console-quality precision**: No need to SSH into servers for real-time data during incidents. |
| 130 | - **Stress detection**: Gaps in charts immediately reveal when systems and applications are under stress. |
| 131 | - **Accurate sequencing**: Understand the exact order of cascading failures across systems. |
| 132 | - **Live troubleshooting**: Watch the immediate impact of your changes as you make them. |
| 133 | - **Tools consolidation**: Use a single uniform and universal dashboard for all systems and applications. |
| 134 | |
| 135 | ### Data Accessibility |
| 136 | |
| 137 | :::note |
| 138 | |
| 139 | Most observability solutions require users to learn query languages, manually build dashboards, and understand metric types before they can visualize data. This prerequisite knowledge and configuration work becomes the biggest barrier to effective monitoring. |
| 140 | |
| 141 | ::: |
| 142 | |
| 143 | Most of our infrastructure components are common: operating systems, databases, web servers, message brokers, containers, storage devices, network devices, and so on. We all use the same finite set of components, plus a few custom applications. |
| 144 | |
| 145 | Netdata dashboards are an algorithm, not a configuration. Each Netdata chart is a full analytical tool, offering a 360° view of data and its sources. With simple point-and-click, you can slice and dice any dataset, gaining a clear picture of what’s available and where it comes from. Netdata provides single-node, multi-node, and infrastructure level dashboards automatically. All metrics are organized in a meaningful manner with a universal table of contents that dynamically adapts to the data available, providing instant access to every metric. This approach delivers: |
| 146 | |
| 147 | - **Zero learning curve**: No query languages, no manual dashboard building, no configuration. |
| 148 | - **Instant time to value**: Complete visibility from the moment of installation. |
| 149 | - **Universal navigation**: The same logical structure across all organizations and infrastructures. |
| 150 | - **Interactive exploration**: Point-and-click analysis without knowing metric names or data types. |
| 151 | - **Skill democratization**: Everyone from junior to senior engineers gets the same powerful tools. |
| 152 | |
| 153 | ### Efficient Storage |
| 154 | |
| 155 | Netdata, contrary to most observability solutions, is optimized for lightweight storage operations. Three storage tiers are updated in parallel (per-second, per-minute, per-hour). The high-resolution tier needs 0.6 bytes per sample on disk (Gorilla compression + ZSTD). The lower resolution tiers need 6-bytes and 18-bytes per sample respectively and maintain the ability to provide the same min, max, average and anomaly rate the high-resolution tier provides. Data are written in append-only files and are never reorganized on disk (Write Once Read Many - WORM). Writes are spread evenly over time. Netdata Agents write at 5 KiB/s, Netdata Parents aggregating 1M metrics/s write at 1MiB/s across all tiers. |
| 156 | |
| 157 | Netdata implements a custom time-series database optimized for the specific patterns of system metrics: |
| 158 | |
| 159 | - **Write-once design**: Append-only architecture for maximum performance |
| 160 | - **Multi-tier storage**: Three storage tiers of different resolution, updated in parallel |
| 161 | - **Zero maintenance**: No recompaction or database maintenance windows |
| 162 | |
| 163 | This efficient storage architecture delivers years of data in gigabytes rather than terabytes, with predictable I/O patterns and linear scaling of storage requirements with infrastructure size. |
| 164 | |
| 165 | ### Logs Management |
| 166 | |
| 167 | :::info |
| 168 | |
| 169 | Log management has become one of the largest cost drivers in observability, with organizations spending millions on storage and processing infrastructure. Many resort to aggressive filtering and sampling just to make costs manageable, inevitably losing critical information when they need it most. |
| 170 | |
| 171 | ::: |
| 172 | |
| 173 | Netdata takes a fundamentally different approach by leveraging the systemd journal format, the native logs format on Linux systems. This edge-based approach provides enterprise-grade capabilities without the enterprise costs: |
| 174 | |
| 175 | - **Direct file access**: No query servers needed — clients open journal files directly, leveraging OS disk cache for fast performance |
| 176 | - **Comprehensive indexing**: Every field in every log entry is automatically indexed, enabling instant queries across millions of entries |
| 177 | - **Flexible schema**: Each log entry can have its own unique set of fields and values, all fully indexed and searchable |
| 178 | - **Efficient storage**: Journal files typically match uncompressed text log sizes while providing full indexing — a balance between space efficiency and query performance |
| 179 | - **Native tooling**: Built-in support for centralization, filtering, exporting, and integration with existing pipelines |
| 180 | - **Security built-in**: Write Once Read Many (WORM) and Forward Secure Sealing (FSS) ensures log integrity and tamper detection |
| 181 | - **Logs transformation**: The platform includes `log2journal` for converting any text, JSON, or logfmt logs into structured journal entries |
| 182 | |
| 183 | Where traditional solutions sample 5,000 log entries to generate field statistics on their dashboards, Netdata starts sampling at 1 million entries, providing 200x more accurate insights into log patterns. |
| 184 | The result is enterprise-grade log management capabilities — field statistics, histogram breakdowns, full-text search, time-based filtering — all while keeping logs at the edge where they're generated, eliminating the massive costs of centralized log infrastructure. |
| 185 | |
| 186 | :::note |
| 187 | |
| 188 | On Windows Netdata queries Windows Event Logs (WEL), Event Tracing for Windows (ETW) and TraceLogging (TL) via the Event Log. |
| 189 | |
| 190 | ::: |
| 191 | |
| 192 | ### AI and Machine Learning |
| 193 | |
| 194 | ML is the simplest way to model the behavior of our systems and applications. When done properly, ML can reliably detect anomalies, surface correlations between components and applications, provide valuable information about cascading effects under crisis, identify the blast radius of issues and even detect infrastructure level issues independently of the configured alerts. |
| 195 | |
| 196 | Netdata democratizes ML and AI by making it automatic and universal (no configuration is required). The system trains 18 k-means models per metric using different time windows, requiring unanimous agreement before flagging anomalies. This achieves a false positive rate of 10^-36 (1% per model ^ 18 models) while remaining sensitive to real issues: |
| 197 | |
| 198 | - **Continuous training**: Models train automatically as data arrives |
| 199 | - **Real-time detection**: Anomaly detection runs instantly, not in batches |
| 200 | - **Efficient storage**: Results store in just 1 bit per metric per second |
| 201 | - **Correlation analysis**: Engine identifies related anomalies across metrics |
| 202 | - **Unbiased detection**: Anomaly detection is not influenced by future events |
| 203 | |
| 204 | Note: Netdata's ML focuses on detecting behavioral anomalies in metrics using their last 2 days of data. It is optimized for reliability rather than sensitivity and may miss slow (over days/weeks) infrastructure degradation or certain types of long-term anomalies (weekly, monthly, etc.). However, it typically detects most types of abnormal behavior that break services. |
| 205 | |
| 206 | For more information see [Netdata's ML Accuracy, Reliability and Sensitivity](/docs/ml-ai/ml-anomaly-detection/ml-anomaly-detection.md). |
| 207 | |
| 208 | ### Troubleshooting |
| 209 | |
| 210 | Netdata introduces a significant shift to the troubleshooting process utilizing its unsupervised and real-time anomaly detection system. The "Anomaly Advisor" transforms troubleshooting: |
| 211 | |
| 212 | - **Automatic scoring**: Ranks all metrics by anomaly severity within any time window |
| 213 | - **Root cause prioritization**: Surfaces the most likely culprits in the first 30-50 metrics |
| 214 | - **Sequence analysis**: Reveals the order of cascading failures across systems |
| 215 | - **Blast radius mapping**: Determines the full impact scope of incidents |
| 216 | - **AI-ready insights**: Provides structured data that AI assistants use to narrow investigations |
| 217 | |
| 218 | This approach still requires interpretation skills but dramatically simplifies the investigation process compared to traditional methods (the aha! moment is within the first 30-50 results). |
| 219 | |
| 220 | ### Alerts |
| 221 | |
| 222 | :::note |
| 223 | |
| 224 | Most monitoring solutions focus on aggregate metrics and business-level alerts, often missing component failures until they cascade into service outages. This approach leads to alert fatigue from false positives and missed issues from incomplete coverage. |
| 225 | |
| 226 | ::: |
| 227 | |
| 228 | Netdata takes a fundamentally different approach: templated alerts that monitor individual component and application instances. Each alert watches a single instance, building a comprehensive safety net where every component has its own watchdog. This granular approach ensures: |
| 229 | |
| 230 | - **Complete coverage**: Every database, web server, container, and service instance has dedicated monitoring |
| 231 | - **Early detection**: Component failures are caught before they cascade into service-wide issues |
| 232 | - **Clear accountability**: Alerts identify exactly which instance is failing, not just that "something is wrong" |
| 233 | - **Scalable alerting**: Templates automatically apply to new instances as infrastructure grows |
| 234 | - **Synthetic checks**: Lightweight integration tests that validate connectivity and behavior between applications complement component monitoring |
| 235 | |
| 236 | :::tip |
| 237 | |
| 238 | Netdata ships with hundreds of pre-configured alerts, many intentionally silent by default. These silent alerts monitor important but non-critical conditions that should be reviewed but shouldn't wake engineers at 3am. This pragmatic approach balances comprehensive monitoring with operational sanity. |
| 239 | |
| 240 | ::: |
| 241 | |
| 242 | ### Scalability |
| 243 | |
| 244 | For Netdata, scalability is inherent to the architecture, not an add-on. Designed to be fully distributed, Netdata achieves linear scalability through: |
| 245 | |
| 246 | - **Independent operation**: Each Agent and Parent operates autonomously without affecting others. |
| 247 | - **Horizontal scaling**: Add more Parents to handle more Agents without redesigning architecture. |
| 248 | - **Consistent performance**: Query response times remain the same whether you have 10 or 10,000 nodes. |
| 249 | - **Resource predictability**: Resource usage scales linearly with infrastructure size. |
| 250 | - **High availability**: Streaming and replication provide high-availability to Netdata deployments. |
| 251 | - **Clustering**: Netdata Parents can be clustered to replicate all their data locally, or cross region for disaster recovery. |
| 252 | - **Fail-over**: Netdata Cloud dynamically routes queries to Netdata Parents and Agents based on their availability. |
| 253 | |
| 254 | ### Open Ecosystem |
| 255 | |
| 256 | Netdata thrives as part of a vibrant open-source community with 1.5 million downloads per day. The platform integrates seamlessly with existing tools and standards: |
| 257 | |
| 258 | - **Metrics collection**: Ingests metrics via all open standards (OpenTelemetry in final release stage) |
| 259 | - **Metrics export**: Exports metrics to all open standards and commonly used time-series databases (Prometheus, Graphite, InfluxDB, OpenTSDB, and more) |
| 260 | - **Logs**: Uses battle tested systemd journal files for storing logs, providing maximum interoperability |
| 261 | - **Alert routing**: Delivers notifications to PagerDuty, Slack, email, webhooks, and 20+ platforms |
| 262 | - **AI integration**: Supports AI assistants via Model Context Protocol (MCP) — available via Netdata Cloud (infrastructure-wide) and on every Agent/Parent (local access) |
| 263 | - **Visualization**: Works with Grafana through native datasource plugin |
| 264 | - **Container orchestration**: Integrates with Kubernetes, Docker Swarm, and Nomad |
| 265 | |
| 266 | Netdata can operate independently or alongside your existing observability stack. Whether you use Prometheus, Grafana, OpenTelemetry, or centralized log aggregators, Netdata enhances visibility without disrupting existing workflows. |
| 267 | |
| 268 | ## Working with Netdata |
| 269 | |
| 270 | Typically, organizations deploying Netdata need to: |
| 271 | |
| 272 | 1. **Install Netdata Agents** on all Linux, Windows, FreeBSD and macOS physical servers and VMs |
| 273 | 2. Optionally: dedicate resources (VMs, storage) for Netdata Parents, providing high-availability and longer retention to observability data |
| 274 | 3. Optionally: configure logs transformation with `log2journal` and centralization using typical systemd-journald methodologies |
| 275 | 4. **Configure collectors** that need credentials to access protected applications (databases, message brokers, etc.), data collection for custom applications, enable SNMP discovery and data collection, install Netdata with auto-discovery in Kubernetes clusters |
| 276 | 5. **Review alerts** (Netdata ships with preconfigured alerts) and set up alert **notification channels** |
| 277 | 6. **Invite colleagues** (enterprise SSO via IODC, Okta and SCIMv2 supported), assign roles and permissions |
| 278 | |
| 279 | Netdata will automatically provide: |
| 280 | |
| 281 | 1. **Complete coverage** of hardware, operating system and application metrics |
| 282 | 2. Real-time, low-latency **Metrics and Logs Dashboards** |
| 283 | 3. Live and interactive exploration of running **processes**, **network connections**, **systemd units**, **systemd services**, **IMPI sensors**, and more |
| 284 | 4. Unsupervised **machine-learning based anomaly detection** for all metrics |
| 285 | 5. Hundreds of **pre-configured alerts** for systems and applications |
| 286 | 6. **AI insights** (reports) and **AI-assistant** (chat) connections via MCP (Cloud MCP for infrastructure-wide access, Agent/Parent MCP for local access) |
| 287 | |
| 288 | :::tip |
| 289 | |
| 290 | Custom dashboards are supported but are optional. Netdata provides single-node, multi-node and **infrastructure level dashboards** automatically. |
| 291 | |
| 292 | ::: |
| 293 | |
| 294 | Netdata configurations are infrastructure-as-code friendly, and provisioning systems can be used to automate deployment on large infrastructures. |
| 295 | A complete Netdata deployment is usually achieved within a few days. |
| 296 | |
| 297 | ## Resource Requirements |
| 298 | |
| 299 | Netdata is committed to having best-in-class resource utilization. Wasted resources are considered bugs and are addressed with high priority. |
| 300 | |
| 301 | Based on extensive real-world deployments and independent academic validation, Netdata maintains minimal resource footprint: |
| 302 | |
| 303 | | Resource | Standalone 5k metrics/s | Child 5k metrics/s | Parent 1M metrics/s | |
| 304 | |------------------------|:-----------------------:|:-------------------:|:-------------------:| |
| 305 | | **CPU** | 5% of a single core | 3% of a single core | ~10 cores total | |
| 306 | | **Memory** | 200 MB | 150 MB | ~40 GB | |
| 307 | | **Network** | None | \<1 Mbps to Parent | ~100 Mbps inbound | |
| 308 | | **Storage Capacity** | 3 GiB (configurable) | None | as needed | |
| 309 | | **Storage Throughput** | 5 KiB/s write | None | 1 MiB/s write | |
| 310 | | **Retention** | 1 year (configurable) | None | as needed | |
| 311 | |
| 312 | :::note |
| 313 | |
| 314 | - Parent resources include both ingestion and query workload |
| 315 | - Storage rates are for all tiers combined; actual disk usage depends on retention configuration |
| 316 | - The recommended topology is having a cluster of Netdata Parents every 500 monitored nodes (2M metrics/s) |
| 317 | |
| 318 | ::: |
| 319 | |
| 320 | :::info |
| 321 | |
| 322 | The [University of Amsterdam study](https://twitter.com/IMalavolta/status/1734208439096676680) found Netdata to be the most energy-efficient monitoring solution, with the lowest CPU overhead, memory usage, and execution time impact among compared tools. |
| 323 | |
| 324 | For more information, see [Netdata's impact on resources](/docs/netdata-agent/sizing-netdata-agents/README.md). |
| 325 | |
| 326 | ::: |
| 327 | |
| 328 | ## Practical Implications |
| 329 | |
| 330 | Please also see [Netdata Enterprise Evaluation Guide](/docs/netdata-enterprise-evaluation-corrected.md) and [Netdata's Security and Privacy Design](/docs/security-and-privacy-design/README.md). |
| 331 | |
| 332 | ### For Small Teams |
| 333 | |
| 334 | Without dedicated monitoring staff, teams need systems that work without constant attention. Netdata's automatic operation enables teams to: |
| 335 | |
| 336 | - Eliminate configuration maintenance as infrastructure changes |
| 337 | - Access instant dashboards during incidents without building them |
| 338 | - Remove the guesswork of threshold tuning as patterns evolve |
| 339 | - Achieve complete visibility with zero learning curve |
| 340 | |
| 341 | ### For Large Organizations |
| 342 | |
| 343 | At scale, traditional monitoring becomes expensive and complex. Netdata's architecture enables organizations to: |
| 344 | |
| 345 | - Gain predictable costs based on node count, not data volume |
| 346 | - Ensure consistent performance from 10 to 10,000 systems |
| 347 | - Match monitoring architecture to organizational structure |
| 348 | - Satisfy data locality requirements (GDPR, HIPAA) by design |
| 349 | |
| 350 | ### For Dynamic Environments |
| 351 | |
| 352 | Modern infrastructure changes constantly. Netdata enables teams to: |
| 353 | |
| 354 | - See new containers in dashboards immediately upon creation |
| 355 | - Maintain clean views as resources are deleted automatically |
| 356 | - Track relationships that update dynamically as services scale |
| 357 | - Benefit from ML models that continuously adapt to new patterns |
| 358 | |
| 359 | ## Frequently Asked Questions on Design Philosophy |
| 360 | |
| 361 | <details> |
| 362 | <summary>Doesn't edge architecture create a management nightmare?</summary> |
| 363 | |
| 364 | **The opposite is true — edge architecture eliminates most management overhead.** |
| 365 | |
| 366 | Traditional centralized systems require: |
| 367 | |
| 368 | - Database administration (backups, compaction, tuning) |
| 369 | - Capacity planning for central storage |
| 370 | - Pipeline management and scaling |
| 371 | - Schema migration coordination |
| 372 | - Downtime windows for maintenance |
| 373 | |
| 374 | Netdata's edge approach provides: |
| 375 | |
| 376 | - **Zero maintenance**: Agents and Parents run autonomously without administration |
| 377 | - **Automatic updates**: Built-in update mechanisms or integration with provisioning tools |
| 378 | - **Strong compatibility**: Backwards compatibility ensures upgrades don't break things |
| 379 | - **Forward compatibility**: Can often downgrade without data loss (we implement forward-read capability before activating new schemas) |
| 380 | - **No coordination needed**: Each agent updates independently — no "big bang" migrations |
| 381 | - **Fixed relationships**: Parent-Child connections are one-time configuration with alerts for disconnections |
| 382 | - **Cardinality protection**: Automated protections prevent runaway metrics from affecting the entire system |
| 383 | - **Built-in high availability**: Streaming and replication provide data redundancy without complex setup |
| 384 | |
| 385 | The architecture also delivers operational benefits: |
| 386 | |
| 387 | - **Minimal disk I/O**: Data commits only every 17 minutes per metric (spread over time), while real-time streaming maintains data safety |
| 388 | - **No backup complexity**: Observability data is ephemeral (rotated) and write-once-read-many (WORM), eliminating traditional backup requirements via replication |
| 389 | - **Isolated failures**: Issues affect only parts of the ecosystem (e.g., a single parent), not the entire monitoring foundation |
| 390 | |
| 391 | **Why not use existing databases?** |
| 392 | |
| 393 | Existing time-series databases couldn't meet the requirements for edge deployment: |
| 394 | |
| 395 | - **Process independence**: No separate database processes to manage |
| 396 | - **Write-once-read-many (WORM)**: Corruption-resistant with graceful degradation |
| 397 | - **Zero maintenance**: No tuning, compaction, or optimization required |
| 398 | - **Minimal footprint**: Small memory usage with extreme compression (0.6 bytes/sample) |
| 399 | - **Optimized I/O**: Low disk writes spread over time to minimize impact |
| 400 | - **Embedded ML**: Anomaly detection without additional storage overhead |
| 401 | - **Partial resilience**: Continues operating even with partial disk corruption |
| 402 | |
| 403 | The "thousands of databases" concern misunderstands the architecture. These aren't databases you manage — they're autonomous components that manage themselves. It's like worrying about managing thousands of log files when you use syslog — the system handles it. |
| 404 | |
| 405 | In practice, organizations using Netdata routinely achieve multi-million samples/second, highly-available observability infrastructure without even noticing the complexity this would normally imply. The complexity isn't moved — it's eliminated through design. |
| 406 | </details> |
| 407 | |
| 408 | <details> |
| 409 | <summary>Isn't collecting 'everything' fundamentally wasteful?</summary> |
| 410 | |
| 411 | **The opposite is true — Netdata is the most energy-efficient monitoring solution available.** |
| 412 | |
| 413 | The University of Amsterdam study confirmed Netdata uses significantly fewer resources than selective monitoring solutions. Despite collecting everything and per-second, our optimized design and streamlined code make Netdata more efficient, not less. |
| 414 | |
| 415 | The real question is: **What's the business impact when critical troubleshooting data isn't available during a crisis?** |
| 416 | |
| 417 | Consider: |
| 418 | |
| 419 | - **Crisis happens when things break unexpectedly** — if they were expected, you'd have mitigations in place |
| 420 | - **The very fact systems are in crisis** means the failure mode wasn't predicted |
| 421 | - **Engineers can't predict what data they'll need** for problems they didn't anticipate |
| 422 | |
| 423 | The business case for complete coverage: |
| 424 | |
| 425 | - **Reduced MTTD/MTTR**: All data is available immediately when investigating issues |
| 426 | - **No blind spots**: The metric you didn't think to collect often holds the key |
| 427 | - **ML/AI effectiveness**: Algorithms can find correlations in "insignificant" metrics that humans miss |
| 428 | - **Lower environmental impact**: More efficient than selective solutions despite broader coverage |
| 429 | |
| 430 | Selective monitoring creates a paradox: you must predict what will break to know what to monitor, but if you could predict it, you'd prevent it. Complete coverage eliminates this guessing game while actually reducing resource consumption through better engineering. |
| 431 | </details> |
| 432 | |
| 433 | <details> |
| 434 | <summary>Does complete coverage create analysis paralysis?</summary> |
| 435 | |
| 436 | **Structure prevents paralysis — Netdata organizes data hierarchically, not as an unstructured pool.** |
| 437 | |
| 438 | Unlike monitoring solutions that present metrics as a flat list, Netdata uses intelligent hierarchical organization: |
| 439 | |
| 440 | - 50 disk metrics stay within the disk section |
| 441 | - 100 container metrics remain in the container view |
| 442 | - Database metrics don't interfere with network analysis |
| 443 | |
| 444 | This means: |
| 445 | |
| 446 | - **No performance impact**: Finding database issues isn't slower because you have more network metrics |
| 447 | - **No confusion**: Each subsystem's metrics are logically grouped and accessible |
| 448 | - **Negligible cost**: One more metric adds just 18KB memory and 0.6 bytes/sample on disk |
| 449 | |
| 450 | **The real insight: Comprehensive data empowers different engineering approaches** |
| 451 | |
| 452 | Some engineers thrive with complete visibility — they can trace issues across subsystems, understand cascading failures, and prevent future problems. Others prefer simpler "is it working?" dashboards. Netdata supports both: |
| 453 | |
| 454 | - **For troubleshooters**: Full depth to understand root causes and prevent recurrence |
| 455 | - **For quick fixes**: High-level dashboards and clear alerts for immediate action |
| 456 | - **For everyone**: ML-driven Anomaly Advisor surfaces what matters without manual searching |
| 457 | |
| 458 | The philosophy isn't "more data is better" — it's "the right data should always be available." Hierarchical organization ensures engineers can work at their preferred depth without being overwhelmed by information they don't currently need. |
| 459 | |
| 460 | Organizations report that engineers who initially felt overwhelmed quickly adapt once they experience finding that one critical metric that solved a major incident — the metric they wouldn't have thought to collect in advance. |
| 461 | </details> |
| 462 | |
| 463 | <details> |
| 464 | <summary>Is per-second granularity actually useful or just marketing?</summary> |
| 465 | |
| 466 | **Per-second is for engineers, not business metrics — it matches the speed at which systems actually operate.** |
| 467 | |
| 468 | Consider the reality of modern systems: |
| 469 | |
| 470 | - CPUs execute **billions of instructions per second** |
| 471 | - A single second contains enough time for entire cascading failures |
| 472 | - In one minute, a system can process millions of requests, experience multiple garbage collections, or suffer intermittent network issues |
| 473 | |
| 474 | **Per-second is the standard for engineering tools** |
| 475 | |
| 476 | When engineers debug with console tools, they never use 10-second or minute averages. Why? Because averaging hides critical details: |
| 477 | |
| 478 | - Stress spikes that trigger failures |
| 479 | - Microbursts that overwhelm queues |
| 480 | - Brief stalls that compound into user-facing latency |
| 481 | |
| 482 | **Netdata was designed as a unified console replacement** |
| 483 | |
| 484 | Think of Netdata as the evolution of `top`, `iostat`, `netstat`, and hundreds of other console tools — but with: |
| 485 | |
| 486 | - The same per-second granularity engineers expect |
| 487 | - Complete coverage across all subsystems |
| 488 | - Historical data to trace issues backward |
| 489 | - Visual representation of complex relationships |
| 490 | - Machine Learning analyzing everything |
| 491 | |
| 492 | This is true tools consolidation: instead of jumping between dozens of console commands during an incident, engineers have one unified view at the resolution that matters. When a service degrades, you need to see the exact second it started, not a minute-average that obscures the trigger. |
| 493 | |
| 494 | **Immediate feedback is crucial for effective operations** |
| 495 | |
| 496 | When engineers make infrastructure changes, they need to see the impact immediately: |
| 497 | |
| 498 | - **During crisis**: Every second counts — you can't wait for minute-averages to confirm if your fix is working |
| 499 | - **Configuration changes**: See instantly whether that parameter helped or made things worse |
| 500 | - **Scaling operations**: Watch resource utilization respond in real-time as you add capacity |
| 501 | - **Performance tuning**: Observe the immediate effect of cache size adjustments or thread pool changes |
| 502 | |
| 503 | This instant feedback loop dramatically accelerates problem resolution. Engineers can rapidly iterate through potential fixes, seeing results within seconds rather than waiting for averaged data that might hide whether the intervention actually helped. |
| 504 | |
| 505 | For business metrics, minute or hourly aggregations make sense. But for infrastructure monitoring and tuning, per-second granularity is the foundation of effective troubleshooting. |
| 506 | </details> |
| 507 | |
| 508 | <details> |
| 509 | <summary>What about the observer effect? How do you guarantee per-second collection isn't impacting application performance?</summary> |
| 510 | |
| 511 | **Netdata's default collection frequencies are carefully configured to avoid impacting monitored applications.** |
| 512 | |
| 513 | The goal is simple: collect all metrics at the maximum possible frequency without affecting performance. This means: |
| 514 | |
| 515 | **Thoughtfully configured defaults:** |
| 516 | |
| 517 | - **Most metrics**: Collected per-second when source data updates frequently |
| 518 | - **Slower metrics**: Collected every 5-10 seconds when source data changes less frequently |
| 519 | - **Expensive metrics**: Disabled by default with optional configuration flags for specialized use cases |
| 520 | |
| 521 | **Performance-first defaults:** |
| 522 | |
| 523 | - Collection frequency is tuned based on the cost of data gathering |
| 524 | - "Expensive" metrics (those affecting performance) have lower default frequencies |
| 525 | - Some specialized metrics are completely disabled by default but can be enabled when their value justifies the overhead |
| 526 | |
| 527 | **User control:** |
| 528 | |
| 529 | - All frequencies are configurable — users can increase collection frequency if they need higher resolution for specific metrics |
| 530 | - Can disable any collector that proves problematic in their specific environment |
| 531 | - Can enable expensive collectors when their specialized value outweighs the performance cost |
| 532 | |
| 533 | This isn't about blindly collecting everything every second regardless of impact. It's about being intelligent enough to collect each metric at the optimal frequency for that specific data source and use case, defaulting to configurations that have been proven safe across thousands of production deployments. |
| 534 | |
| 535 | The University of Amsterdam study confirmed this approach works: despite comprehensive collection, Netdata has the lowest performance impact on the monitored applications among monitoring solutions. |
| 536 | </details> |
| 537 | |
| 538 | <details> |
| 539 | <summary>Why systemd-journal instead of industry standards like Elasticsearch/Splunk?</summary> |
| 540 | |
| 541 | **systemd-journal IS the industry standard — it's already installed and running on every Linux system.** |
| 542 | |
| 543 | The question misframes the choice. systemd-journal isn't competing with Elasticsearch/Splunk — it's the native log format they all read from. The real question is: why move data when you can query it directly? |
| 544 | |
| 545 | **Understanding the trade-offs:** |
| 546 | |
| 547 | | Approach | Storage Footprint | Query Performance | Indexing Strategy | |
| 548 | |--------------------------|--------------------------------|--------------------------------------------------|--------------------------------------| |
| 549 | | **Loki** | 1/4 to 1/2 of original logs | Slow (brute force scan after metadata filtering) | Limited metadata indexing | |
| 550 | | **Elasticsearch/Splunk** | 2-5x larger than original logs | Fast full-text search | Word-level reverse indexing | |
| 551 | | **systemd-journal** | ~Equal to original logs | Fast field-value queries | Forward indexing of all field values | |
| 552 | |
| 553 | **systemd-journal provides a balanced approach:** |
| 554 | |
| 555 | - **Open schema**: Each log entry can have unique fields, all automatically indexed |
| 556 | - **Storage efficient**: Roughly the same size as original logs |
| 557 | - **Query optimized**: Fast lookups for any field value as a whole |
| 558 | - **Universal compatibility**: Already the source for all other log systems |
| 559 | |
| 560 | **But systemd-journal is actually superior in critical ways:** |
| 561 | |
| 562 | - **Security features**: Forward Secure Sealing (FSS) for tamper detection — not even available in most commercial solutions |
| 563 | - **Native access control**: Uses filesystem permissions for isolation — no additional security layer to breach |
| 564 | - **Extreme performance**: Outperforms everything else in single-node ingestion throughput while being lightweight |
| 565 | - **No query server**: All queries run in parallel, lockless, directly on files — infinitely scalable read performance |
| 566 | - **OS-level optimization**: Naturally cached by the kernel, providing blazing-fast repeated queries |
| 567 | - **Built-in distribution**: Native tools for log centralization within infrastructure, no additional software needed |
| 568 | - **Edge-native**: Distributed by design, perfectly aligned with Netdata's architecture |
| 569 | |
| 570 | Furthermore, direct file access isn't a security risk — it's a security advantage. Access control is enforced by the operating system itself through native filesystem permissions. There's no query server to hack, no additional authentication layer to misconfigure, and no database permissions to manage. Multi-tenancy and log isolation work through the same filesystem permission model that has provided reliable security for decades. |
| 571 | |
| 572 | **What Netdata adds:** |
| 573 | systemd-journal is powerful but lacks the visualization and analysis layer. Netdata provides: |
| 574 | |
| 575 | - Rich query interface and dashboards |
| 576 | - Field statistics and histograms |
| 577 | - Integration with metrics and anomaly detection |
| 578 | - Web-based exploration tools |
| 579 | |
| 580 | The insight: instead of copying logs to expensive centralized systems, why not build better tools on the robust foundation already present in every Linux system? This eliminates data movement, reduces infrastructure costs, provides superior security, and delivers faster queries through native file access — all while maintaining the distributed architecture that makes modern infrastructure manageable. |
| 581 | </details> |
| 582 | |
| 583 | ## Summary |
| 584 | |
| 585 | Netdata represents a fundamental rethink of monitoring architecture. By processing data at the edge, automating configuration, maintaining real-time resolution, applying ML universally, and making data accessible to everyone, it solves core monitoring challenges that have persisted for decades. |
| 586 | |
| 587 | The result is a monitoring system that deploys in minutes, scales to any size, adapts automatically to change, and delivers insights traditional tools can’t — all while staying open source and community-driven. |
| 588 | |
| 589 | Whether you're monitoring a single server or a global infrastructure, Netdata's design philosophy creates a monitoring system that works with you rather than demanding constant attention. |