7c95644fa · cryptotaxi247/netdata-1

@@ -6,45 +6,52 @@ Netdata is a distributed, real-time observability platform that monitors metrics

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 while offering significantly faster queries.

8

9 -The platform is designed 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.

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 -- **Netdata Agent**: Monitoring software installed on each system

13 -- **Netdata Parents**: Optional centralization points for aggregating data from multiple agents (Netdata Parents are the same software component as Netdata Agents, configured as Parents)

14 -- **Netdata Cloud**: 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.

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 ## Performance at a Glance

18

18 -| Aspect | Netdata | Industry Standard |

19 -|-------:|:-------:|:-----------------:|

20 -| **Real-Time Monitoring** | | |

21 -| Data granularity | 1 second | 10-60 seconds |

22 -| Collection to visualization | 1 second | 30+ seconds |

23 -| Time to first dashboard | 10 seconds | Hours to days |

24 -| **Automation** | | |

25 -| Configuration required | Minimal to none | Extensive |

26 -| ML anomaly detection | All metrics automatically | Selected metrics manually |

27 -| Pre-configured alerts | 400+ out of the box | Build from scratch |

28 -| **Efficiency** | | |

29 -| Storage per metric | 0.6 bytes/sample | 2-16 bytes/sample |

30 -| Agent CPU usage | 5% single core | 10-30% single core |

31 -| Scalability | Linear, unlimited | Exponential complexity |

32 -| **Coverage** | | |

33 -| Metrics collected | Everything available | Manually selected |

34 -| Built-in collectors | 800+ integrations | Basic system metrics |

35 -| Hardware monitoring | Comprehensive | Limited or none |

36 -| Live monitoring | processes, network connections, and more | Limited or none |

19 +| Aspect | Netdata | Industry Standard |

20 +|----------------------------:|:----------------------------------------:|:-------------------------:|

21 +| **Real-Time Monitoring** | | |

22 +| Data granularity | 1 second | 10-60 seconds |

23 +| Collection to visualization | 1 second | 30+ seconds |

24 +| Time to first dashboard | 10 seconds | Hours to days |

25 +| **Automation** | | |

26 +| Configuration required | Minimal to none | Extensive |

27 +| ML anomaly detection | All metrics automatically | Selected metrics manually |

28 +| Pre-configured alerts | 400+ out of the box | Build from scratch |

29 +| **Efficiency** | | |

30 +| Storage per metric | 0.6 bytes/sample | 2-16 bytes/sample |

31 +| Agent CPU usage | 5% single core | 10-30% single core |

32 +| Scalability | Linear, unlimited | Exponential complexity |

33 +| **Coverage** | | |

34 +| Metrics collected | Everything available | Manually selected |

35 +| Built-in collectors | 800+ integrations | Basic system metrics |

36 +| Hardware monitoring | Comprehensive | Limited or none |

37 +| Live monitoring | processes, network connections, and more | Limited or none |

38

39 ## Design Philosophy and Implementation

40

41 ### Data at the Edge

42

42 -> Observability data is vast, usually orders of magnitude larger than actual business data. Observability solutions struggle to scale, and even when they do scale, their complexity increases drastically and their total cost of ownership becomes unreasonable, in many cases matching or exceeding the actual infrastructure cost.

43 -

44 -Observability data is collected, stored and analyzed, but only a small percentage is actually ever viewed. The vast majority of observability data is there in case they are needed for troubleshooting, capacity planning, or post-mortem analysis.

43 +:::note

44

45 Netdata keeps the observability data at the edge (Netdata Agents), or as close to the edge as possible (Netdata Parents).

46

47 +:::

48 +

49 +:::tip

50 +

51 +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.

52 +

53 +:::

54 +

55 **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:

56

57 - **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.

@@ -55,11 +62,16 @@ Netdata keeps the observability data at the edge (Netdata Agents), or as close t

62

63 ### Complete Coverage

64

58 -> 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.

59 ->

60 -> This creates two fundamental problems:

