Spelling md (#10508)
* spelling: activity Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: adding Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: addresses Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: administrators Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: alarm Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: alignment Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: analyzing Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: apcupsd Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: apply Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: around Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: associated Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: automatically Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: availability Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: background Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: bandwidth Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: berkeley Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: between Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: celsius Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: centos Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: certificate Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: cockroach Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: collectors Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: concatenation Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: configuration Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: configured Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: continuous Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: correctly Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: corresponding Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: cyberpower Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: daemon Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: dashboard Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: database Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: deactivating Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: dependencies Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: deployment Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: determine Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: downloading Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: either Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: electric Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: entity Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: entrant Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: enumerating Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: environment Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: equivalent Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: etsy Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: everything Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: examining Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: expectations Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: explicit Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: explicitly Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: finally Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: flexible Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: further Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: hddtemp Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: humidity Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: identify Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: importance Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: incoming Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: individual Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: initiate Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: installation Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: integration Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: integrity Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: involuntary Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: issues Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: kernel Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: language Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: libwebsockets Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: lighttpd Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: maintained Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: meaningful Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: memory Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: metrics Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: miscellaneous Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: monitoring Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: monitors Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: monolithic Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: multi Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: multiplier Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: navigation Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: noisy Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: number Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: observing Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: omitted Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: orchestrator Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: overall Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: overridden Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: package Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: packages Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: packet Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: pages Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: parameter Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: parsable Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: percentage Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: perfect Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: phpfpm Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: platform Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: preferred Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: prioritize Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: probabilities Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: process Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: processes Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: program Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: qos Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: quick Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: raspberry Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: received Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: recvfile Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: red hat Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: relatively Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: reliability Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: repository Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: requested Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: requests Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: retrieved Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: scenarios Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: see all Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: supported Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: supports Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: temporary Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: tsdb Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: tutorial Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: updates Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: utilization Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: value Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: variables Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: visualize Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: voluntary Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: your Signed-off-by: Josh Soref <jsoref@users.noreply.github.com>
This commit is contained in:
Josh Soref
GitHub
parent
586945c2b7
commit
f4193c3b5c
|
|
@ -66,7 +66,7 @@ Briefly our activities include:
|
|||
|
||||
## Artifacts validation
|
||||
At this point we know our software is building, we need to go through the a set of checks, to guarantee
|
||||
that our product meets certain epxectations. At the current stage, we are focusing on basic capabilities
|
||||
that our product meets certain expectations. At the current stage, we are focusing on basic capabilities
|
||||
like installing in different distributions, running the full lifecycle of install-run-update-install and so on.
|
||||
We are still working on enriching this with more and more use cases, to get us closer to achieving full stability of our software.
|
||||
Briefly we currently evaluate the following activities:
|
||||
|
|
@ -121,7 +121,7 @@ The following distributions are supported
|
|||
- Bionic
|
||||
- artful
|
||||
|
||||
- Enterprise Linux versions (Covers Redhat, CentOS, and Amazon Linux with version 6)
|
||||
- Enterprise Linux versions (Covers Red Hat, CentOS, and Amazon Linux with version 6)
|
||||
- Version 8 (TBD)
|
||||
- Version 7
|
||||
- Version 6
|
||||
|
|
|
|||
6
BUILD.md
6
BUILD.md
|
|
@ -57,7 +57,7 @@ cmake -DENABLE_DBENGINE
|
|||
|
||||
### Dependency detection
|
||||
|
||||
We have a mixture of soft- and hard-depedencies on libraries. For most of these we expect
|
||||
We have a mixture of soft- and hard-dependencies on libraries. For most of these we expect
|
||||
`pkg-config` information, for some we manually probe for libraries and include files. We
|
||||
should treat all of the external dependencies consistently:
|
||||
|
||||
|
|
@ -346,10 +346,10 @@ We should follow these steps:
|
|||
9. Deprecate / remove the autotools build-system completely (so that we can support a single
|
||||
build-system).
|
||||
|
||||
Some smaller miscellaeneous suggestions:
|
||||
Some smaller miscellaneous suggestions:
|
||||
|
||||
1. Remove the `_Generic` / `strerror_r` config to make the system simpler (use the technique
|
||||
on the blog post to make the standard version re-enterant so that it is thread-safe).
|
||||
on the blog post to make the standard version re-entrant so that it is thread-safe).
|
||||
2. Pull in jemalloc by source into the repo if it is our preferred malloc implementation.
|
||||
|
||||
# Background
|
||||
|
|
|
|||
|
|
@ -33,9 +33,9 @@
|
|||
- Exclude autofs by default in diskspace plugin [\#10441](https://github.com/netdata/netdata/pull/10441) ([nabijaczleweli](https://github.com/nabijaczleweli))
|
||||
- New eBPF kernel [\#10434](https://github.com/netdata/netdata/pull/10434) ([thiagoftsm](https://github.com/thiagoftsm))
|
||||
- Update and improve the Netdata style guide [\#10433](https://github.com/netdata/netdata/pull/10433) ([joelhans](https://github.com/joelhans))
|
||||
- Change HDDtemp to report None instead of 0 [\#10429](https://github.com/netdata/netdata/pull/10429) ([slavox](https://github.com/slavox))
|
||||
- Change hddtemp to report None instead of 0 [\#10429](https://github.com/netdata/netdata/pull/10429) ([slavox](https://github.com/slavox))
|
||||
- Use bash shell as user netdata for debug [\#10425](https://github.com/netdata/netdata/pull/10425) ([Steve8291](https://github.com/Steve8291))
|
||||
- Qick and dirty fix for \#10420 [\#10424](https://github.com/netdata/netdata/pull/10424) ([skibbipl](https://github.com/skibbipl))
|
||||
- Quick and dirty fix for \#10420 [\#10424](https://github.com/netdata/netdata/pull/10424) ([skibbipl](https://github.com/skibbipl))
|
||||
- Add instructions on enabling explicitly disabled collectors [\#10418](https://github.com/netdata/netdata/pull/10418) ([joelhans](https://github.com/joelhans))
|
||||
- Change links at bottom of all install docs [\#10416](https://github.com/netdata/netdata/pull/10416) ([joelhans](https://github.com/joelhans))
|
||||
- Improve configuration docs with common changes and start/stop/restart directions [\#10415](https://github.com/netdata/netdata/pull/10415) ([joelhans](https://github.com/joelhans))
|
||||
|
|
@ -139,7 +139,7 @@
|
|||
- add `nvidia\_smi` collector data to the dashboard\_info.js [\#10230](https://github.com/netdata/netdata/pull/10230) ([ilyam8](https://github.com/ilyam8))
|
||||
- health: convert `elasticsearch\_last\_collected` alarm to template [\#10226](https://github.com/netdata/netdata/pull/10226) ([ilyam8](https://github.com/ilyam8))
|
||||
- streaming: fix a typo in the README.md [\#10225](https://github.com/netdata/netdata/pull/10225) ([ilyam8](https://github.com/ilyam8))
|
||||
- collectors/xenstat.plugin: recieved =\> received [\#10224](https://github.com/netdata/netdata/pull/10224) ([ilyam8](https://github.com/ilyam8))
|
||||
- collectors/xenstat.plugin: received =\> received [\#10224](https://github.com/netdata/netdata/pull/10224) ([ilyam8](https://github.com/ilyam8))
|
||||
- dashboard\_info.js: fix a typo \(vernemq\) [\#10223](https://github.com/netdata/netdata/pull/10223) ([ilyam8](https://github.com/ilyam8))
|
||||
- Fix chart filtering [\#10218](https://github.com/netdata/netdata/pull/10218) ([vlvkobal](https://github.com/vlvkobal))
|
||||
- Don't stop Prometheus remote write collector when data is not available for dimension formatting [\#10217](https://github.com/netdata/netdata/pull/10217) ([vlvkobal](https://github.com/vlvkobal))
|
||||
|
|
@ -226,7 +226,7 @@
|
|||
- Fix memory mode none not dropping stale dimension data [\#9917](https://github.com/netdata/netdata/pull/9917) ([mfundul](https://github.com/mfundul))
|
||||
- Fix memory mode none not marking dimensions as obsolete. [\#9912](https://github.com/netdata/netdata/pull/9912) ([mfundul](https://github.com/mfundul))
|
||||
- Fix buffer overflow in rrdr structure [\#9903](https://github.com/netdata/netdata/pull/9903) ([mfundul](https://github.com/mfundul))
|
||||
- Fix missing newline concatentation slash causing rpm build to fail [\#9900](https://github.com/netdata/netdata/pull/9900) ([prologic](https://github.com/prologic))
|
||||
- Fix missing newline concatenation slash causing rpm build to fail [\#9900](https://github.com/netdata/netdata/pull/9900) ([prologic](https://github.com/prologic))
|
||||
- installer: update go.d.plugin version to v0.22.0 [\#9898](https://github.com/netdata/netdata/pull/9898) ([ilyam8](https://github.com/ilyam8))
|
||||
- Add v2 HTTP message with compression to ACLK [\#9895](https://github.com/netdata/netdata/pull/9895) ([underhood](https://github.com/underhood))
|
||||
- Fix lock order reversal \(Coverity defect CID 361629\) [\#9888](https://github.com/netdata/netdata/pull/9888) ([mfundul](https://github.com/mfundul))
|
||||
|
|
|
|||
|
|
@ -164,7 +164,7 @@ netdata (1.6.0) - 2017-03-20
|
|||
|
||||
1. number of sensors by state
|
||||
2. number of events in SEL
|
||||
3. Temperatures CELCIUS
|
||||
3. Temperatures CELSIUS
|
||||
4. Temperatures FAHRENHEIT
|
||||
5. Voltages
|
||||
6. Currents
|
||||
|
|
@ -239,7 +239,7 @@ netdata (1.5.0) - 2017-01-22
|
|||
Vladimir Kobal (@vlvkobal) has done a magnificent work
|
||||
porting netdata to FreeBSD and MacOS.
|
||||
|
||||
Everyhing works: cpu, memory, disks performance, disks space,
|
||||
Everything works: cpu, memory, disks performance, disks space,
|
||||
network interfaces, interrupts, IPv4 metrics, IPv6 metrics
|
||||
processes, context switches, softnet, IPC queues,
|
||||
IPC semaphores, IPC shared memory, uptime, etc. Wow!
|
||||
|
|
@ -382,7 +382,7 @@ netdata (1.4.0) - 2016-10-04
|
|||
cgroups,
|
||||
hddtemp,
|
||||
sensors,
|
||||
phpfm,
|
||||
phpfpm,
|
||||
tc (QoS)
|
||||
|
||||
In detail:
|
||||
|
|
@ -483,7 +483,7 @@ netdata (1.3.0) - 2016-08-28
|
|||
- hddtemp
|
||||
- mysql
|
||||
- nginx
|
||||
- phpfm
|
||||
- phpfpm
|
||||
- postfix
|
||||
- sensors
|
||||
- squid
|
||||
|
|
@ -518,7 +518,7 @@ netdata (1.3.0) - 2016-08-28
|
|||
- apps.plugin improvements:
|
||||
|
||||
- can now run with command line argument 'without-files'
|
||||
to prevent it from enumating all the open files/sockets/pipes
|
||||
to prevent it from enumerating all the open files/sockets/pipes
|
||||
of all running processes.
|
||||
|
||||
- apps.plugin now scales the collected values to match the
|
||||
|
|
@ -575,7 +575,7 @@ netdata (1.2.0) - 2016-05-16
|
|||
20% better performance for the core of netdata.
|
||||
|
||||
- More efficient threads locking in key components
|
||||
contributed to the overal efficiency.
|
||||
contributed to the overall efficiency.
|
||||
|
||||
- netdata now has a CENTRAL REGISTRY !
|
||||
|
||||
|
|
@ -625,7 +625,7 @@ netdata (1.1.0) - 2016-04-20
|
|||
- Data collection: apps.plugin: grouping of processes now support patterns
|
||||
- Data collection: apps.plugin: now it is faster, after the new features added
|
||||
- Data collection: better auto-detection of partitions for disk monitoring
|
||||
- Data collection: better fireqos intergation for QoS monitoring
|
||||
- Data collection: better fireqos integration for QoS monitoring
|
||||
- Data collection: squid monitoring now uses squidclient
|
||||
- Data collection: SNMP monitoring now supports 64bit counters
|
||||
- API: fixed issues in CSV output generation
|
||||
|
|
|
|||
|
|
@ -27,7 +27,7 @@ TimescaleDB.
|
|||
Finally, another member of Netdata's community has built a project that quickly launches Netdata, TimescaleDB, and
|
||||
Grafana in easy-to-manage Docker containers. Rune Juhl Jacobsen's
|
||||
[project](https://github.com/runejuhl/grafana-timescaledb) uses a `Makefile` to create everything, which makes it
|
||||
perferct for testing and experimentation.
|
||||
perfect for testing and experimentation.
|
||||
|
||||
## Netdata↔TimescaleDB in action
|
||||
|
||||
|
|
|
|||
|
|
@ -21,7 +21,7 @@ change the `destination = localhost:4242` line accordingly.
|
|||
|
||||
As of [v1.16.0](https://github.com/netdata/netdata/releases/tag/v1.16.0), Netdata can send metrics to OpenTSDB using
|
||||
TLS/SSL. Unfortunately, OpenTDSB does not support encrypted connections, so you will have to configure a reverse proxy
|
||||
to enable HTTPS communication between Netdata and OpenTSBD. You can set up a reverse proxy with
|
||||
to enable HTTPS communication between Netdata and OpenTSDB. You can set up a reverse proxy with
|
||||
[Nginx](/docs/Running-behind-nginx.md).
|
||||
|
||||
After your proxy is configured, make the following changes to `netdata.conf`:
|
||||
|
|
|
|||
|
|
@ -12,7 +12,7 @@ decoupled. This allows:
|
|||
- Cross-compilation (e.g. linux development from macOS)
|
||||
- Cross-distro (e.g. using CentOS user-land while developing on Debian)
|
||||
- Multi-host scenarios (e.g. parent-child configurations)
|
||||
- Bleeding-edge sceneraios (e.g. using the ACLK (**currently for internal-use only**))
|
||||
- Bleeding-edge scenarios (e.g. using the ACLK (**currently for internal-use only**))
|
||||
|
||||
The advantage of these scenarios is that they allow **reproducible** builds and testing
|
||||
for developers. This is the first iteration of the build-system to allow the team to use
|
||||
|
|
|
|||
|
|
@ -304,7 +304,7 @@ This node no longer has access to the credentials it was claimed with and cannot
|
|||
You will still be able to see this node in your War Rooms in an **unreachable** state.
|
||||
|
||||
If you want to reclaim this node into a different Space, you need to create a new identity by adding `-id=$(uuidgen)` to
|
||||
the claiming script parameters. Make sure that you have the `uuidgen-runtime` packagen installed, as it is used to run the command `uuidgen`. For example, using the default claiming script:
|
||||
the claiming script parameters. Make sure that you have the `uuidgen-runtime` package installed, as it is used to run the command `uuidgen`. For example, using the default claiming script:
|
||||
|
||||
```bash
|
||||
sudo netdata-claim.sh -token=TOKEN -rooms=ROOM1,ROOM2 -url=https://app.netdata.cloud -id=$(uuidgen)
|
||||
|
|
|
|||
|
|
@ -222,7 +222,7 @@ configure any of these collectors according to your setup and infrastructure.
|
|||
- [ISC DHCP (Go)](https://learn.netdata.cloud/docs/agent/collectors/go.d.plugin/modules/isc_dhcpd): Reads a
|
||||
`dhcpd.leases` file and collects metrics on total active leases, pool active leases, and pool utilization.
|
||||
- [ISC DHCP (Python)](/collectors/python.d.plugin/isc_dhcpd/README.md): Reads `dhcpd.leases` file and reports DHCP
|
||||
pools utiliation and leases statistics (total number, leases per pool).
|
||||
pools utilization and leases statistics (total number, leases per pool).
|
||||
- [OpenLDAP](/collectors/python.d.plugin/openldap/README.md): Provides statistics information from the OpenLDAP
|
||||
(`slapd`) server.
|
||||
- [NSD](/collectors/python.d.plugin/nsd/README.md): Monitor nameserver performance metrics using the `nsd-control`
|
||||
|
|
@ -357,7 +357,7 @@ The Netdata Agent can collect these system- and hardware-level metrics using a v
|
|||
- [BCACHE](/collectors/proc.plugin/README.md): Monitor BCACHE statistics with the the `proc.plugin` collector.
|
||||
- [Block devices](/collectors/proc.plugin/README.md): Gather metrics about the health and performance of block
|
||||
devices using the the `proc.plugin` collector.
|
||||
- [Btrfs](/collectors/proc.plugin/README.md): Montiors Btrfs filesystems with the the `proc.plugin` collector.
|
||||
- [Btrfs](/collectors/proc.plugin/README.md): Monitors Btrfs filesystems with the the `proc.plugin` collector.
|
||||
- [Device mapper](/collectors/proc.plugin/README.md): Gather metrics about the Linux device mapper with the proc
|
||||
collector.
|
||||
- [Disk space](/collectors/diskspace.plugin/README.md): Collect disk space usage metrics on Linux mount points.
|
||||
|
|
@ -445,7 +445,7 @@ The Netdata Agent can collect these system- and hardware-level metrics using a v
|
|||
- [systemd](/collectors/cgroups.plugin/README.md): Monitor the CPU and memory usage of systemd services using the
|
||||
`cgroups.plugin` collector.
|
||||
- [systemd unit states](https://learn.netdata.cloud/docs/agent/collectors/go.d.plugin/modules/systemdunits): See the
|
||||
state (active, inactive, activating, deactiviating, failed) of various systemd unit types.
|
||||
state (active, inactive, activating, deactivating, failed) of various systemd unit types.
|
||||
- [System processes](/collectors/proc.plugin/README.md): Collect metrics on system load and total processes running
|
||||
using `/proc/loadavg` and the `proc.plugin` collector.
|
||||
- [Uptime](/collectors/proc.plugin/README.md): Monitor the uptime of a system using the `proc.plugin` collector.
|
||||
|
|
@ -511,10 +511,10 @@ the `go.d.plugin`.
|
|||
|
||||
## Third-party collectors
|
||||
|
||||
These collectors are developed and maintined by third parties and, unlike the other collectors, are not installed by
|
||||
These collectors are developed and maintained by third parties and, unlike the other collectors, are not installed by
|
||||
default. To use a third-party collector, visit their GitHub/documentation page and follow their installation procedures.
|
||||
|
||||
- [CyberPower UPS](https://github.com/HawtDogFlvrWtr/netdata_cyberpwrups_plugin): Polls Cyberpower UPS data using
|
||||
- [CyberPower UPS](https://github.com/HawtDogFlvrWtr/netdata_cyberpwrups_plugin): Polls CyberPower UPS data using
|
||||
PowerPanel® Personal Linux.
|
||||
- [Logged-in users](https://github.com/veksh/netdata-numsessions): Collect the number of currently logged-on users.
|
||||
- [nim-netdata-plugin](https://github.com/FedericoCeratto/nim-netdata-plugin): A helper to create native Netdata
|
||||
|
|
|
|||
|
|
@ -32,7 +32,7 @@ guide](/collectors/QUICKSTART.md).
|
|||
|
||||
[Monitor Nginx or Apache web server log files with Netdata](/docs/guides/collect-apache-nginx-web-logs.md)
|
||||
|
||||
[Monitor CockroadchDB metrics with Netdata](/docs/guides/monitor-cockroachdb.md)
|
||||
[Monitor CockroachDB metrics with Netdata](/docs/guides/monitor-cockroachdb.md)
|
||||
|
||||
[Monitor Unbound DNS servers with Netdata](/docs/guides/collect-unbound-metrics.md)
|
||||
|
||||
|
|
@ -40,7 +40,7 @@ guide](/collectors/QUICKSTART.md).
|
|||
|
||||
## Related features
|
||||
|
||||
**[Dashboards](/web/README.md)**: Vizualize your newly-collect metrics in real-time using Netdata's [built-in
|
||||
**[Dashboards](/web/README.md)**: Visualize your newly-collect metrics in real-time using Netdata's [built-in
|
||||
dashboard](/web/gui/README.md).
|
||||
|
||||
**[Backends](/backends/README.md)**: Extend our built-in [database engine](/database/engine/README.md), which supports
|
||||
|
|
|
|||
|
|
@ -46,7 +46,7 @@ However, there are cases that auto-detection fails. Usually, the reason is that
|
|||
allow Netdata to connect. In most of the cases, allowing the user `netdata` from `localhost` to connect and collect
|
||||
metrics, will automatically enable data collection for the application in question (it will require a Netdata restart).
|
||||
|
||||
View our [collectors quickstart](/collectors/QUICKSTART.md) for explict details on enabling and configuring collector modules.
|
||||
View our [collectors quickstart](/collectors/QUICKSTART.md) for explicit details on enabling and configuring collector modules.
|
||||
|
||||
## Troubleshoot a collector
|
||||
|
||||
|
|
@ -112,7 +112,7 @@ This section features a list of Netdata's plugins, with a boolean setting to ena
|
|||
# charts.d = yes
|
||||
```
|
||||
|
||||
By default, most plugins are enabled, so you don't need to enable them explicity to use their collectors. To enable or
|
||||
By default, most plugins are enabled, so you don't need to enable them explicitly to use their collectors. To enable or
|
||||
disable any specific plugin, remove the comment (`#`) and change the boolean setting to `yes` or `no`.
|
||||
|
||||
All **external plugins** are managed by [plugins.d](plugins.d/), which provides additional management options.
|
||||
|
|
|
|||
|
|
@ -59,7 +59,7 @@ Each of these sections provides the same number of charts:
|
|||
- Pipes open (`apps.pipes`)
|
||||
- Swap memory
|
||||
- Swap memory used (`apps.swap`)
|
||||
- Major page faults (i.e. swap activiy, `apps.major_faults`)
|
||||
- Major page faults (i.e. swap activity, `apps.major_faults`)
|
||||
- Network
|
||||
- Sockets open (`apps.sockets`)
|
||||
|
||||
|
|
|
|||
|
|
@ -145,7 +145,7 @@ Support per distribution:
|
|||
|Fedora 25|YES|[here](http://pastebin.com/ax0373wF)||
|
||||
|Debian 8|NO||can be enabled, see below|
|
||||
|AMI|NO|[here](http://pastebin.com/FrxmptjL)|not a systemd system|
|
||||
|Centos 7.3.1611|NO|[here](http://pastebin.com/SpzgezAg)|can be enabled, see below|
|
||||
|CentOS 7.3.1611|NO|[here](http://pastebin.com/SpzgezAg)|can be enabled, see below|
|
||||
|
||||
### how to enable cgroup accounting on systemd systems that is by default disabled
|
||||
|
||||
|
|
|
|||
|
|
@ -221,7 +221,7 @@ The following options are available:
|
|||
- `ports`: Define the destination ports for Netdata to monitor.
|
||||
- `hostnames`: The list of hostnames that can be resolved to an IP address.
|
||||
- `ips`: The IP or range of IPs that you want to monitor. You can use IPv4 or IPv6 addresses, use dashes to define a
|
||||
range of IPs, or use CIDR values. The default behavior is to only collect data for private IP addresess, but this
|
||||
range of IPs, or use CIDR values. The default behavior is to only collect data for private IP addresses, but this
|
||||
can be changed with the `ips` setting.
|
||||
|
||||
By default, Netdata displays up to 500 dimensions on network connection charts. If there are more possible dimensions,
|
||||
|
|
@ -275,7 +275,7 @@ curl -sSL https://raw.githubusercontent.com/netdata/kernel-collector/master/tool
|
|||
|
||||
If this script returns no output, your system is ready to compile and run the eBPF collector.
|
||||
|
||||
If you see a warning about a missing kerkel configuration (`KPROBES KPROBES_ON_FTRACE HAVE_KPROBES BPF BPF_SYSCALL
|
||||
If you see a warning about a missing kernel configuration (`KPROBES KPROBES_ON_FTRACE HAVE_KPROBES BPF BPF_SYSCALL
|
||||
BPF_JIT`), you will need to recompile your kernel to support this configuration. The process of recompiling Linux
|
||||
kernels varies based on your distribution and version. Read the documentation for your system's distribution to learn
|
||||
more about the specific workflow for recompiling the kernel, ensuring that you set all the necessary
|
||||
|
|
|
|||
|
|
@ -25,7 +25,7 @@ The plugin creates (up to) 8 charts, based on the information collected from IPM
|
|||
|
||||
1. number of sensors by state
|
||||
2. number of events in SEL
|
||||
3. Temperatures CELCIUS
|
||||
3. Temperatures CELSIUS
|
||||
4. Temperatures FAHRENHEIT
|
||||
5. Voltages
|
||||
6. Currents
|
||||
|
|
|
|||
|
|
@ -40,7 +40,7 @@ The charts are configurable, however, the provided default configuration collect
|
|||
- Heat circuit 1 room temperature in C (set/actual)
|
||||
- Heat circuit 2 room temperature in C (set/actual)
|
||||
|
||||
5. **Eletric Reheating**
|
||||
5. **Electric Reheating**
|
||||
|
||||
- Dual Mode Reheating temperature in C (hot water/heating)
|
||||
|
||||
|
|
@ -68,7 +68,7 @@ If no configuration is given, the module will be disabled. Each `update_every` i
|
|||
|
||||
Original author: BrainDoctor (github)
|
||||
|
||||
The module supports any metrics that are parseable with RegEx. There is no API that gives direct access to the values (AFAIK), so the "workaround" is to parse the HTML output of the ISG.
|
||||
The module supports any metrics that are parsable with RegEx. There is no API that gives direct access to the values (AFAIK), so the "workaround" is to parse the HTML output of the ISG.
|
||||
|
||||
### Testing
|
||||
|
||||
|
|
|
|||
|
|
@ -64,7 +64,7 @@ enable the perf plugin, edit /etc/netdata/netdata.conf and set:
|
|||
You can use the `command options` parameter to pick what data should be collected and which charts should be
|
||||
displayed. If `all` is used, all general performance monitoring counters are probed and corresponding charts
|
||||
are enabled for the available counters. You can also define a particular set of enabled charts using the
|
||||
following keywords: `cycles`, `instructions`, `branch`, `cache`, `bus`, `stalled`, `migrations`, `alighnment`,
|
||||
following keywords: `cycles`, `instructions`, `branch`, `cache`, `bus`, `stalled`, `migrations`, `alignment`,
|
||||
`emulation`, `L1D`, `L1D-prefetch`, `L1I`, `LL`, `DTLB`, `ITLB`, `PBU`.
|
||||
|
||||
## Debugging
|
||||
|
|
|
|||
|
|
@ -79,7 +79,7 @@ Example:
|
|||
```
|
||||
|
||||
The setting `enable running new plugins` sets the default behavior for all external plugins. It can be
|
||||
overriden for distinct plugins by modifying the appropriate plugin value configuration to either `yes` or `no`.
|
||||
overridden for distinct plugins by modifying the appropriate plugin value configuration to either `yes` or `no`.
|
||||
|
||||
The setting `check for new plugins every` sets the interval between scans of the directory
|
||||
`/usr/libexec/netdata/plugins.d`. New plugins can be added any time, and Netdata will detect them in a timely manner.
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ sidebar_label: "AM2320"
|
|||
|
||||
# AM2320 sensor monitoring with netdata
|
||||
|
||||
Displays a graph of the temperature and humity from a AM2320 sensor.
|
||||
Displays a graph of the temperature and humidity from a AM2320 sensor.
|
||||
|
||||
## Requirements
|
||||
- Adafruit Circuit Python AM2320 library
|
||||
|
|
@ -28,10 +28,10 @@ cd /etc/netdata # Replace this path with your Netdata config directory, if dif
|
|||
sudo ./edit-config python.d/am2320.conf
|
||||
```
|
||||
|
||||
Raspbery Pi Instructions:
|
||||
Raspberry Pi Instructions:
|
||||
|
||||
Hardware install:
|
||||
Connect the am2320 to the Raspbery Pi I2C pins
|
||||
Connect the am2320 to the Raspberry Pi I2C pins
|
||||
|
||||
Raspberry Pi 3B/4 Pins:
|
||||
|
||||
|
|
|
|||
|
|
@ -134,7 +134,7 @@ local:
|
|||
diffs_n: 1
|
||||
|
||||
# What is the typical proportion of anomalies in your data on average?
|
||||
# This paramater can control the sensitivity of your models to anomalies.
|
||||
# This parameter can control the sensitivity of your models to anomalies.
|
||||
# Some discussion here: https://github.com/yzhao062/pyod/issues/144
|
||||
contamination: 0.001
|
||||
|
||||
|
|
@ -142,7 +142,7 @@ local:
|
|||
# just the average of all anomaly probabilities at each time step
|
||||
include_average_prob: true
|
||||
|
||||
# Define any custom models you would like to create anomaly probabilties for, some examples below to show how.
|
||||
# Define any custom models you would like to create anomaly probabilities for, some examples below to show how.
|
||||
# For example below example creates two custom models, one to run anomaly detection user and system cpu for our demo servers
|
||||
# and one on the cpu and mem apps metrics for the python.d.plugin.
|
||||
# custom_models:
|
||||
|
|
@ -161,7 +161,7 @@ local:
|
|||
|
||||
In the `anomalies.conf` file you can also define some "custom models" which you can use to group one or more metrics into a single model much like is done by default for the charts you specify. This is useful if you have a handful of metrics that exist in different charts but perhaps are related to the same underlying thing you would like to perform anomaly detection on, for example a specific app or user.
|
||||
|
||||
To define a custom model you would include configuation like below in `anomalies.conf`. By default there should already be some commented out examples in there.
|
||||
To define a custom model you would include configuration like below in `anomalies.conf`. By default there should already be some commented out examples in there.
|
||||
|
||||
`name` is a name you give your custom model, this is what will appear alongside any other specified charts in the `anomalies.probability` and `anomalies.anomaly` charts. `dimensions` is a string of metrics you want to include in your custom model. By default the [netdata-pandas](https://github.com/netdata/netdata-pandas) library used to pull the data from Netdata uses a "chart.a|dim.1" type of naming convention in the pandas columns it returns, hence the `dimensions` string should look like "chart.name|dimension.name,chart.name|dimension.name". The examples below hopefully make this clear.
|
||||
|
||||
|
|
@ -194,7 +194,7 @@ sudo su -s /bin/bash netdata
|
|||
/usr/libexec/netdata/plugins.d/python.d.plugin anomalies debug trace nolock
|
||||
```
|
||||
|
||||
## Deepdive turorial
|
||||
## Deepdive tutorial
|
||||
|
||||
If you would like to go deeper on what exactly the anomalies collector is doing under the hood then check out this [deepdive tutorial](https://github.com/netdata/community/blob/main/netdata-agent-api/netdata-pandas/anomalies_collector_deepdive.ipynb) in our community repo where you can play around with some data from our demo servers (or your own if its accessible to you) and work through the calculations step by step.
|
||||
|
||||
|
|
@ -206,7 +206,7 @@ If you would like to go deeper on what exactly the anomalies collector is doing
|
|||
- Python 3 is also required for the underlying ML libraries of [numba](https://pypi.org/project/numba/), [scikit-learn](https://pypi.org/project/scikit-learn/), and [PyOD](https://pypi.org/project/pyod/).
|
||||
- It may take a few hours or so (depending on your choice of `train_secs_n`) for the collector to 'settle' into it's typical behaviour in terms of the trained models and probabilities you will see in the normal running of your node.
|
||||
- As this collector does most of the work in Python itself, with [PyOD](https://pyod.readthedocs.io/en/latest/) leveraging [numba](https://numba.pydata.org/) under the hood, you may want to try it out first on a test or development system to get a sense of its performance characteristics on a node similar to where you would like to use it.
|
||||
- `lags_n`, `smooth_n`, and `diffs_n` together define the preprocessing done to the raw data before models are trained and before each prediction. This essentially creates a [feature vector](https://en.wikipedia.org/wiki/Feature_(machine_learning)#:~:text=In%20pattern%20recognition%20and%20machine,features%20that%20represent%20some%20object.&text=Feature%20vectors%20are%20often%20combined,score%20for%20making%20a%20prediction.) for each chart model (or each custom model). The default settings for these parameters aim to create a rolling matrix of recent smoothed [differenced](https://en.wikipedia.org/wiki/Autoregressive_integrated_moving_average#Differencing) values for each chart. The aim of the model then is to score how unusual this 'matrix' of features is for each chart based on what it has learned as 'normal' from the training data. So as opposed to just looking at the single most recent value of a dimension and considering how strange it is, this approach looks at a recent smoothed window of all dimensions for a chart (or dimensions in a custom model) and asks how unusual the data as a whole looks. This should be more flexibile in capturing a wider range of [anomaly types](https://andrewm4894.com/2020/10/19/different-types-of-time-series-anomalies/) and be somewhat more robust to temporary 'spikes' in the data that tend to always be happening somewhere in your metrics but often are not the most important type of anomaly (this is all covered in a lot more detail in the [deepdive tutorial](https://nbviewer.jupyter.org/github/netdata/community/blob/main/netdata-agent-api/netdata-pandas/anomalies_collector_deepdive.ipynb)).
|
||||
- `lags_n`, `smooth_n`, and `diffs_n` together define the preprocessing done to the raw data before models are trained and before each prediction. This essentially creates a [feature vector](https://en.wikipedia.org/wiki/Feature_(machine_learning)#:~:text=In%20pattern%20recognition%20and%20machine,features%20that%20represent%20some%20object.&text=Feature%20vectors%20are%20often%20combined,score%20for%20making%20a%20prediction.) for each chart model (or each custom model). The default settings for these parameters aim to create a rolling matrix of recent smoothed [differenced](https://en.wikipedia.org/wiki/Autoregressive_integrated_moving_average#Differencing) values for each chart. The aim of the model then is to score how unusual this 'matrix' of features is for each chart based on what it has learned as 'normal' from the training data. So as opposed to just looking at the single most recent value of a dimension and considering how strange it is, this approach looks at a recent smoothed window of all dimensions for a chart (or dimensions in a custom model) and asks how unusual the data as a whole looks. This should be more flexible in capturing a wider range of [anomaly types](https://andrewm4894.com/2020/10/19/different-types-of-time-series-anomalies/) and be somewhat more robust to temporary 'spikes' in the data that tend to always be happening somewhere in your metrics but often are not the most important type of anomaly (this is all covered in a lot more detail in the [deepdive tutorial](https://nbviewer.jupyter.org/github/netdata/community/blob/main/netdata-agent-api/netdata-pandas/anomalies_collector_deepdive.ipynb)).
|
||||
- You can see how long model training is taking by looking in the logs for the collector `grep 'anomalies' /var/log/netdata/error.log | grep 'training'` and you should see lines like `2020-12-01 22:02:14: python.d INFO: anomalies[local] : training complete in 2.81 seconds (runs_counter=2700, model=pca, train_n_secs=14400, models=26, n_fit_success=26, n_fit_fails=0, after=1606845731, before=1606860131).`.
|
||||
- This also gives counts of the number of models, if any, that failed to fit and so had to default back to the DefaultModel (which is currently [HBOS](https://pyod.readthedocs.io/en/latest/_modules/pyod/models/hbos.html)).
|
||||
- `after` and `before` here refer to the start and end of the training data used to train the models.
|
||||
|
|
@ -215,8 +215,8 @@ If you would like to go deeper on what exactly the anomalies collector is doing
|
|||
- Typically ~3%-3.5% additional cpu usage from scoring, jumping to ~60% for a couple of seconds during model training.
|
||||
- About ~150mb of ram (`apps.mem`) being continually used by the `python.d.plugin`.
|
||||
- If you activate this collector on a fresh node, it might take a little while to build up enough data to calculate a realistic and useful model.
|
||||
- Some models like `iforest` can be comparatively expensive (on same n1-standard-2 system above ~2s runtime during predict, ~40s training time, ~50% cpu on both train and predict) so if you would like to use it you might be advised to set a relativley high `update_every` maybe 10, 15 or 30 in `anomalies.conf`.
|
||||
- Setting a higher `train_every_n` and `update_every` is an easy way to devote less resources on the node to anomaly detection. Specifying less charts and a lower `train_n_secs` will also help reduce resources at the expense of covering less charts and maybe a more noisey model if you set `train_n_secs` to be too small for how your node tends to behave.
|
||||
- Some models like `iforest` can be comparatively expensive (on same n1-standard-2 system above ~2s runtime during predict, ~40s training time, ~50% cpu on both train and predict) so if you would like to use it you might be advised to set a relatively high `update_every` maybe 10, 15 or 30 in `anomalies.conf`.
|
||||
- Setting a higher `train_every_n` and `update_every` is an easy way to devote less resources on the node to anomaly detection. Specifying less charts and a lower `train_n_secs` will also help reduce resources at the expense of covering less charts and maybe a more noisy model if you set `train_n_secs` to be too small for how your node tends to behave.
|
||||
|
||||
## Useful links and further reading
|
||||
|
||||
|
|
|
|||
|
|
@ -38,8 +38,8 @@ Module gives information with following charts:
|
|||
|
||||
5. **Context Switches**
|
||||
|
||||
- volountary
|
||||
- involountary
|
||||
- voluntary
|
||||
- involuntary
|
||||
|
||||
6. **disk** in bytes/s
|
||||
|
||||
|
|
|
|||
|
|
@ -69,7 +69,7 @@ Sample output:
|
|||
```json
|
||||
{
|
||||
"cmdline": ["./expvar-demo-binary"],
|
||||
"memstats": {"Alloc":630856,"TotalAlloc":630856,"Sys":3346432,"Lookups":27, <ommited for brevity>}
|
||||
"memstats": {"Alloc":630856,"TotalAlloc":630856,"Sys":3346432,"Lookups":27, <omitted for brevity>}
|
||||
}
|
||||
```
|
||||
|
||||
|
|
|
|||
|
|
@ -80,7 +80,7 @@ Number of charts depends on mongodb version, storage engine and other features (
|
|||
13. **Cache metrics** (WiredTiger):
|
||||
|
||||
- percentage of bytes currently in the cache (amount of space taken by cached data)
|
||||
- percantage of tracked dirty bytes in the cache (amount of space taken by dirty data)
|
||||
- percentage of tracked dirty bytes in the cache (amount of space taken by dirty data)
|
||||
|
||||
14. **Pages evicted from cache** (WiredTiger):
|
||||
|
||||
|
|
|
|||
|
|
@ -67,7 +67,7 @@ This module will produce following charts (if data is available):
|
|||
- immediate
|
||||
- waited
|
||||
|
||||
6. **Table Select Join Issuess** in joins/s
|
||||
6. **Table Select Join Issues** in joins/s
|
||||
|
||||
- full join
|
||||
- full range join
|
||||
|
|
@ -75,7 +75,7 @@ This module will produce following charts (if data is available):
|
|||
- range check
|
||||
- scan
|
||||
|
||||
7. **Table Sort Issuess** in joins/s
|
||||
7. **Table Sort Issues** in joins/s
|
||||
|
||||
- merge passes
|
||||
- range
|
||||
|
|
@ -164,7 +164,7 @@ This module will produce following charts (if data is available):
|
|||
- updated
|
||||
- deleted
|
||||
|
||||
24. **InnoDB Buffer Pool Pagess** in pages
|
||||
24. **InnoDB Buffer Pool Pages** in pages
|
||||
|
||||
- data
|
||||
- dirty
|
||||
|
|
|
|||
|
|
@ -22,7 +22,7 @@ Following charts are drawn:
|
|||
|
||||
- active
|
||||
|
||||
3. **Current Backend Processe Usage** percentage
|
||||
3. **Current Backend Process Usage** percentage
|
||||
|
||||
- used
|
||||
- available
|
||||
|
|
|
|||
|
|
@ -31,7 +31,7 @@ It produces:
|
|||
- questions: total number of queries sent from frontends
|
||||
- slow_queries: number of queries that ran for longer than the threshold in milliseconds defined in global variable `mysql-long_query_time`
|
||||
|
||||
3. **Overall Bandwith (backends)**
|
||||
3. **Overall Bandwidth (backends)**
|
||||
|
||||
- in
|
||||
- out
|
||||
|
|
@ -45,7 +45,7 @@ It produces:
|
|||
- `4=OFFLINE_HARD`: when a server is put into OFFLINE_HARD mode, the existing connections are dropped, while new incoming connections aren't accepted either. This is equivalent to deleting the server from a hostgroup, or temporarily taking it out of the hostgroup for maintenance work
|
||||
- `-1`: Unknown status
|
||||
|
||||
5. **Bandwith (backends)**
|
||||
5. **Bandwidth (backends)**
|
||||
|
||||
- Backends
|
||||
- in
|
||||
|
|
|
|||
|
|
@ -21,7 +21,7 @@ It produces the following charts:
|
|||
1. **Syscall R/Ws** in kilobytes/s
|
||||
|
||||
- sendfile
|
||||
- recvfle
|
||||
- recvfile
|
||||
|
||||
2. **Smb2 R/Ws** in kilobytes/s
|
||||
|
||||
|
|
|
|||
|
|
@ -93,7 +93,7 @@ Please refer [Spring Boot Actuator: Production-ready Features](https://docs.spri
|
|||
- MarkSweep
|
||||
- ...
|
||||
|
||||
4. **Heap Mmeory Usage** in KB
|
||||
4. **Heap Memory Usage** in KB
|
||||
|
||||
- used
|
||||
- committed
|
||||
|
|
|
|||
|
|
@ -38,7 +38,7 @@ Netdata fully supports the statsd protocol. All statsd client libraries can be u
|
|||
|
||||
`:value` can be omitted and statsd will assume it is `1`. `|c`, `|C` and `|m` can be omitted an statsd will assume it is `|m`. So, the application may send just `name` and statsd will parse it as `name:1|m`.
|
||||
|
||||
For counters use `|c` (esty/statsd compatible) or `|C` (brubeck compatible), for meters use `|m`.
|
||||
For counters use `|c` (etsy/statsd compatible) or `|C` (brubeck compatible), for meters use `|m`.
|
||||
|
||||
Sampling rate is supported (check below).
|
||||
|
||||
|
|
@ -290,7 +290,7 @@ dimension = [pattern] METRIC NAME TYPE MULTIPLIER DIVIDER OPTIONS
|
|||
|
||||
`pattern` is a keyword. When set, `METRIC` is expected to be a Netdata simple pattern that will be used to match all the statsd metrics to be added to the chart. So, `pattern` automatically matches any number of statsd metrics, all of which will be added as separate chart dimensions.
|
||||
|
||||
`TYPE`, `MUTLIPLIER`, `DIVIDER` and `OPTIONS` are optional.
|
||||
`TYPE`, `MULTIPLIER`, `DIVIDER` and `OPTIONS` are optional.
|
||||
|
||||
`TYPE` can be:
|
||||
|
||||
|
|
|
|||
|
|
@ -172,7 +172,7 @@ And this is what you are going to get:
|
|||
|
||||
## QoS Configuration with tc
|
||||
|
||||
First, setup the tc rules in rc.local using commands to assign different DSCP markings to different classids. You can see one such example in [github issue #4563](https://github.com/netdata/netdata/issues/4563#issuecomment-455711973).
|
||||
First, setup the tc rules in rc.local using commands to assign different QoS markings to different classids. You can see one such example in [github issue #4563](https://github.com/netdata/netdata/issues/4563#issuecomment-455711973).
|
||||
|
||||
Then, map the classids to names by creating `/etc/iproute2/tc_cls`. For example:
|
||||
|
||||
|
|
|
|||
|
|
@ -514,7 +514,7 @@ section(s) you need to trace.
|
|||
|
||||
We have made the most to make Netdata crash free. If however, Netdata crashes on your system, it would be very helpful
|
||||
to provide stack traces of the crash. Without them, is will be almost impossible to find the issue (the code base is
|
||||
quite large to find such an issue by just objerving it).
|
||||
quite large to find such an issue by just observing it).
|
||||
|
||||
To provide stack traces, **you need to have Netdata compiled with debugging**. There is no need to enable any tracing
|
||||
(`debug flags`).
|
||||
|
|
|
|||
|
|
@ -100,7 +100,7 @@ Additionally, there will be the following options:
|
|||
|:-----:|:-----:|:---|
|
||||
| PATH environment variable|`auto-detected`||
|
||||
| PYTHONPATH environment variable||Used to set a custom python path|
|
||||
| enable running new plugins|`yes`|When set to `yes`, Netdata will enable detected plugins, even if they are not configured explicitly. Setting this to `no` will only enable plugins explicitly configirued in this file with a `yes`|
|
||||
| enable running new plugins|`yes`|When set to `yes`, Netdata will enable detected plugins, even if they are not configured explicitly. Setting this to `no` will only enable plugins explicitly configured in this file with a `yes`|
|
||||
| check for new plugins every|60|The time in seconds to check for new plugins in the plugins directory. This allows having other applications dynamically creating plugins for Netdata.|
|
||||
| checks|`no`|This is a debugging plugin for the internal latency|
|
||||
|
||||
|
|
@ -190,7 +190,7 @@ that is information about lines that begin with `dim`, which affect a chart's di
|
|||
You may notice some settings that begin with `dim` beneath the ones defined in the table above. These settings determine
|
||||
which dimensions appear on the given chart and how Netdata calculates them.
|
||||
|
||||
Each dimension setting has the following structure: `dim [DIMENSION ID] [OPTION] = [VALUE]`. The available options are `name`, `algorithm`, `multipler`, and `divisor`.
|
||||
Each dimension setting has the following structure: `dim [DIMENSION ID] [OPTION] = [VALUE]`. The available options are `name`, `algorithm`, `multiplier`, and `divisor`.
|
||||
|
||||
| Setting | Function |
|
||||
| :----------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
|
||||
|
|
|
|||
|
|
@ -365,7 +365,7 @@ apache logs accesses and Netdata logs them too. You can prevent Netdata from gen
|
|||
|
||||
## Troubleshooting mod_proxy
|
||||
|
||||
Make sure the requests reach Netdata, by examing `/var/log/netdata/access.log`.
|
||||
Make sure the requests reach Netdata, by examining `/var/log/netdata/access.log`.
|
||||
|
||||
1. if the requests do not reach Netdata, your apache does not forward them.
|
||||
2. if the requests reach Netdata but the URLs are wrong, you have not re-written them properly.
|
||||
|
|
|
|||
|
|
@ -65,7 +65,7 @@ collection capabilities.
|
|||
## Collect Kubernetes metrics
|
||||
|
||||
We already have a few complementary tools and collectors for monitoring the many layers of a Kubernetes cluster,
|
||||
_entirely for free_. These methods work together to help you troubleshoot performance or availablility issues across
|
||||
_entirely for free_. These methods work together to help you troubleshoot performance or availability issues across
|
||||
your k8s infrastructure.
|
||||
|
||||
- A [Helm chart](https://github.com/netdata/helmchart), which bootstraps a Netdata Agent pod on every node in your
|
||||
|
|
|
|||
|
|
@ -18,10 +18,10 @@ enable or configure a collector to gather all available metrics from your system
|
|||
## Enable a collector or its orchestrator
|
||||
|
||||
You can enable/disable collectors individually, or enable/disable entire orchestrators, using their configuration files.
|
||||
For example, you can change the behavior of the Go orchestator, or any of its collectors, by editing `go.d.conf`.
|
||||
For example, you can change the behavior of the Go orchestrator, or any of its collectors, by editing `go.d.conf`.
|
||||
|
||||
Use `edit-config` from your [Netdata config directory](/docs/configure/nodes.md#the-netdata-config-directory) to open
|
||||
the orchestrator's primary configuration file:
|
||||
the orchestrator primary configuration file:
|
||||
|
||||
```bash
|
||||
cd /etc/netdata
|
||||
|
|
@ -29,7 +29,7 @@ sudo ./edit-config go.d.conf
|
|||
```
|
||||
|
||||
Within this file, you can either disable the orchestrator entirely (`enabled: yes`), or find a specific collector and
|
||||
enable/disable it with `yes` and `no` settings. Uncomment any line you change to ensure the Netdata deamon reads it on
|
||||
enable/disable it with `yes` and `no` settings. Uncomment any line you change to ensure the Netdata daemon reads it on
|
||||
start.
|
||||
|
||||
After you make your changes, restart the Agent with `service netdata restart`.
|
||||
|
|
|
|||
|
|
@ -55,7 +55,7 @@ terms related to collecting metrics.
|
|||
|
||||
- **Modules** are a type of collector.
|
||||
- **Orchestrators** are external plugins that run and manage one or more modules. They run as independent processes.
|
||||
The Go orchestator is in active development.
|
||||
The Go orchestrator is in active development.
|
||||
- [go.d.plugin](https://learn.netdata.cloud/docs/agent/collectors/go.d.plugin/): An orchestrator for data
|
||||
collection modules written in `go`.
|
||||
- [python.d.plugin](/collectors/python.d.plugin/README.md): An orchestrator for data collection modules written in
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@ custom_edit_url: https://github.com/netdata/netdata/edit/master/docs/export/exte
|
|||
# Export metrics to external time-series databases
|
||||
|
||||
Netdata allows you to export metrics to external time-series databases with the [exporting
|
||||
engine](/exporting/README.md). This system uses a number of **connectors** to intiate connections to [more than
|
||||
engine](/exporting/README.md). This system uses a number of **connectors** to initiate connections to [more than
|
||||
thirty](#supported-databases) supported databases, including InfluxDB, Prometheus, Graphite, ElasticSearch, and much
|
||||
more.
|
||||
|
||||
|
|
|
|||
|
|
@ -10,7 +10,7 @@ performance of their web servers, and Netdata is taking important steps to make
|
|||
|
||||
By parsing web server log files with Netdata, and seeing the volume of redirects, requests, or server errors over time,
|
||||
you can better understand what's happening on your infrastructure. Too many bad requests? Maybe a recent deploy missed a
|
||||
few small SVG icons. Too many requsests? Time to batten down the hatches—it's a DDoS.
|
||||
few small SVG icons. Too many requests? Time to batten down the hatches—it's a DDoS.
|
||||
|
||||
Netdata has been capable of monitoring web log files for quite some time, thanks for the [weblog python.d
|
||||
module](/collectors/python.d.plugin/web_log/README.md), but we recently refactored this module in Go, and that effort
|
||||
|
|
|
|||
|
|
@ -53,7 +53,7 @@ size` and `dbengine multihost disk space`.
|
|||
|
||||
`page cache size` sets the maximum amount of RAM (in MiB) the database engine will use for caching and indexing.
|
||||
`dbengine multihost disk space` sets the maximum disk space (again, in MiB) the database engine will use for storing
|
||||
compressed metrics. The default settings retain about two day's worth of metris on a system collecting 2,000 metrics
|
||||
compressed metrics. The default settings retain about two day's worth of metrics on a system collecting 2,000 metrics
|
||||
every second.
|
||||
|
||||
[**See our database engine
|
||||
|
|
|
|||
|
|
@ -13,7 +13,7 @@ troubleshoot issues with your cluster.
|
|||
|
||||
Some k8s providers, like GKE (Google Kubernetes Engine), do deploy clusters bundled with monitoring capabilities, such
|
||||
as Google Stackdriver Monitoring. However, these pre-configured solutions might not offer the depth of metrics,
|
||||
customization, or integration with your perferred alerting methods.
|
||||
customization, or integration with your preferred alerting methods.
|
||||
|
||||
Without this visibility, it's like you built an entire house and _then_ smashed your way through the finished walls to
|
||||
add windows.
|
||||
|
|
@ -23,7 +23,7 @@ you actively troubleshoot anomalies or outages. Better yet, this toolkit include
|
|||
let you monitor the many layers of a Kubernetes cluster entirely for free.
|
||||
|
||||
We already have a few complementary tools and collectors for monitoring the many layers of a Kubernetes cluster,
|
||||
_entirely for free_. These methods work together to help you troubleshoot performance or availablility issues across
|
||||
_entirely for free_. These methods work together to help you troubleshoot performance or availability issues across
|
||||
your k8s infrastructure.
|
||||
|
||||
- A [Helm chart](https://github.com/netdata/helmchart), which bootstraps a Netdata Agent pod on every node in your
|
||||
|
|
|
|||
|
|
@ -31,7 +31,7 @@ directly using a keyboard, mouse, and monitor.
|
|||
Netdata helps you monitor and troubleshoot all kinds of devices and the applications they run, including IoT devices
|
||||
like the Raspberry Pi and applications like Pi-hole.
|
||||
|
||||
After a two-minute installation and with zero configuration, you'll be able to seeall of Pi-hole's metrics, including
|
||||
After a two-minute installation and with zero configuration, you'll be able to see all of Pi-hole's metrics, including
|
||||
the volume of queries, connected clients, DNS queries per type, top clients, top blocked domains, and more.
|
||||
|
||||
With Netdata installed, you can also monitor system metrics and any other applications you might be running. By default,
|
||||
|
|
@ -107,7 +107,7 @@ walkthrough of all its features. For a more expedited tour, see the [get started
|
|||
You need to manually enable Netdata's built-in [temperature sensor
|
||||
collector](https://learn.netdata.cloud/docs/agent/collectors/charts.d.plugin/sensors) to start collecting metrics.
|
||||
|
||||
> Netdata uses a few plugins to manage its [collectors](/collectors/REFERENCE.md), each using a different lanaguge: Go,
|
||||
> Netdata uses a few plugins to manage its [collectors](/collectors/REFERENCE.md), each using a different language: Go,
|
||||
> Python, Node.js, and Bash. While our Go collectors are undergoing the most active development, we still support the
|
||||
> other languages. In this case, you need to enable a temperature sensor collector that's written in Bash.
|
||||
|
||||
|
|
|
|||
|
|
@ -15,7 +15,7 @@ and performance of your infrastructure.
|
|||
One of these layers is the _process_. Every time a Linux system runs a program, it creates an independent process that
|
||||
executes the program's instructions in parallel with anything else happening on the system. Linux systems track the
|
||||
state and resource utilization of processes using the [`/proc` filesystem](https://en.wikipedia.org/wiki/Procfs), and
|
||||
Netdata is designed to hook into those metrics to create meaningul visualizations out of the box.
|
||||
Netdata is designed to hook into those metrics to create meaningful visualizations out of the box.
|
||||
|
||||
While there are a lot of existing command-line tools for tracking processes on Linux systems, such as `ps` or `top`,
|
||||
only Netdata provides dozens of real-time charts, at both per-second and event frequency, without you having to write
|
||||
|
|
@ -86,7 +86,7 @@ Linux systems:
|
|||
- Pipes open (`apps.pipes`)
|
||||
- Swap memory
|
||||
- Swap memory used (`apps.swap`)
|
||||
- Major page faults (i.e. swap activiy, `apps.major_faults`)
|
||||
- Major page faults (i.e. swap activity, `apps.major_faults`)
|
||||
- Network
|
||||
- Sockets open (`apps.sockets`)
|
||||
- eBPF file
|
||||
|
|
@ -132,7 +132,7 @@ sudo ./edit-config apps_groups.conf
|
|||
|
||||
Inside the file are lists of process names, oftentimes using wildcards (`*`), that the Netdata Agent looks for and
|
||||
groups together. For example, the Netdata Agent looks for processes starting with `mysqld`, `mariad`, `postgres`, and
|
||||
others, and groups them into `sql`. That makes sense, since all these procesess are for SQL databases.
|
||||
others, and groups them into `sql`. That makes sense, since all these processes are for SQL databases.
|
||||
|
||||
```conf
|
||||
sql: mysqld* mariad* postgres* postmaster* oracle_* ora_* sqlservr
|
||||
|
|
@ -247,7 +247,7 @@ metrics](https://user-images.githubusercontent.com/1153921/101411810-d08fb800-38
|
|||
|
||||
### Using Netdata's eBPF collector (`ebpf.plugin`)
|
||||
|
||||
Netdata's eBPF collector puts its charts in two places. Of most imporance to process monitoring are the **ebpf file**,
|
||||
Netdata's eBPF collector puts its charts in two places. Of most importance to process monitoring are the **ebpf file**,
|
||||
**ebpf syscall**, **ebpf process**, and **ebpf net** sub-sections under **Applications**, shown in the above screenshot.
|
||||
|
||||
For example, running the above workload shows the entire "story" how MySQL interacts with the Linux kernel to open
|
||||
|
|
@ -274,7 +274,7 @@ piece of data needed to discover the root cause of an incident. See our [collect
|
|||
setup](/docs/collect/enable-configure.md) doc for details.
|
||||
|
||||
[Create new dashboards](/docs/visualize/create-dashboards.md) in Netdata Cloud using charts from `apps.plugin`,
|
||||
`ebpf.plugin`, and application-specific collectors to build targeted dashboards for monitoring key procesess across your
|
||||
`ebpf.plugin`, and application-specific collectors to build targeted dashboards for monitoring key processes across your
|
||||
infrastructure.
|
||||
|
||||
Try running [Metric Correlations](https://learn.netdata.cloud/docs/cloud/insights/metric-correlations) on a node that's
|
||||
|
|
|
|||
|
|
@ -11,7 +11,7 @@ To accurately monitor the health of your systems and applications, you need to k
|
|||
strange going on. Netdata's alarm and notification systems are essential to keeping you informed.
|
||||
|
||||
Netdata comes with hundreds of pre-configured alarms that don't require configuration. They were designed by our
|
||||
community of system adminstrators to cover the most important parts of production systems, so, in many cases, you won't
|
||||
community of system administrators to cover the most important parts of production systems, so, in many cases, you won't
|
||||
need to edit them.
|
||||
|
||||
Luckily, Netdata's alarm and notification system are incredibly adaptable to your infrastructure's unique needs.
|
||||
|
|
|
|||
|
|
@ -34,7 +34,7 @@ underlying architecture.
|
|||
|
||||
By default, Netdata collects a lot of metrics every second using any number of discrete collector. Collectors, in turn,
|
||||
are organized and manged by plugins. **Internal** plugins collect system metrics, **external** plugins collect
|
||||
non-system metrics, and **orchestrator** plugins group individal collectors together based on the programming language
|
||||
non-system metrics, and **orchestrator** plugins group individual collectors together based on the programming language
|
||||
they were built in.
|
||||
|
||||
These modules are primarily written in [Go](https://learn.netdata.cloud/docs/agent/collectors/go.d.plugin/) (`go.d`) and
|
||||
|
|
|
|||
|
|
@ -76,7 +76,7 @@ following:
|
|||
</html>
|
||||
```
|
||||
|
||||
Try visiting `http://HOST:19999/custom-dashbord.html` in your browser.
|
||||
Try visiting `http://HOST:19999/custom-dashboard.html` in your browser.
|
||||
|
||||
If you get a blank page with this text: `Access to file is not permitted: /usr/share/netdata/web/custom-dashboard.html`.
|
||||
You can fix this error by changing the dashboard file's permissions to make it owned by the `netdata` user.
|
||||
|
|
|
|||
|
|
@ -143,7 +143,7 @@ Add the following section to the file:
|
|||
```
|
||||
|
||||
[Restart](/docs/getting-started.md#start-stop-and-restart-netdata) Netdata to enable the MongoDB exporting connector.
|
||||
Click on the **Netdata Montioring** menu and check out the **exporting my mongo instance** sub-menu. You should start
|
||||
Click on the **Netdata Monitoring** menu and check out the **exporting my mongo instance** sub-menu. You should start
|
||||
seeing these charts fill up with data about the exporting process!
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -65,7 +65,7 @@ Check out [Nginx's installation
|
|||
instructions](https://docs.nginx.com/nginx/admin-guide/installing-nginx/installing-nginx-open-source/) for details on
|
||||
other Linux distributions.
|
||||
|
||||
Certbot is a tool to help you create and renew certiciate+key pairs for your domain. Visit their
|
||||
Certbot is a tool to help you create and renew certificate+key pairs for your domain. Visit their
|
||||
[instructions](https://certbot.eff.org/instructions) to get a detailed installation process for your operating system.
|
||||
|
||||
### Fully qualified domain name
|
||||
|
|
|
|||
|
|
@ -120,7 +120,7 @@ calls to open/close files, call functions like `do_fork`, IO activity on the VFS
|
|||
See the [eBPF collector documentation](/collectors/ebpf.plugin/README.md#integration-with-appsplugin) for the full list
|
||||
of per-application charts.
|
||||
|
||||
Let's show some examples of how you can first identify normal eBPF patterns, then use that knowledge to idenfity
|
||||
Let's show some examples of how you can first identify normal eBPF patterns, then use that knowledge to identify
|
||||
anomalies in a few simulated scenarios.
|
||||
|
||||
For example, the following screenshot shows the number of open files, failures to open files, and closed files on a
|
||||
|
|
@ -252,7 +252,7 @@ Debugging and troubleshooting an application takes a special combination of prac
|
|||
Netdata's eBPF metrics to back you up, you can rest assured that you see every minute detail of how your application
|
||||
interacts with the Linux kernel.
|
||||
|
||||
If you're still trying to wrap your head aroud what we offer, be sure to read up on our accompanying documentation and
|
||||
If you're still trying to wrap your head around what we offer, be sure to read up on our accompanying documentation and
|
||||
other resources on eBPF monitoring with Netdata:
|
||||
|
||||
- [eBPF collector](/collectors/ebpf.plugin/README.md)
|
||||
|
|
|
|||
|
|
@ -131,7 +131,7 @@ to IP addresses within the `160.1.x.x` range and that reverse DNS is setup for t
|
|||
|
||||
#### Use an authenticating web server in proxy mode
|
||||
|
||||
Use one web server to provide authentication in front of **all your Netdata servers**. So, you will be accessing all your Netdata with URLs like `http://{HOST}/netdata/{NETDATA_HOSTNAME}/` and authentication will be shared among all of them (you will sign-in once for all your servers). Instructions are provided on how to set the proxy configuration to have Netdata run behind [nginx](Running-behind-nginx.md), [Apache](Running-behind-apache.md), [lighthttpd](Running-behind-lighttpd.md) and [Caddy](Running-behind-caddy.md).
|
||||
Use one web server to provide authentication in front of **all your Netdata servers**. So, you will be accessing all your Netdata with URLs like `http://{HOST}/netdata/{NETDATA_HOSTNAME}/` and authentication will be shared among all of them (you will sign-in once for all your servers). Instructions are provided on how to set the proxy configuration to have Netdata run behind [nginx](Running-behind-nginx.md), [Apache](Running-behind-apache.md), [lighttpd](Running-behind-lighttpd.md) and [Caddy](Running-behind-caddy.md).
|
||||
|
||||
To use this method, you should firewall protect all your Netdata servers, so that only the web server IP will allowed to directly access Netdata. To do this, run this on each of your servers (or use your firewall manager):
|
||||
|
||||
|
|
@ -212,7 +212,7 @@ If sending this information to the central Netdata registry violates your securi
|
|||
Starting with v1.12, Netdata collects anonymous usage information by default and sends it to Google Analytics. Read
|
||||
about the information collected, and learn how to-opt, on our [anonymous statistics](anonymous-statistics.md) page.
|
||||
|
||||
The usage statistics are _vital_ for us, as we use them to discover bugs and priortize new features. We thank you for
|
||||
The usage statistics are _vital_ for us, as we use them to discover bugs and prioritize new features. We thank you for
|
||||
_actively_ contributing to Netdata's future.
|
||||
|
||||
## Netdata directories
|
||||
|
|
|
|||
|
|
@ -92,7 +92,7 @@ X seconds (though, it can send them per second if you need it to).
|
|||
|
||||
## Configuration
|
||||
|
||||
Here are the configruation blocks for every supported connector. Your current `exporting.conf` file may look a little
|
||||
Here are the configuration blocks for every supported connector. Your current `exporting.conf` file may look a little
|
||||
different.
|
||||
|
||||
You can configure each connector individually using the available [options](#options). The
|
||||
|
|
@ -234,7 +234,7 @@ Configure individual connectors and override any global settings with the follow
|
|||
|
||||
- `prefix = Netdata`, is the prefix to add to all metrics.
|
||||
|
||||
- `update every = 10`, is the number of seconds between sending data to the external datanase. Netdata will add some
|
||||
- `update every = 10`, is the number of seconds between sending data to the external database. Netdata will add some
|
||||
randomness to this number, to prevent stressing the external server when many Netdata servers send data to the same
|
||||
database. This randomness does not affect the quality of the data, only the time they are sent.
|
||||
|
||||
|
|
@ -266,7 +266,7 @@ Configure individual connectors and override any global settings with the follow
|
|||
- `send configured labels = yes | no` controls if labels defined in the `[host labels]` section in `netdata.conf`
|
||||
should be sent to the external database
|
||||
|
||||
- `send automatic labels = yes | no` controls if automatially created labels, like `_os_name` or `_architecture`
|
||||
- `send automatic labels = yes | no` controls if automatically created labels, like `_os_name` or `_architecture`
|
||||
should be sent to the external database
|
||||
|
||||
> Starting from Netdata v1.20 the host tags (defined in the `[backend]` section of `netdata.conf`) are parsed in
|
||||
|
|
|
|||
|
|
@ -39,7 +39,7 @@ TimescaleDB.
|
|||
Finally, another member of Netdata's community has built a project that quickly launches Netdata, TimescaleDB, and
|
||||
Grafana in easy-to-manage Docker containers. Rune Juhl Jacobsen's
|
||||
[project](https://github.com/runejuhl/grafana-timescaledb) uses a `Makefile` to create everything, which makes it
|
||||
perferct for testing and experimentation.
|
||||
perfect for testing and experimentation.
|
||||
|
||||
## Netdata↔TimescaleDB in action
|
||||
|
||||
|
|
|
|||
|
|
@ -21,7 +21,7 @@ You can configure the Agent's health watchdog service by editing files in two lo
|
|||
altogether, run health checks more or less often, and more. See [daemon
|
||||
configuration](/daemon/config/README.md#health-section-options) for a table of all the available settings, their
|
||||
default values, and what they control.
|
||||
- The individual `.conf` files in `health.d/`. These health entitiy files are organized by the type of metric they are
|
||||
- The individual `.conf` files in `health.d/`. These health entity files are organized by the type of metric they are
|
||||
performing calculations on or their associated collector. You should edit these files using the `edit-config`
|
||||
script. For example: `sudo ./edit-config health.d/cpu.conf`.
|
||||
|
||||
|
|
@ -241,7 +241,7 @@ A `calc` is designed to apply some calculation to the values or variables availa
|
|||
calculation will be made available at the `$this` variable, overwriting the value from your `lookup`, to use in warning
|
||||
and critical expressions.
|
||||
|
||||
When paired with `lookup`, `calc` will perform the calculation just after `lookup` has retreived a value from Netdata's
|
||||
When paired with `lookup`, `calc` will perform the calculation just after `lookup` has retrieved a value from Netdata's
|
||||
database.
|
||||
|
||||
You can use `calc` without `lookup` if you are using [other available variables](#variables).
|
||||
|
|
@ -340,7 +340,7 @@ delay: [[[up U] [down D] multiplier M] max X]
|
|||
will delay the notification by 1 minute. This is used to prevent notifications for flapping
|
||||
alarms. The default `D` is zero.
|
||||
|
||||
- `mutliplier M` multiplies `U` and `D` when an alarm changes state, while a notification is
|
||||
- `multiplier M` multiplies `U` and `D` when an alarm changes state, while a notification is
|
||||
delayed. The default multiplier is `1.0`.
|
||||
|
||||
- `max X` defines the maximum absolute notification delay an alarm may get. The default `X`
|
||||
|
|
|
|||
|
|
@ -29,7 +29,7 @@ The easiest way to install Alerta is to use the Docker image available
|
|||
on [Docker hub][1]. Alternatively, follow the ["getting started"][2]
|
||||
tutorial to deploy Alerta to an Ubuntu server. More advanced
|
||||
configurations are out os scope of this tutorial but information
|
||||
about different deployment scenaries can be found in the [docs][3].
|
||||
about different deployment scenarios can be found in the [docs][3].
|
||||
|
||||
[1]: https://hub.docker.com/r/alerta/alerta-web/
|
||||
|
||||
|
|
@ -86,7 +86,7 @@ We can test alarms using the standard approach:
|
|||
|
||||
Note: Netdata will send 3 alarms, and because last alarm is "CLEAR"
|
||||
you will not see them in main Alerta page, you need to select to see
|
||||
"closed" alarma in top-right lookup. A little change in `alarm-notify.sh`
|
||||
"closed" alarm in top-right lookup. A little change in `alarm-notify.sh`
|
||||
that let us test each state one by one will be useful.
|
||||
|
||||
For more information see <https://docs.alerta.io>
|
||||
|
|
|
|||
|
|
@ -37,7 +37,7 @@ Once that's done, you're ready to go and can specify the desired topic ARN as a
|
|||
Notes:
|
||||
|
||||
- Netdata's native email notification support is far better in almost all respects than it's support through Amazon SNS. If you want email notifications, use the native support, not SNS.
|
||||
- If you need to change the notification format for SNS notifications, you can do so by specifying the format in `AWSSNS_MESSAGE_FORMAT` in the configuration. This variable supports all the same vairiables you can use in custom notifications.
|
||||
- If you need to change the notification format for SNS notifications, you can do so by specifying the format in `AWSSNS_MESSAGE_FORMAT` in the configuration. This variable supports all the same variables you can use in custom notifications.
|
||||
- While Amazon SNS supports sending differently formatted messages for different delivery methods, Netdata does not currently support this functionality.
|
||||
|
||||
[](<>)
|
||||
|
|
|
|||
|
|
@ -55,7 +55,7 @@ sendmail="/usr/bin/msmtp"
|
|||
(sudo) su -s /bin/bash netdata
|
||||
```
|
||||
- Configure `~/.msmtprc` as shown [in the documentation](https://marlam.de/msmtp/documentation/).
|
||||
- Finaly set the appropriate permissions on the `.msmtprc` file :
|
||||
- Finally set the appropriate permissions on the `.msmtprc` file :
|
||||
```sh
|
||||
chmod 600 ~/.msmtprc
|
||||
```
|
||||
|
|
|
|||
|
|
@ -29,7 +29,7 @@ Set the path for `nc` in `/etc/netdata/health_alarm_notify.conf` (to edit it on
|
|||
nc="/usr/bin/nc"
|
||||
```
|
||||
|
||||
2. Αn `IRC_NETWORK` to which your preffered channels belong to.
|
||||
2. Αn `IRC_NETWORK` to which your preferred channels belong to.
|
||||
3. One or more channels ( `DEFAULT_RECIPIENT_IRC` ) to post the messages to.
|
||||
4. An `IRC_NICKNAME` and an `IRC_REALNAME` to identify in IRC.
|
||||
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ custom_edit_url: https://github.com/netdata/netdata/edit/master/health/notificat
|
|||
# Prowl
|
||||
|
||||
[Prowl](https://www.prowlapp.com/) is a push notification service for iOS devices. Netdata
|
||||
supprots delivering notifications to iOS devices through Prowl.
|
||||
supports delivering notifications to iOS devices through Prowl.
|
||||
|
||||
Because of how Netdata integrates with Prowl, there is a hard limit of
|
||||
at most 1000 notifications per hour (starting from the first notification
|
||||
|
|
@ -20,7 +20,7 @@ the alert, directly to the chart that it triggered on.
|
|||
|
||||
## configuration
|
||||
|
||||
To use this, you will need a Prowl API key, which can be rquested through
|
||||
To use this, you will need a Prowl API key, which can be requested through
|
||||
the Prowl website after registering.
|
||||
|
||||
Once you have an API key, simply specify that as a recipient for Prowl
|
||||
|
|
|
|||
|
|
@ -47,6 +47,6 @@ role_recipients_rocketchat[webmaster]="marketing development"
|
|||
```
|
||||
|
||||
The keywords `systems`, `databases`, `marketing`, `development` are RocketChat channels (they should already exist).
|
||||
Both public and private channels can be used, even if they differ from the channel configured in yout RocketChat incomming webhook.
|
||||
Both public and private channels can be used, even if they differ from the channel configured in your RocketChat incoming webhook.
|
||||
|
||||
[](<>)
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@ custom_edit_url: https://github.com/netdata/netdata/edit/master/health/notificat
|
|||
|
||||
# Send notifications to StackPulse
|
||||
|
||||
[StackPulse](https://stackpulse.com/) is a software-as-a-service platform for site reliablility engineering.
|
||||
[StackPulse](https://stackpulse.com/) is a software-as-a-service platform for site reliability engineering.
|
||||
It helps SREs, DevOps Engineers and Software Developers reduce toil and alert fatigue while improving reliability of
|
||||
software services by managing, analyzing and automating incident response activities.
|
||||
|
||||
|
|
@ -18,7 +18,7 @@ Sending Netdata alarm notifications to StackPulse allows you to create smart aut
|
|||
- Performing triage actions and analyzing their results
|
||||
- Orchestrating incident management and notification flows
|
||||
- Performing automatic and semi-automatic remediation actions
|
||||
- Analzying incident data and remediation patterns to improve reliability of your services
|
||||
- Analyzing incident data and remediation patterns to improve reliability of your services
|
||||
|
||||
To send the notification you need:
|
||||
|
||||
|
|
|
|||
|
|
@ -19,7 +19,7 @@ have complete visibility over the range of support.
|
|||
- **Family**: The family that the OS belongs to
|
||||
- **CI: Smoke Testing**: Smoke testing has been implemented on our CI, to prevent broken code reaching our users
|
||||
- **CI: Testing**: Testing has been implemented to prevent broken or problematic code reaching our users
|
||||
- **CD**: Continious deployment support has been fully enabled for this operating system
|
||||
- **CD**: Continuous deployment support has been fully enabled for this operating system
|
||||
- **.DEB**: We provide a `.DEB` package for that particular operating system
|
||||
- **.RPM**: We provide a `.RPM` package for that particular operating system
|
||||
- **Installer**: Running netdata from source, using our installer, is working for this operating system
|
||||
|
|
|
|||
|
|
@ -15,7 +15,7 @@ Starting with v1.12, Netdata collects anonymous usage information by default and
|
|||
about the information collected, and learn how to-opt, on our [anonymous statistics](/docs/anonymous-statistics.md)
|
||||
page.
|
||||
|
||||
The usage statistics are _vital_ for us, as we use them to discover bugs and priortize new features. We thank you for
|
||||
The usage statistics are _vital_ for us, as we use them to discover bugs and prioritize new features. We thank you for
|
||||
_actively_ contributing to Netdata's future.
|
||||
|
||||
## Limitations running the Agent in Docker
|
||||
|
|
@ -107,7 +107,7 @@ You can control how the health checks run by using the environment variable `NET
|
|||
correctly or not. This is sufficient to ensure that Netdata did not
|
||||
hang during startup, but does not provide a rigorous verification
|
||||
that the daemon is collecting data or is otherwise usable.
|
||||
- If set to anything else, the health check will treat the vaule as a
|
||||
- If set to anything else, the health check will treat the value as a
|
||||
URL to check for a 200 status code on. In most cases, this should
|
||||
start with `http://localhost:19999/` to check the agent running in
|
||||
the container.
|
||||
|
|
|
|||
|
|
@ -11,7 +11,7 @@ Netdata Agent on your node.
|
|||
|
||||
Before you try reinstalling Netdata, figure out which [installation method you
|
||||
used](/packaging/installer/UPDATE.md#determine-which-installation-method-you-used) if you do not already know. This will
|
||||
deterimine the reinstallation method.
|
||||
determine the reinstallation method.
|
||||
|
||||
## One-line installer script (`kickstart.sh`)
|
||||
|
||||
|
|
|
|||
|
|
@ -26,7 +26,7 @@ most installations, this is `/etc/netdata`.
|
|||
Use `cd` to navigate to the Netdata config directory, then use `ls -a` to look for a file called `.environment`.
|
||||
|
||||
- If the `.environment` file _does not_ exist, reinstall with your [package manager](#deb-or-rpm-packages).
|
||||
- If the `.environtment` file _does_ exist, check its contents with `less .environment`.
|
||||
- If the `.environment` file _does_ exist, check its contents with `less .environment`.
|
||||
- If `IS_NETDATA_STATIC_BINARY` is `"yes"`, update using the [pre-built static
|
||||
binary](#pre-built-static-binary-for-64-bit-systems-kickstart-static64sh).
|
||||
- In all other cases, update using the [one-line installer script](#one-line-installer-script-kickstartsh).
|
||||
|
|
@ -118,7 +118,7 @@ installation instructions](/packaging/docker/README.md#create-a-new-netdata-agen
|
|||
|
||||
## macOS
|
||||
|
||||
If you installed Netdata on your macOS system using Homebrew, you can explictly request an update:
|
||||
If you installed Netdata on your macOS system using Homebrew, you can explicitly request an update:
|
||||
|
||||
```bash
|
||||
brew upgrade netdata
|
||||
|
|
|
|||
|
|
@ -89,7 +89,7 @@ to create a new firewall rule.
|
|||
#### Amazon Web Services (AWS) / EC2
|
||||
|
||||
Sign in to the [AWS console](https://console.aws.amazon.com/) and navigate to the EC2 dashboard. Click on the **Security
|
||||
Groups** link in the naviagtion, beneath the **Network & Security** heading. Find the Security Group your instance
|
||||
Groups** link in the navigation, beneath the **Network & Security** heading. Find the Security Group your instance
|
||||
belongs to, and either right-click on it or click the **Actions** button above to see a dropdown menu with **Edit
|
||||
inbound rules**.
|
||||
|
||||
|
|
|
|||
|
|
@ -80,7 +80,7 @@ The `netdata-updater.sh` script will update your Agent.
|
|||
| `--dont-wait` | Run installation in non-interactive mode|
|
||||
| `--auto-update` or `-u` | Install netdata-updater in cron to update netdata automatically once per day|
|
||||
| `--stable-channel` | Use packages from GitHub release pages instead of GCS (nightly updates). This results in less frequent updates|
|
||||
| `--nightly-channel` | Use most recent nightly udpates instead of GitHub releases. This results in more frequent updates|
|
||||
| `--nightly-channel` | Use most recent nightly updates instead of GitHub releases. This results in more frequent updates|
|
||||
| `--disable-go` | Disable installation of go.d.plugin|
|
||||
| `--disable-ebpf` | Disable eBPF Kernel plugin (Default: enabled)|
|
||||
| `--disable-cloud` | Disable all Netdata Cloud functionality|
|
||||
|
|
@ -103,6 +103,6 @@ The `netdata-updater.sh` script will update your Agent.
|
|||
| `--disable-lto` | Disable Link-Time-Optimization. Default: enabled|
|
||||
| `--disable-x86-sse` | Disable SSE instructions. By default SSE optimizations are enabled|
|
||||
| `--zlib-is-really-here` or `--libs-are-really-here` | If you get errors about missing zlib or libuuid but you know it is available, you might have a broken pkg-config. Use this option to proceed without checking pkg-config|
|
||||
|`--disable-telemetry` | Use this flag to opt-out from our anonymous telemetry progam. (DO_NOT_TRACK=1)|
|
||||
|`--disable-telemetry` | Use this flag to opt-out from our anonymous telemetry program. (DO_NOT_TRACK=1)|
|
||||
|
||||
[](<>)
|
||||
|
|
|
|||
|
|
@ -37,7 +37,7 @@ The `kickstart.sh` script does the following after being downloaded and run:
|
|||
added.
|
||||
- Installs `netdata-updater.sh` to `cron.daily` to enable automatic updates, unless you added the `--no-updates`
|
||||
option.
|
||||
- Prints a message about whether the insallation succeeded for failed for QA purposes.
|
||||
- Prints a message about whether the installation succeeded for failed for QA purposes.
|
||||
|
||||
If your shell fails to handle the above one-liner, you can download and run the `kickstart-static64.sh` script manually.
|
||||
|
||||
|
|
@ -65,7 +65,7 @@ your installation. Here are a few important parameters:
|
|||
Netdata better.
|
||||
- `--no-updates`: Prevent automatic updates of any kind.
|
||||
- `--reinstall`: If an existing installation is detected, reinstall instead of attempting to update it. Note
|
||||
that this cannot be used to switch betwen installation types.
|
||||
that this cannot be used to switch between installation types.
|
||||
- `--local-files`: Used for [offline installations](/packaging/installer/methods/offline.md). Pass four file paths:
|
||||
the Netdata tarball, the checksum file, the go.d plugin tarball, and the go.d plugin config tarball, to force
|
||||
kickstart run the process using those files. This option conflicts with the `--stable-channel` option. If you set
|
||||
|
|
@ -73,7 +73,7 @@ your installation. Here are a few important parameters:
|
|||
|
||||
## Verify script integrity
|
||||
|
||||
To use `md5sum` to verify the intregity of the `kickstart-static64.sh` script you will download using the one-line
|
||||
To use `md5sum` to verify the integrity of the `kickstart-static64.sh` script you will download using the one-line
|
||||
command above, run the following:
|
||||
|
||||
```bash
|
||||
|
|
|
|||
|
|
@ -56,7 +56,7 @@ installation. Here are a few important parameters:
|
|||
|
||||
## Verify script integrity
|
||||
|
||||
To use `md5sum` to verify the intregity of the `kickstart.sh` script you will download using the one-line command above,
|
||||
To use `md5sum` to verify the integrity of the `kickstart.sh` script you will download using the one-line command above,
|
||||
run the following:
|
||||
|
||||
```bash
|
||||
|
|
|
|||
|
|
@ -89,7 +89,7 @@ applications](https://github.com/netdata/helmchart#service-discovery-and-support
|
|||
by our [generic Prometheus collector](https://learn.netdata.cloud/docs/agent/collectors/go.d.plugin/modules/prometheus).
|
||||
|
||||
If you haven't changed listening ports, image names, or other defaults, service discovery should find your pods, create
|
||||
the proper configurations based on the service that pod runs, and begin monitoring them immediately after depolyment.
|
||||
the proper configurations based on the service that pod runs, and begin monitoring them immediately after deployment.
|
||||
|
||||
However, if you have changed some of these defaults, you need to copy a file from the Netdata Helm chart repository,
|
||||
make your edits, and pass the changed file to `helm install`/`helm upgrade`.
|
||||
|
|
@ -188,7 +188,7 @@ Cloud](https://user-images.githubusercontent.com/1153921/94497340-c1f49880-01ab-
|
|||
## Update/reinstall the Netdata Helm chart
|
||||
|
||||
If you update the Helm chart's configuration, run `helm upgrade` to redeploy your Netdata service, replacing `netdata`
|
||||
with the name of the release, if you changed it upon installtion:
|
||||
with the name of the release, if you changed it upon installation:
|
||||
|
||||
```bash
|
||||
helm upgrade netdata netdata/netdata
|
||||
|
|
@ -203,7 +203,7 @@ Check out our [infrastructure](/docs/quickstart/infrastructure.md) for details a
|
|||
and learn more about [configuring the Netdata Agent](/docs/configure/nodes.md) to better understand the settings you
|
||||
might be interested in changing.
|
||||
|
||||
To futher configure Netdata for your cluster, see our [Helm chart repository](https://github.com/netdata/helmchart) and
|
||||
To further configure Netdata for your cluster, see our [Helm chart repository](https://github.com/netdata/helmchart) and
|
||||
the [service discovery repository](https://github.com/netdata/agent-service-discovery/).
|
||||
|
||||
[](<>)
|
||||
|
|
|
|||
|
|
@ -32,7 +32,7 @@ and other operating systems and is regularly tested. You can find this tool [her
|
|||
|
||||
- **Debian** Linux and its derivatives (including **Ubuntu**, **Mint**)
|
||||
|
||||
- **Redhat Enterprise Linux** and its derivatives (including **Fedora**, **CentOS**, **Amazon Machine Image**)
|
||||
- **Red Hat Enterprise Linux** and its derivatives (including **Fedora**, **CentOS**, **Amazon Machine Image**)
|
||||
- Please note that for RHEL/CentOS you need
|
||||
[EPEL](http://www.tecmint.com/how-to-enable-epel-repository-for-rhel-centos-6-5/).
|
||||
In addition, RHEL/CentOS version 6 also need
|
||||
|
|
@ -147,7 +147,7 @@ And install the minimum required dependencies.
|
|||
### CentOS / RHEL 8.x
|
||||
|
||||
For CentOS / RHEL 8.x a lot of development packages have moved out into their
|
||||
own separate repositories. Some other dependeicies are either missing completely
|
||||
own separate repositories. Some other dependencies are either missing completely
|
||||
or have to be sourced by 3rd-parties.
|
||||
|
||||
CentOS 8.x:
|
||||
|
|
|
|||
|
|
@ -28,8 +28,8 @@ package downloads.
|
|||
If you are using such a setup, there are a couple of ways to work around this:
|
||||
|
||||
- Configure your proxy to automatically pass through HTTPS connections without caching them. This is the simplest
|
||||
solution, but means that downloads of Netdata pacakges will not be cached.
|
||||
- Mirror the respository locally on your proxy system, and use that mirror when installing on other systems. This
|
||||
solution, but means that downloads of Netdata packages will not be cached.
|
||||
- Mirror the repository locally on your proxy system, and use that mirror when installing on other systems. This
|
||||
requires more setup and more disk space on the caching host, but it lets you cache the packages locally.
|
||||
- Some specific caching proxies may have alternative configuration options to deal with these issues. Find
|
||||
such options in their documentation.
|
||||
|
|
|
|||
|
|
@ -48,7 +48,7 @@ pkg add http://pkg.freebsd.org/FreeBSD:11:amd64/latest/All/py37-yaml-5.3.1.txz
|
|||
> Python from the FreeBSD repository as instructed above.
|
||||
|
||||
> ⚠️ If you are using the `apcupsd` collector, you need to make sure that apcupsd is up before starting Netdata.
|
||||
> Otherwise a infinitely running `cat` process triggered by the default activated apcuspd charts plugin will eat up CPU
|
||||
> Otherwise a infinitely running `cat` process triggered by the default activated apcupsd charts plugin will eat up CPU
|
||||
> and RAM (`/tmp/.netdata-charts.d-*/run-*`). This also applies to `OPNsense`.
|
||||
|
||||
## Install Netdata
|
||||
|
|
|
|||
|
|
@ -62,9 +62,9 @@ Netdata Cloud functionality. To prepare this library for the build system:
|
|||
of `packaging/mosquitto.version` in your Netdata sources.
|
||||
2. Obtain the sources for that version by either:
|
||||
- Navigating to https://github.com/netdata/mosquitto/releases and
|
||||
donwloading and unpacking the source code archive for that release.
|
||||
downloading and unpacking the source code archive for that release.
|
||||
- Cloning the repository with `git` and checking out the required tag.
|
||||
3. If building on a platfom other than Linux, prepare the mosquitto
|
||||
3. If building on a platform other than Linux, prepare the mosquitto
|
||||
sources by running `cmake -D WITH_STATIC_LIBRARIES:boolean=YES .` in
|
||||
the mosquitto source directory.
|
||||
4. Build mosquitto by running `make -C lib` in the mosquitto source directory.
|
||||
|
|
@ -89,9 +89,9 @@ library for the build system:
|
|||
of `packaging/libwebsockets.version` in your Netdata sources.
|
||||
2. Obtain the sources for that version by either:
|
||||
- Navigating to https://github.com/warmcat/libwebsockets/releases and
|
||||
donwloading and unpacking the source code archive for that release.
|
||||
downloading and unpacking the source code archive for that release.
|
||||
- Cloning the repository with `git` and checking out the required tag.
|
||||
3. Prepare the libweboskcets sources by running `cmake -D
|
||||
3. Prepare the libwebsockets sources by running `cmake -D
|
||||
LWS_WITH_SOCKS5:bool=ON .` in the libwebsockets source directory.
|
||||
4. Build libwebsockets by running `make` in the libwebsockets source
|
||||
directory.
|
||||
|
|
@ -112,7 +112,7 @@ you can do the following to prepare a copy for the build system:
|
|||
1. Verify the tag that Netdata expects to be used by checking the contents
|
||||
of `packaging/jsonc.version` in your Netdata sources.
|
||||
2. Obtain the sources for that version by either:
|
||||
- Navigating to https://github.com/json-c/json-c and donwloading
|
||||
- Navigating to https://github.com/json-c/json-c and downloading
|
||||
and unpacking the source code archive for that release.
|
||||
- Cloning the repository with `git` and checking out the required tag.
|
||||
3. Prepare the JSON-C sources by running `cmake -DBUILD_SHARED_LIBS=OFF .`
|
||||
|
|
@ -201,7 +201,7 @@ NPM. Once you have the required tools, do the following:
|
|||
1. Verify the release version that Netdata expects to be used by checking
|
||||
the contents of `packaging/dashboard.version` in your Netdata sources.
|
||||
2. Obtain the sources for that version by either:
|
||||
- Navigating to https://github.com/netdata/dashboard and donwloading
|
||||
- Navigating to https://github.com/netdata/dashboard and downloading
|
||||
and unpacking the source code archive for that release.
|
||||
- Cloning the repository with `git` and checking out the required tag.
|
||||
3. Run `npm install` in the dashboard source tree.
|
||||
|
|
@ -216,7 +216,7 @@ and are developed in a separate repository from the mian Netdata code.
|
|||
An installation without these collectors is still usable, but will be
|
||||
unable to collect metrics for a number of network services the system
|
||||
may be providing. You can either install a pre-built copy of these
|
||||
eollectors, or build them locally.
|
||||
collectors, or build them locally.
|
||||
|
||||
#### Installing the pre-built Go collectors
|
||||
|
||||
|
|
@ -229,7 +229,7 @@ we officially support. To use one of these:
|
|||
required release, and download the `go.d.plugin-*.tar.gz` file
|
||||
for your system type and CPu architecture and the `config.tar.gz`
|
||||
configuration file archive.
|
||||
3. Extract the `go.d.plugin-*.tar.gz` archive into a temprary
|
||||
3. Extract the `go.d.plugin-*.tar.gz` archive into a temporary
|
||||
location, and then copy the single file in the archive to
|
||||
`/usr/libexec/netdata/plugins.d` or the equivalent location for your
|
||||
build of Netdata and rename it to `go.d.plugin`.
|
||||
|
|
@ -246,12 +246,12 @@ newer. Once you have the required tools, do the following:
|
|||
1. Verify the release version that Netdata expects to be used by checking
|
||||
the contents of `packaging/go.d.version` in your Netdata sources.
|
||||
2. Obtain the sources for that version by either:
|
||||
- Navigating to https://github.com/netdata/go.d.plugin and donwloading
|
||||
- Navigating to https://github.com/netdata/go.d.plugin and downloading
|
||||
and unpacking the source code archive for that release.
|
||||
- Cloning the repository with `git` and checking out the required tag.
|
||||
3. Run `make` in the go.d.plugin source tree.
|
||||
4. Copy `bin/godplugin` to `/usr/libexec/netdata/plugins.d` or th
|
||||
eequivalent location for your build of Netdata and rename it to
|
||||
equivalent location for your build of Netdata and rename it to
|
||||
`go.d.plugin`.
|
||||
5. Copy the contents of the `config` directory to `/etc/netdata` or the
|
||||
equivalent location for your build of Netdata.
|
||||
|
|
@ -274,7 +274,7 @@ using glibc or musl. To use one of these:
|
|||
the contents of `packaging/ebpf.version` in your Netdata sources.
|
||||
2. Go to https://github.com/netdata/kernel-collector/releases, select the
|
||||
required release, and download the `netdata-kernel-collector-*.tar.xz`
|
||||
file for the libc variant your system uses (eithe rmusl or glibc).
|
||||
file for the libc variant your system uses (either rmusl or glibc).
|
||||
3. Extract the contents of the archive to a temporary location, and then
|
||||
copy all of the `.o` and `.so.*` files and the contents of the `library/`
|
||||
directory to `/usr/libexec/netdata/plugins.d` or the equivalent location
|
||||
|
|
|
|||
|
|
@ -22,7 +22,7 @@ This page tracks the package maintainers for Netdata, for various operating syst
|
|||
| Debian | Release | @lhw @FedericoCeratto | [netdata @ debian](http://salsa.debian.org/debian/netdata) |
|
||||
| Slackware | Release | @willysr | [netdata @ slackbuilds](https://slackbuilds.org/repository/14.2/system/netdata/) |
|
||||
| Ubuntu | | | |
|
||||
| Red Hat / Fedora / Centos | | | |
|
||||
| Red Hat / Fedora / CentOS | | | |
|
||||
| SUSE SLE / openSUSE Tumbleweed & Leap | | | [netdata @ SUSE OpenBuildService](https://software.opensuse.org/package/netdata) |
|
||||
|
||||
---
|
||||
|
|
|
|||
|
|
@ -49,6 +49,6 @@ If Netdata crashes, `valgrind` will print a stack trace of the issue. Open a git
|
|||
|
||||
To stop Netdata while it runs under `valgrind`, press Control-C on the console.
|
||||
|
||||
> If you omit the parameter `--undef-value-errors=no` to valgrind, you will get hundreds of errors about conditional jumps that depend on uninitialized values. This is normal. Valgrind has heuristics to prevent it from printing such errors for system libraries, but for the static Netdata binary, all the required libraries are built into Netdata. So, valgrind cannot appply its heuristics and prints them.
|
||||
> If you omit the parameter `--undef-value-errors=no` to valgrind, you will get hundreds of errors about conditional jumps that depend on uninitialized values. This is normal. Valgrind has heuristics to prevent it from printing such errors for system libraries, but for the static Netdata binary, all the required libraries are built into Netdata. So, valgrind cannot apply its heuristics and prints them.
|
||||
|
||||
[](<>)
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ Usage
|
|||
|
||||
1. Define a structure that will be used to share user state across calls
|
||||
1. Initialize the parser using `parser_init`
|
||||
2. Register keywords and assosiated callback function using `parser_add_keyword`
|
||||
2. Register keywords and associated callback function using `parser_add_keyword`
|
||||
3. Register actions on the keywords
|
||||
4. Start a loop until EOF
|
||||
1. Fetch the next line using `parser_next`
|
||||
|
|
@ -79,11 +79,11 @@ Input
|
|||
* PARSER_RC_ERROR -- Callback failed, exit
|
||||
|
||||
Output
|
||||
- The correspoding keyword and callback will be registered
|
||||
- The corresponding keyword and callback will be registered
|
||||
|
||||
Returns
|
||||
- 0 maximum callbacks already registered for this keyword
|
||||
- > 0 which is the number of callbacks assosiated with this keyword.
|
||||
- > 0 which is the number of callbacks associated with this keyword.
|
||||
|
||||
|
||||
----
|
||||
|
|
|
|||
|
|
@ -287,7 +287,7 @@ Now you update the list of certificates running the following, again either as `
|
|||
```
|
||||
|
||||
> Some Linux distributions have different methods of updating the certificate list. For more details, please read this
|
||||
> guide on [addding trusted root certificates](https://github.com/Busindre/How-to-Add-trusted-root-certificates).
|
||||
> guide on [adding trusted root certificates](https://github.com/Busindre/How-to-Add-trusted-root-certificates).
|
||||
|
||||
Once you update your certificate list, you can set the stream parameters for Netdata to trust the parent certificate. Open `stream.conf` for editing and change the following lines:
|
||||
|
||||
|
|
|
|||
|
|
@ -188,10 +188,10 @@ These are options dedicated to badges:
|
|||
The following parameters specify colors of each individual part of the badge. Each parameter is documented in detail
|
||||
below.
|
||||
|
||||
| Area of badge | Backgroud color parameter | Text color parameter |
|
||||
| ---: | :-----------------------: | :------------------: |
|
||||
| Label (left) part | `label_color` | `text_color_lbl` |
|
||||
| Value (right) part | `value_color` | `text_color_val` |
|
||||
| Area of badge | Background color parameter | Text color parameter |
|
||||
| ---: | :------------------------: | :------------------: |
|
||||
| Label (left) part | `label_color` | `text_color_lbl` |
|
||||
| Value (right) part | `value_color` | `text_color_val` |
|
||||
|
||||
- `label_color=COLOR`
|
||||
|
||||
|
|
@ -223,7 +223,7 @@ These are options dedicated to badges:
|
|||
|
||||
The above will set `grey` if no value exists (not collected within the `gap when lost iterations above` in
|
||||
`netdata.conf` for the chart), `green` if the value is less than 10, `yellow` if the value is less than 100, and
|
||||
so on. Netdata will use `red` if no other conditions match. Only integers are suported as values.
|
||||
so on. Netdata will use `red` if no other conditions match. Only integers are supported as values.
|
||||
|
||||
The supported operators are `<`, `>`, `<=`, `>=`, `=` (or `:`), and `!=` (or `<>`).
|
||||
|
||||
|
|
|
|||
|
|
@ -75,7 +75,7 @@ curl "http://NODE:19999/api/v1/manage/health?cmd=RESET" -H "X-Auth-Token: Mytoke
|
|||
By default access to the health management API is only allowed from `localhost`. Accessing the API from anything else will return a 403 error with the message `You are not allowed to access this resource.`. You can change permissions by editing the `allow management from` variable in `netdata.conf` within the [web] section. See [web server access lists](/web/server/README.md#access-lists) for more information.
|
||||
|
||||
The command `RESET` just returns Netdata to the default operation, with all health checks and notifications enabled.
|
||||
If you've configured and entered your token correclty, you should see the plain text response `All health checks and notifications are enabled`.
|
||||
If you've configured and entered your token correctly, you should see the plain text response `All health checks and notifications are enabled`.
|
||||
|
||||
### Disable or silence all alarms
|
||||
|
||||
|
|
|
|||
|
|
@ -324,7 +324,7 @@ Netdata supports a number of chart libraries. The default chart library is
|
|||
Each chart library has a number of specific settings. To learn more about them,
|
||||
you should investigate the documentation of the given chart library, or visit
|
||||
the appropriate JavaScript file that defines the library's options. These files
|
||||
are concatenated into the monolithin `dashboard.js` for deployment.
|
||||
are concatenated into the monolithic `dashboard.js` for deployment.
|
||||
|
||||
- [Dygraph](https://github.com/netdata/netdata/blob/5b57fc441c40959514c4e2d0863be2e6a417e352/web/gui/dashboard.js#L2034)
|
||||
- [d3](https://github.com/netdata/netdata/blob/5b57fc441c40959514c4e2d0863be2e6a417e352/web/gui/dashboard.js#L4095)
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
<!--
|
||||
title: "`static-threaded` web server"
|
||||
description: "The Netdata Agent's static-threaded web server spawns a fixed nubmer of threads that listen to web requests and uses non-blocking I/O."
|
||||
description: "The Netdata Agent's static-threaded web server spawns a fixed number of threads that listen to web requests and uses non-blocking I/O."
|
||||
custom_edit_url: https://github.com/netdata/netdata/edit/master/web/server/static/README.md
|
||||
-->
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue