1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
|
# Docs Development Guidelines
Welcome to our docs developer guidelines!
We store documentation related to Netdata inside of the [`netdata/netdata` repository](https://github.com/netdata/netdata) on GitHub.
The Netdata team aggregates and publishes all documentation at [learn.netdata.cloud](/) using
[Docusaurus](https://v2.docusaurus.io/) over at the [`netdata/learn` repository](https://github.com/netdata/learn).
## Before you get started
Anyone interested in contributing to documentation should first read the [Netdata style guide](#styling-guide) further down below and the [Netdata Community Code of Conduct](/contribute/code-of-conduct).
Netdata's documentation uses Markdown syntax. If you're not familiar with Markdown, read the [Mastering Markdown](https://guides.github.com/features/mastering-markdown/) guide from GitHub for the basics on creating paragraphs, styled text, lists, tables, and more, and read further down about some special occasions [while writing in MDX](#mdx-and-markdown).
### Netdata's Documentation structure
Netdata's documentation is separated into 5 categories.
- **Getting Started**: This section’s purpose is to present “What is Netdata” and for whom is it for while also presenting all the ways Netdata can be deployed. That includes Netdata’s platform support, Standalone deployment, Parent-child deployments, deploying on Kubernetes and also deploying on IoT nodes.
- Stored in **WIP**
- Published in **WIP**
- **Concepts**: This section’s purpose is to take a pitch on all the aspects of Netdata. We present the functionality of each component/idea and support it with examples but we don’t go deep into technical details.
- Stored in the `/docs/concepts` directory in the `netdata/netdata` repository.
- Published in **WIP**
- **Tasks**: This section's purpose is to break down any operation into a series of fundamental tasks for the Netdata solution.
- Stored in the `/docs/tasks` directory in the `netdata/netdata` repository.
- Published in **WIP**
- **References**: This section’s purpose is to explain thoroughly every part of Netdata. That covers settings, configurations and so on.
- Stored near the component they refer to.
- Published in **WIP**
- **Collectors References**: This section’s purpose is to explain thoroughly every collector that Netdata supports and it's configuration options.
- Stored in stored near the collector they refer to.
- Published in **WIP**
## How to contribute
The easiest way to contribute to Netdata's documentation is to edit a file directly on GitHub. This is perfect for small fixes to a single document, such as fixing a typo or clarifying a confusing sentence.
Click on the **Edit this page** button on any published document on [Netdata Learn](https://learn.netdata.cloud). Each
page has two of these buttons: One beneath the table of contents, and another at the end of the document, which take you
to GitHub's code editor. Make your suggested changes, keeping the [Netdata style guide](#styling-guide)
in mind, and use the ***Preview changes*** button to ensure your Markdown syntax works as expected.
Under the **Commit changes** header, write descriptive title for your requested change. Click the **Commit changes**
button to initiate your pull request (PR).
Jump down to our instructions on [PRs](#making-a-pull-request) for your next steps.
### Edit locally
Editing documentation locally is the preferred method for complex changes that span multiple documents or change the documentation's style or structure.
Create a fork of the Netdata Agent repository by visit the [Netdata repository](https://github.com/netdata/netdata) and clicking on the **Fork** button.
GitHub will ask you where you want to clone the repository. When finished, you end up at the index of your forked Netdata Agent repository. Clone your fork to your local machine:
```bash
git clone https://github.com/YOUR-GITHUB-USERNAME/netdata.git
```
Create a new branch using `git checkout -b BRANCH-NAME`. Use your favorite text editor to make your changes, keeping the [Netdata style guide](/contribute/style-guide) in mind. Add, commit, and push changes to your fork. When you're finished, visit the [Netdata Agent Pull requests](https://github.com/netdata/netdata/pulls) to create a new pull request based on the changes you made in the new branch of your fork.
### Making a pull request
Pull requests (PRs) should be concise and informative. See our [PR guidelines](/contribute/handbook#pr-guidelines) for specifics.
- The title must follow the [imperative mood](https://en.wikipedia.org/wiki/Imperative_mood) and be no more than ~50 characters.
- The description should explain what was changed and why. Verify that you tested any code or processes that you are trying to change.
The Netdata team will review your PR and assesses it for correctness, conciseness, and overall quality. We may point to specific sections and ask for additional information or other fixes.
After merging your PR, the Netdata team rebuilds the [documentation site](https://learn.netdata.cloud) to publish the changed documentation.
## Writing Docs
We have three main types of Docs: **References**, **Concepts** and **Tasks**.
### Metadata Tags
All of the Docs however have what we call "metadata" tags. these help to organize the document upon publishing.
So let's go through the different necessary metadata tags to get a document properly published on Learn:
- Docusaurus Specific:\
These metadata tags are parsed automatically by Docusaurus and are rendered in the published document. **Note**: Netdata only uses the Docusaurus metadata tags releveant for our documentation infrastructure.
- `title: "The title of the document"` : Here we specify the title of our document, which is going to be converted to the heading of the published page.
- `description: "The description of the file"`: Here we give a description of what this file is about.
- `custom_edit_url: https://github.com/netdata/netdata/edit/master/collectors/COLLECTORS.md`: Here is an example of the link that the user will be redirected to if he clicks the "Edit this page button", as you see it leads directly to the edit page of the source file.
- Netdata Learn specific:
- `learn_status: "..."`
- The options for this tag are:
- `"published"`
- `"unpublished"`
- `learn_topic_type: "..."`
- The options for this tag are:
- `"Getting Started"`
- `"Concepts"`
- `"Tasks"`
- `"References"`
- `"Collectors References"`
- This is the Topic that the file belongs to, and this is going to resemble the start directory of the file's path on Learn for example if we write `"Concepts"` in the field, then the file is going to be placed under `/Concepts/....` inside Learn.
- `learn_rel_path: "/example/"`
- This tag represents the rest of the path, without the filename in the end, so in this case if the file is a Concept, it would go under `Concepts/example/filename.md`. If you want to place the file under the "root" topic folder, input `"/"`.
- ⚠️ In case any of these "Learn" tags are missing or falsely inputted the file will remain unpublished. This is by design to prevent non-properly tagged files from getting published.
While Docusaurus can make use of more metadata tags than the above, these are the minimum we require to publish the file on Learn.
### Doc Templates
These are the templates we use for our Documentation files:
<details>
<summary>Reference Docs</summary>
The template that is used for Reference files is:
```
<!--
title: "Apache monitoring with Netdata"
description: "Monitor the health and performance of Apache web servers with zero configuration, per-second metric granularity, and interactive visualizations."
custom_edit_url: https://github.com/netdata/go.d.plugin/edit/master/modules/apache/README.md
learn_topic_type: "Collector References"
learn_rel_path: "/sample_category"
learn_status: "published"
-->
```
## Configuration files
### Data collection
```
go.d/apache.conf
```
To make changes, see `the ./edit-config task <link>`
### Alerts
none
## Requirements to run this module
- none
## Requirement on the monitored application
- `Apache` with enabled [`mod_status`](https://httpd.apache.org/docs/2.4/mod/mod_status.html)
## Auto detection
### Single node installation
. . . we autodetect localhost:port and what configurations are defaults
### Kubernetes installations
. . . Service discovery, click here
## Metrics
Columns: Context | description (of the context) | units (of the context) | dimensions | alerts
- Requests in `requests/s`
- Connections in `connections`
- Async Connections in `connections`
- Scoreboard in `connections`
- Bandwidth in `kilobits/s`
- Workers in `workers`
- Lifetime Average Number Of Requests Per Second in `requests/s`
- Lifetime Average Number Of Bytes Served Per Second in `KiB/s`
- Lifetime Average Response Size in `KiB`
### Labels
just like <https://github.com/netdata/go.d.plugin/tree/master/modules/k8s_state#labels>
## Alerts
collapsible content for every alert, just like the alert guides
## Configuration options
Table with all the configuration options available.
Columns: name | description | default
## Configuration example
Needs only `url` to server's `server-status?auto`. Here is an example for 2 servers:
```yaml
jobs:
- name: local
url: http://127.0.0.1/server-status?auto
- name: remote
url: http://203.0.113.10/server-status?auto
```
For all available options please see
module [configuration file](https://github.com/netdata/go.d.plugin/blob/master/config/go.d/apache.conf).
## Troubleshoot
backlink to the task to run this module in debug mode
</details>
<details>
<summary>Task Docs</summary>
The template that is used for Task files is:
```
<!--
title: "Task title"
description: "Task description"
custom_edit_url: https://github.com/netdata/netdata/edit/master/docs/Tasks/sampletask.md
learn_topic_type: "Tasks"
learn_rel_path: "/sample_category"
learn_status: "published"
-->
```
## Description
A small description of the Task.
## Prerequisites
Describe all the information that the user needs to know before proceeding with the task.
## Context
Describe the background information of the Task, the purpose of the Task, and what will the user achieve by completing it.
## Steps
A task consists of steps, here provide the actions needed from the user, so he can complete the task correctly.
## Result
Describe the expected output/ outcome of the result.
## Example
Provide any examples needed for the Task
</details>
<details>
<summary>Concept Docs</summary>
The template of the Concept files is:
```
<!--
title: "Concept title"
description: "Concept description"
custom_edit_url: https://github.com/netdata/netdata/edit/master/docs/Concepts/sampleconcept.md
learn_topic_type: "Concepts"
learn_rel_path: "/sample_category"
learn_status: "published"
-->
```
## Description
In our concepts we have a more loose structure, the goal is to communicate the "concept" to the user, starting with simple language that even a new user can understand, and building from there.
</details>
## Styling Guide
The *Netdata style guide* establishes editorial guidelines for any writing produced by the Netdata team or the Netdata
community, including documentation, articles, in-product UX copy, and more. Both internal Netdata teams and external
contributors to any of Netdata's open-source projects should reference and adhere to this style guide as much as
possible.
Netdata's writing should **empower** and **educate**. You want to help people understand Netdata's value, encourage them
to learn more, and ultimately use Netdata's products to democratize monitoring in their organizations. To achieve these
goals, your writing should be:
- **Clear**. Use simple words and sentences. Use strong, direct, and active language that encourages readers to action.
- **Concise**. Provide solutions and answers as quickly as possible. Give users the information they need right now,
along with opportunities to learn more.
- **Universal**. Think of yourself as a guide giving a tour of Netdata's products, features, and capabilities to a
diverse group of users. Write to reach the widest possible audience.
You can achieve these goals by reading and adhering to the principles outlined below.
## Voice and tone
One way we write empowering, educational content is by using a consistent voice and an appropriate tone.
*Voice* is like your personality, which doesn't really change day to day.
*Tone* is how you express your personality. Your expression changes based on your attitude or mood, or based on who
you're around. In writing, your reflect tone in your word choice, punctuation, sentence structure, or even the use of
emoji.
The same idea about voice and tone applies to organizations, too. Our voice shouldn't change much between two pieces of
content, no matter who wrote each, but the tone might be quite different based on who we think is reading.
For example, a [blog post](https://www.netdata.cloud/blog/) and a [press release](https://www.netdata.cloud/news/)
should have a similar voice, despite most often being written by different people. However, blog posts are relaxed and
witty, while press releases are focused and academic. You won't see any emoji in a press release.
### Voice
Netdata's voice is authentic, passionate, playful, and respectful.
- **Authentic** writing is honest and fact-driven. Focus on Netdata's strength while accurately communicating what
Netdata can and cannot do, and emphasize technical accuracy over hard sells and marketing jargon.
- **Passionate** writing is strong and direct. Be a champion for the product or feature you're writing about, and let
your unique personality and writing style shine.
- **Playful** writing is friendly, thoughtful, and engaging. Don't take yourself too seriously, as long as it's not at
the expense of Netdata or any of its users.
- **Respectful** writing treats people the way you want to be treated. Prioritize giving solutions and answers as
quickly as possible.
### Tone
Netdata's tone is fun and playful, but clarity and conciseness comes first. We also tend to be informal, and aren't
afraid of a playful joke or two.
While we have general standards for voice and tone, we do want every individual's unique writing style to reflect in
published content.
## Universal communication
Netdata is a global company in every sense, with employees, contributors, and users from around the world. We strive to
communicate in a way that is clear and easily understood by everyone.
Here are some guidelines, pointers, and questions to be aware of as you write to ensure your writing is universal. Some
of these are expanded into individual sections in the [language, grammar, and mechanics](#language-grammar-and-mechanics) section below.
- Would this language make sense to someone who doesn't work here?
- Could someone quickly scan this document and understand the material?
- Create an information hierarchy with key information presented first and clearly called out to improve scannability.
- Avoid directional language like "sidebar on the right of the page" or "header at the top of the page" since
presentation elements may adapt for devices.
- Use descriptive links rather than "click here" or "learn more".
- Include alt text for images and image links.
- Ensure any information contained within a graphic element is also available as plain text.
- Avoid idioms that may not be familiar to the user or that may not make sense when translated.
- Avoid local, cultural, or historical references that may be unfamiliar to users.
- Prioritize active, direct language.
- Avoid referring to someone's age unless it is directly relevant; likewise, avoid referring to people with age-related
descriptors like "young" or "elderly."
- Avoid disability-related idioms like "lame" or "falling on deaf ears." Don't refer to a person's disability unless
it’s directly relevant to what you're writing.
- Don't call groups of people "guys." Don't call women "girls."
- Avoid gendered terms in favor of neutral alternatives, like "server" instead of "waitress" and "businessperson"
instead of "businessman."
- When writing about a person, use their communicated pronouns. When in doubt, just ask or use their name. It's OK to
use "they" as a singular pronoun.
> Some of these guidelines were adapted from MailChimp under the Creative Commons license.
## Language, grammar, and mechanics
To ensure Netdata's writing is clear, concise, and universal, we have established standards for language, grammar, and
certain writing mechanics. However, if you're writing about Netdata for an external publication, such as a guest blog
post, follow that publication's style guide or standards, while keeping the [preferred spelling of Netdata
terms](#netdata-specific-terms) in mind.
### Active voice
Active voice is more concise and easier to understand compared to passive voice. When using active voice, the subject of
the sentence is action. In passive voice, the subject is acted upon. A famous example of passive voice is the phrase
"mistakes were made."
| | |
| --------------- | ----------------------------------------------------------------------------------------- |
| Not recommended | When an alarm is triggered by a metric, a notification is sent by Netdata. |
| **Recommended** | When a metric triggers an alarm, Netdata sends a notification to your preferred endpoint. |
### Second person
Use the second person ("you") to give instructions or "talk" directly to users.
In these situations, avoid "we," "I," &qu
|