61 -> - missing just one uncollected metric can obscure the root cause of an issue, leading to frustration and incomplete visibility during crisis

62 -> - the observability quality organizations get reflects the skills and experience of their people.

65 +:::note

66 +

67 +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.

68 +

69 +This creates two fundamental problems:

70 +

71 +- missing just one uncollected metric can obscure the root cause of an issue, leading to frustration and incomplete visibility during crisis

72 +- the observability quality organizations get reflects the skills and experience of their people.

73 +

74 +:::

75

76 Netdata's design allows it to capture everything exposed by systems and applications — every metric, every log entry, every piece of telemetry available.

77

@@ -72,11 +84,11 @@ The comprehensive approach ensures:

84

85 ### Real-Time, Low-Latency Visibility

86

75 -> Observability solutions lower granularity (the frequency data is collected) to control cost and scalability. For most of them 'real-time' is at best every 10 or 15 seconds. For all of them even this frequency is not strict, it can fluctuate without any direct impact on the analysis.

76 ->

77 -> Additionally, observability pipelines introduce latency in making the data available and it is common to have several seconds to minutes of delay between data collection and visualization.

78 ->

79 -> These inherent weaknesses make observability a statistical analysis tool, not able to keep up with the actual pace of the infrastructure, forcing engineers to use console tools when precise, accurate and on-time information is required.

87 +:::note

88 +

89 +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.

90 +

91 +:::

92

93 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:

94

@@ -89,13 +101,15 @@ Netdata collects everything per-second and has a fixed one-second data collectio

101

102 ### Data Accessibility

103

92 -> Observability solutions assume users know and understand the data before they collect and visualize them. Many solutions require from users to also know the exact types and kinds of collected data in order to visualize them properly. Most solutions require from users to manually set up charts by learning a query language and configure dashboards, organizing them in a manner that is meaningful.

93 ->

94 -> This is usually the biggest obstacle to proper observability. Discipline, skills and a huge amount of work for something that should be there by default.

104 +:::note

105 +

106 +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.

107 +

108 +:::

109

110 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.

111

98 -Netdata dashboards are an algorithm, not a configuration. Each Netdata chart is a complete analytical tool that provides a 360 view of the data and its sources, allowing slicing and dicing of any data-set using point and click, optimized to provide a comprehensive view of what is available and where data is coming 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:

112 +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:

113

114 - **Zero learning curve**: No query languages, no manual dashboard building, no configuration.

115 - **Instant time to value**: Complete visibility from the moment of installation.

@@ -105,9 +119,7 @@ Netdata dashboards are an algorithm, not a configuration. Each Netdata chart is

119

120 ### Efficient Storage

121

108 -> Centralized observability solutions introduce significant storage requirements in both capacity and I/O throughput, making observability the most important consumer of storage systems in the infrastructure.

109 -

110 -Netdata 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.

122 +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.

123

124 Netdata implements a custom time-series database optimized for the specific patterns of system metrics:

125

@@ -119,7 +131,11 @@ This efficient storage architecture delivers years of data in gigabytes rather t

131

132 ### Logs Management

133

122 -> 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.

134 +:::info

135 +

136 +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.

137 +

138 +:::

139

140 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:

141

@@ -131,14 +147,16 @@ Netdata takes a fundamentally different approach by leveraging the systemd journ

147 - **Security built-in**: Write Once Read Many (WORM) and Forward Secure Sealing (FSS) ensures log integrity and tamper detection

148 - **Logs transformation**: The platform includes `log2journal` for converting any text, JSON, or logfmt logs into structured journal entries

149

134 -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.

150 +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.

151 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.

152

137 -Note: On Windows Netdata queries Windows Event Logs (WEL), Event Tracing for Windows (ETW) and TraceLogging (TL) via the Event Log.

153 +:::note

154

139 -### AI and Machine Learning

155 +On Windows Netdata queries Windows Event Logs (WEL), Event Tracing for Windows (ETW) and TraceLogging (TL) via the Event Log.

156

