File: README.md

package info (click to toggle)
netdata 1.37.1-2
  • links: PTS, VCS
  • area: main
  • in suites: bookworm
  • size: 59,364 kB
  • sloc: ansic: 302,654; javascript: 77,865; python: 27,094; sh: 18,726; cpp: 2,916; makefile: 2,547; pascal: 171; xml: 10
file content (35 lines) | stat: -rw-r--r-- 1,419 bytes parent folder | download
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
<!--
title: "Why Netdata"
custom_edit_url: https://github.com/netdata/netdata/edit/master/docs/why-netdata/README.md
-->

# Why Netdata

> Any performance monitoring solution that does not go down to per second
> collection and visualization of the data, is useless.
> It will make you happy to have it, but it will not help you more than that. 

Netdata is built around 4 principles:

1.  **[Per second data collection for all metrics.](/docs/why-netdata/1s-granularity.md)**

    _It is impossible to monitor a 2 second SLA, with 10 second metrics._

2.  **[Collect and visualize all the metrics from all possible sources.](/docs/why-netdata/unlimited-metrics.md)**

    _To troubleshoot slowdowns, we need all the available metrics. The console should not provide more metrics._

3.  **[Meaningful presentation, optimized for visual anomaly detection.](/docs/why-netdata/meaningful-presentation.md)**

    _Metrics are a lot more than name-value pairs over time. The monitoring tool should know all the metrics. Users should not!_

4.  **[Immediate results, just install and use.](/docs/why-netdata/immediate-results.md)**

    _Most of our infrastructure is standardized. There is no point to configure everything metric by metric._

Unlike other monitoring solutions that focus on metrics visualization,
Netdata's helps us troubleshoot slowdowns without touching the console.

So, everything is a bit different.