141 -> Machine Learning (ML) in monitoring requires data scientists, training periods, and careful model management. This makes it accessible only to a few organizations with specialized teams, and even then is used selectively with limited scope.

157 +:::

158 +

159 +### AI and Machine Learning

160

161 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.

162

@@ -150,14 +168,12 @@ Netdata democratizes ML and AI by making it automatic and universal (no configur

168 - **Correlation analysis**: Engine identifies related anomalies across metrics

169 - **Unbiased detection**: Anomaly detection is not influenced by future events

170

153 -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.

171 +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.

172

155 -For more information see [Netdata's ML Accuracy, Reliability and Sensitivity](ml-ai/ml-anomaly-detection/ml-accuracy.md).

173 +For more information see [Netdata's ML Accuracy, Reliability and Sensitivity](/docs/ml-ai/ml-anomaly-detection/ml-anomaly-detection.md).

174

175 ### Troubleshooting

176

159 -> During a crisis, engineers typically need to make assumptions about possible root causes and validate or drop these assumptions. This is a painful process requiring expertise, deep understanding of the monitored infrastructure and dependencies that usually leads to days or weeks of investigation.

160 -

177 Netdata introduces a significant shift to the troubleshooting process utilizing its unsupervised and real-time anomaly detection system. The "Anomaly Advisor" transforms troubleshooting:

178

179 - **Automatic scoring**: Ranks all metrics by anomaly severity within any time window

@@ -170,7 +186,11 @@ This approach still requires interpretation skills but dramatically simplifies t

186

187 ### Alerts

188

173 -> 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.

189 +:::note

190 +

191 +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.

192 +

193 +:::

194

195 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:

196

@@ -178,15 +198,17 @@ Netdata takes a fundamentally different approach: templated alerts that monitor

198 - **Early detection**: Component failures are caught before they cascade into service-wide issues

199 - **Clear accountability**: Alerts identify exactly which instance is failing, not just that "something is wrong"

200 - **Scalable alerting**: Templates automatically apply to new instances as infrastructure grows

181 -- **Synthetic checks**: Lightweight integration tests that validate connectivity and behavior between applications complements component monitoring

201 +- **Synthetic checks**: Lightweight integration tests that validate connectivity and behavior between applications complement component monitoring

202 +

203 +:::tip

204

205 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.

206

185 -### Scalability

207 +:::

208

187 -> Centralized monitoring architectures hit bottlenecks — ingestion pipelines overflow, storage systems struggle, query engines slow down. Adding more infrastructure makes the monitoring system itself harder to manage.

209 +### Scalability

210

189 -For Netdata scalability is inherent to the architecture, not an add-on. Designed to be fully distributed, Netdata achieves linear scalability through:

211 +For Netdata, scalability is inherent to the architecture, not an add-on. Designed to be fully distributed, Netdata achieves linear scalability through:

212

213 - **Independent operation**: Each Agent and Parent operates autonomously without affecting others.

214 - **Horizontal scaling**: Add more Parents to handle more Agents without redesigning architecture.

@@ -214,10 +236,10 @@ Netdata can operate independently or alongside your existing observability stack

236

237 Typically, organizations deploying Netdata need to:

238

217 -1. **Install Netdata Agents** on all Linux, Windows, FreeBSD and MacOS physical servers and VMs

239 +1. **Install Netdata Agents** on all Linux, Windows, FreeBSD and macOS physical servers and VMs

240 2. Optionally: dedicate resources (VMs, storage) for Netdata Parents, providing high-availability and longer retention to observability data

241 3. Optionally: configure logs transformation with `log2journal` and centralization using typical systemd-journald methodologies

220 -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

242 +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

243 5. **Review alerts** (Netdata ships with preconfigured alerts) and set up alert **notification channels**

244 6. **Invite colleagues** (enterprise SSO via IODC, Okta and SCIMv2 supported), assign roles and permissions

245

@@ -230,8 +252,12 @@ Netdata will automatically provide:

252 5. Hundreds of **pre-configured alerts** for systems and applications

253 6. **AI insights** (reports) and **AI-assistant** (chat) connections via MCP

254

255 +:::tip

256 +

257 Custom dashboards are supported but are optional. Netdata provides single-node, multi-node and **infrastructure level dashboards** automatically.

258

259 +:::

260 +

261 Netdata configurations are infrastructure-as-code friendly, and provisioning systems can be used to automate deployment on large infrastructures.

262 A complete Netdata deployment is usually achieved within a few days.

263

@@ -243,25 +269,32 @@ Based on extensive real-world deployments and independent academic validation, N

269

271 |------------------------|:-----------------------:|:-------------------:|:-------------------:|

247 -| **Memory** | 200 MB | 150 MB | ~40 GB |

252 -

253 -Notes:

273 +| **Memory** | 200 MB | 150 MB | ~40 GB |

278 +

279 +:::note

280 +

281 - Parent resources include both ingestion and query workload

282 - Storage rates are for all tiers combined; actual disk usage depends on retention configuration

283 - The recommended topology is having a cluster of Netdata Parents every 500 monitored nodes (2M metrics/s)

284

285 +:::

286 +

287 +:::info

288 +

289 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.

290

260 -For more information see [Netdata's impact on resources](impact-on-resources.md).

291 +For more information, see [Netdata's impact on resources](/docs/netdata-agent/sizing-netdata-agents/README.md).

292 +

293 +:::

294

295 ## Practical Implications

296

264 -Please also see [Netdata Enterprise Evaluation Guide](netdata-enterprise-evaluation-corrected.md] and [Netdata's Security and Privacy Design](security-and-privacy-design/README.md).

297 +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).

298

299 ### For Small Teams

300

@@ -292,14 +325,13 @@ Modern infrastructure changes constantly. Netdata enables teams to:

325

326 ## Frequently Asked Questions on Design Philosophy

327

295 -### Q: Doesn't edge architecture create a management nightmare?

328 +<details>

329 +<summary>Doesn't edge architecture create a management nightmare?</summary>

330

331 **The opposite is true — edge architecture eliminates most management overhead.**

332

299 -<details>

300 -<summary>More details</summary>

301 -

333 Traditional centralized systems require:

334 +

335 - Database administration (backups, compaction, tuning)

336 - Capacity planning for central storage

337 - Pipeline management and scaling

@@ -307,6 +339,7 @@ Traditional centralized systems require:

339 - Downtime windows for maintenance

340

341 Netdata's edge approach provides:

342 +

343 - **Zero maintenance**: Agents and Parents run autonomously without administration

344 - **Automatic updates**: Built-in update mechanisms or integration with provisioning tools

345 - **Strong compatibility**: Backwards compatibility ensures upgrades don't break things

@@ -317,6 +350,7 @@ Netdata's edge approach provides:

350 - **Built-in high availability**: Streaming and replication provide data redundancy without complex setup

351

352 The architecture also delivers operational benefits:

353 +

354 - **Minimal disk I/O**: Data commits only every 17 minutes per metric (spread over time), while real-time streaming maintains data safety

355 - **No backup complexity**: Observability data is ephemeral (rotated) and write-once-read-many (WORM), eliminating traditional backup requirements via replication

356 - **Isolated failures**: Issues affect only parts of the ecosystem (e.g., a single parent), not the entire monitoring foundation

@@ -324,6 +358,7 @@ The architecture also delivers operational benefits:

358 **Why not use existing databases?**

359

360 Existing time-series databases couldn't meet the requirements for edge deployment:

361 +

362 - **Process independence**: No separate database processes to manage

363 - **Write-once-read-many (WORM)**: Corruption-resistant with graceful degradation

364 - **Zero maintenance**: No tuning, compaction, or optimization required

@@ -337,23 +372,23 @@ The "thousands of databases" concern misunderstands the architecture. These aren

372 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.

373 </details>

374

340 -### Q: Isn't collecting 'everything' fundamentally wasteful?

375 +<details>

376 +<summary>Isn't collecting 'everything' fundamentally wasteful?</summary>

377

378 **The opposite is true — Netdata is the most energy-efficient monitoring solution available.**

379

344 -<details>

345 -<summary>More details</summary>

346 -

380 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.

381

382 The real question is: **What's the business impact when critical troubleshooting data isn't available during a crisis?**

383

384 Consider:

385 +

386 - **Crisis happens when things break unexpectedly** — if they were expected, you'd have mitigations in place

387 - **The very fact systems are in crisis** means the failure mode wasn't predicted

388 - **Engineers can't predict what data they'll need** for problems they didn't anticipate

389

390 The business case for complete coverage:

391 +

392 - **Reduced MTTD/MTTR**: All data is available immediately when investigating issues

393 - **No blind spots**: The metric you didn't think to collect often holds the key

394 - **ML/AI effectiveness**: Algorithms can find correlations in "insignificant" metrics that humans miss

@@ -362,19 +397,19 @@ The business case for complete coverage:

397 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.

398 </details>

399

365 -### Q: Does complete coverage create analysis paralysis?

400 +<details>

401 +<summary>Does complete coverage create analysis paralysis?</summary>

402

403 **Structure prevents paralysis — Netdata organizes data hierarchically, not as an unstructured pool.**

404

369 -<details>

370 -<summary>More details</summary>

371 -

405 Unlike monitoring solutions that present metrics as a flat list, Netdata uses intelligent hierarchical organization:

406 +

407 - 50 disk metrics stay within the disk section

408 - 100 container metrics remain in the container view

409 - Database metrics don't interfere with network analysis

410

411 This means:

412 +

413 - **No performance impact**: Finding database issues isn't slower because you have more network metrics

414 - **No confusion**: Each subsystem's metrics are logically grouped and accessible

415 - **Negligible cost**: One more metric adds just 18KB memory and 0.6 bytes/sample on disk

@@ -392,14 +427,13 @@ The philosophy isn't "more data is better" — it's "the right data should alway

427 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.

428 </details>

429

395 -### Q: Is per-second granularity actually useful or just marketing?

430 +<details>

431 +<summary>Is per-second granularity actually useful or just marketing?</summary>

432

433 **Per-second is for engineers, not business metrics — it matches the speed at which systems actually operate.**

434

399 -<details>

400 -<summary>More details</summary>

401 -

435 Consider the reality of modern systems:

436 +

437 - CPUs execute **billions of instructions per second**

438 - A single second contains enough time for entire cascading failures

439 - In one minute, a system can process millions of requests, experience multiple garbage collections, or suffer intermittent network issues

@@ -407,13 +441,15 @@ Consider the reality of modern systems:

441 **Per-second is the standard for engineering tools**

442

443 When engineers debug with console tools, they never use 10-second or minute averages. Why? Because averaging hides critical details:

444 +

445 - Stress spikes that trigger failures

411 -- Micro-bursts that overwhelm queues

446 +- Microbursts that overwhelm queues

447 - Brief stalls that compound into user-facing latency

448

449 **Netdata was designed as a unified console replacement**

450

451 Think of Netdata as the evolution of `top`, `iostat`, `netstat`, and hundreds of other console tools — but with:

452 +

453 - The same per-second granularity engineers expect

454 - Complete coverage across all subsystems

455 - Historical data to trace issues backward

@@ -425,6 +461,7 @@ This is true tools consolidation: instead of jumping between dozens of console c

461 **Immediate feedback is crucial for effective operations**

462

463 When engineers make infrastructure changes, they need to see the impact immediately:

464 +

465 - **During crisis**: Every second counts — you can't wait for minute-averages to confirm if your fix is working

466 - **Configuration changes**: See instantly whether that parameter helped or made things worse

467 - **Scaling operations**: Watch resource utilization respond in real-time as you add capacity

@@ -435,26 +472,27 @@ This instant feedback loop dramatically accelerates problem resolution. Engineer

472 For business metrics, minute or hourly aggregations make sense. But for infrastructure monitoring and tuning, per-second granularity is the foundation of effective troubleshooting.

473 </details>

474

438 -### Q: What about the observer effect? How do you guarantee per-second collection isn't impacting application performance?

475 +<details>

476 +<summary>What about the observer effect? How do you guarantee per-second collection isn't impacting application performance?</summary>

477

478 **Netdata's default collection frequencies are carefully configured to avoid impacting monitored applications.**

479

442 -<details>

443 -<summary>More details</summary>

444 -

480 The goal is simple: collect all metrics at the maximum possible frequency without affecting performance. This means:

481

482 **Thoughtfully configured defaults:**

483 +

484 - **Most metrics**: Collected per-second when source data updates frequently

449 -- **Slower metrics**: Collected every 5-10 seconds when source data changes less frequently

485 +- **Slower metrics**: Collected every 5-10 seconds when source data changes less frequently

486 - **Expensive metrics**: Disabled by default with optional configuration flags for specialized use cases

487

488 **Performance-first defaults:**

489 +

490 - Collection frequency is tuned based on the cost of data gathering

491 - "Expensive" metrics (those affecting performance) have lower default frequencies

492 - Some specialized metrics are completely disabled by default but can be enabled when their value justifies the overhead

493

494 **User control:**

495 +

496 - All frequencies are configurable — users can increase collection frequency if they need higher resolution for specific metrics

497 - Can disable any collector that proves problematic in their specific environment

498 - Can enable expensive collectors when their specialized value outweighs the performance cost

@@ -464,30 +502,30 @@ This isn't about blindly collecting everything every second regardless of impact

502 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.

503 </details>

504

467 -### Q: Why systemd-journal instead of industry standards like Elasticsearch/Splunk?

505 +<details>

506 +<summary>Why systemd-journal instead of industry standards like Elasticsearch/Splunk?</summary>

507

508 **systemd-journal IS the industry standard — it's already installed and running on every Linux system.**

509

471 -<details>

472 -<summary>More details</summary>

473 -

510 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?

511

512 **Understanding the trade-offs:**

513

479 -|----------|------------------|-------------------|-------------------|

515 +|--------------------------|--------------------------------|--------------------------------------------------|--------------------------------------|

519

520 **systemd-journal provides a balanced approach:**

521 +

522 - **Open schema**: Each log entry can have unique fields, all automatically indexed

486 -- **Storage efficient**: Roughly same size as original logs

523 +- **Storage efficient**: Roughly the same size as original logs

524 - **Query optimized**: Fast lookups for any field value as a whole

525 - **Universal compatibility**: Already the source for all other log systems

526

527 **But systemd-journal is actually superior in critical ways:**

528 +

529 - **Security features**: Forward Secure Sealing (FSS) for tamper detection — not even available in most commercial solutions

530 - **Native access control**: Uses filesystem permissions for isolation — no additional security layer to breach

531 - **Extreme performance**: Outperforms everything else in single-node ingestion throughput while being lightweight

@@ -496,10 +534,11 @@ The question misframes the choice. systemd-journal isn't competing with Elastics

534 - **Built-in distribution**: Native tools for log centralization within infrastructure, no additional software needed

535 - **Edge-native**: Distributed by design, perfectly aligned with Netdata's architecture

536

499 -Furhermore, 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.

537 +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.

538

539 **What Netdata adds:**

540 systemd-journal is powerful but lacks the visualization and analysis layer. Netdata provides:

541 +

542 - Rich query interface and dashboards

543 - Field statistics and histograms

544 - Integration with metrics and anomaly detection

@@ -512,6 +551,6 @@ The insight: instead of copying logs to expensive centralized systems, why not b

551

552 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.

553

515 -The result is a monitoring system that deploys in minutes instead of months, scales efficiently to any size, adapts automatically to changes, and provides insights that would be impossible with traditional approaches — all while remaining open source and community driven.

554 +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.

555

556 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.

Update welcome-to-netdata.md (#20986)