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
|
<!--
title: "Contribute to the documentation"
sidebar_label: "Contribute to the documentation"
custom_edit_url: "https://github.com/netdata/netdata/blob/master/docs/guidelines.md"
sidebar_position: "10"
learn_status: "Published"
learn_topic_type: "Custom"
learn_rel_path: "Contribute"
-->
import Tabs from '@theme/Tabs'; import TabItem from '@theme/TabItem';
Welcome to our docs developer guidelines!
This document will guide you to the process of contributing to our
docs (**learn.netdata.cloud**)
## Documentation architecture
Netdata docs follows has two principals.
1. Keep the documentation of each component _as close as you can to the codebase_
2. Every component is analyzed via topic related docs.
To this end:
1. Documentation lives in every possible repo in the netdata organization. At the moment we contribute to:
- netdata/netdata
- netdata/learn (final site)
- netdata/go.d.plugin
- netdata/agent-service-discovery
In each of these repos you will find markdown files. These markdown files may or not be part of the final docs. You
understand what documents are part of the final docs in the following section:[_How to update documentation of
learn.netdata.cloud_](#how-to-update-documentation-of-learn-netdata-cloud)
2. Netdata docs processes are inspired from
the [DITA 1.2 guidelines](http://docs.oasis-open.org/dita/v1.2/os/spec/archSpec/dita-1.2_technicalContent_overview.html)
for Technical content.
## Topic types
### Concepts
A concept introduces a single feature or concept. A concept should answer the questions:
- What is this?
- Why would I use it?
Concept topics:
- Are abstract ideas
- Explain meaning or benefit
- Can stay when specifications change
- Provide background information
### Tasks
Concept and reference topics exist to support tasks. _The goal for users … is not to understand a concept but to
complete a task_. A task gives instructions for how to complete a procedure.
Much of the uncertainty whether a topic is a concept or a reference disappears, when you have strong, solid task topics
in place, furthermore topics directly address your users and their daily tasks and help them to get their job done. A
task **must give an answer** to the **following questions**:
- How do I create cool espresso drinks with my new coffee machine?
- How do I clean the milk steamer?
For the title text, use the structure active verb + noun. For example, for instance _Deploy the Agent_.
### References
The reference document and information types provide for the separation of fact-based information from concepts and
tasks. \
Factual information may include tables and lists of specifications, parameters, parts, commands, edit-files and other
information that the users are likely to look up. The reference information type allows fact-based content to be
maintained by those responsible for its accuracy and consistency.
## Contribute to the documentation of learn.netdata.cloud
### Encapsulate topics into markdown files.
Netdata uses markdown files to document everything. To implement concrete sections of these [Topic types](#topic-types)
we encapsulate this logic as follows. Every document is characterized by its topic type ('learn_topic_type' metadata
field). To avoid breaking every single netdata concept into numerous small markdown files each document can be either a
single `Reference` or `Concept` or `Task` or a group of `References`, `Concepts`, `Tasks`.
To this end, every single topic is encapsulated into a `Heading 3 (###)` section. That means, when you have a single
file you only make use of `Headings 4` and lower (`4, 5, 6`, for templated section or subsection). In case you want to
includ multiple (`Concepts` let's say) in a single document, you use `Headings 3` to seperate each concept. `Headings 2`
are used only in case you want to logically group topics inside a document.
For instance:
```markdown
Small introduction of the document.
### Concept A
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna
aliqua.
#### Field from template 1
Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat.
#### Field from template 1
Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur.
##### Subsection 1
. . .
### Concept A
Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.
#### Field from template 1
. . .
```
This approach gives a clean and readable outlook in each document from a single sidebar.
Here you can find the preferred templates for each topic type:
<Tabs>
<TabItem value="Concept" label="Concept" default>
```markdown
Small intro, give some context to the user of what you will cover on this document
### concept title (omit if the document describes only one concept)
A concept introduces a single feature or concept. A concept should answer the questions:
1. What is this?
2. Why would I use it?
```
</TabItem>
<TabItem value="Task" label="Tasks">
```markdown
Small intro, give some context to the user of what you will cover on this document
### Task title (omit if the document describes only one task)
#### Prerequisite
Unordered list of what you will need.
#### Steps
Exact list of step the user must follow
#### Expected result
What you expect to see when you complete the steps above
#### Example
Example configuration/actions of the task
#### Related reference documentation
List of reference docs user needs to be aware of.
```
</TabItem>
<TabItem value="Reference-collectors" label="Reference-collectors">
```markdown
Small intro, give some context to the user of what you will cover on this document
### Reference name (omit if the document describes only one reference)
#### Requirements
Document any dependencies needed to run this module
#### Requirements on the monitored component
Document any steps user must take to sucessful monitor application,
for instance (create a user)
#### Configuration files
table with path and configuration files purpose
Columns: File name | Description (Purpose in a nutshell)
#### Data collection
To make changes, see `the ./edit-config task <link>`
#### Auto discovery
##### Single node installation
. . . we autodetect localhost:port and what configurations are defaults
##### Kubernetes installations
. . . Service discovery, click here
#### Metrics
Columns: Metric (Context) | Scope | description (of the context) | dimensions | units (of the context) | Alert triggered
#### Alerts
Collapsible content for every alert, just like the alert guides
#### Configuration options
Table with all the configuration options available.
Columns: name | description | default | file_name
#### Configuration example
Default configuration example
#### Troubleshoot
backlink to the task to run this module in debug mode (here you provide the debug flags)
```
</TabItem>
</Tabs>
### Metadata fields
All Docs that are supposed to be part of learn.netdata.cloud have **hidden** sections in the begining of document. These
sections are plain lines of text and we call them metadata. Their represented as `key : "Value"` pairs. Some of them are
needed from our statice website builder (docusaurus) others are needed for our internal pipelines to build docs
(have prefix `learn_`).
So let's go through the different necessary metadata tags to get a document properly published on Learn:
| metadata_key | Value(s) | Frontmatter effect | Mandatory | Limitations |
|:---------------------:|---------------------------------------------------------------------------------------------------------------|:-----------------------------------------------------------------------------------------------------------------------------------------------------------:|:---------:|:---------------------------------------:|
| `title` | `String` | Title in each document | yes | |
| `custom_edit_url` | `String` | The source GH link of the file | yes | |
| `description` | `String or multiline String` | - | yes | |
| `sidebar_label` | `String or multiline String` | Name in the TOC tree | yes | |
| `sidebar_position` | `String or multiline String` | Global position in the TOC tree (local for per folder) | yes | |
| `learn_status` | [`Published`, `Unpublished`, `Hidden`] | `Published`: Document visible in learn,<br/> `Unpublished`: Document archived in learn, <br/>`Hidden`: Documentplaced under learn_rel_path but it's hidden] | yes | |
| `learn_topic_type` | [`Concepts`, `Tasks`, `References`, `Getting Started`] | | yes | |
| `learn_rel_path` | `Path` (the path you want this file to appear in learn<br/> without the /docs prefix and the name of the file | | yes | |
| `learn_autogenerated` | `Dictionary` (for internal use) | | no | Keys in the dictionary must be in `' '` |
:::important
1. In case any mandatory tags are missing or falsely inputted the file will remain unpublished. This is by design to
prevent non-properly tagged files from getting published.
2. All metadata values must be included in `" "`. From `string` noted text inside the fields use `' ''`
While Docusaurus can make use of more metadata tags than the above, these are the minimum we require to publish the file
on Learn.
:::
### Placing a document in learn
Here you can see how the metadata are parsed and create a markdown file in learn.
![](https://user-images.githubusercontent.com/12612986/207310336-f7cc150b-543c-4f13-be98-5058a4d29284.png)
### 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](https://github.com/netdata/.github/blob/main/CODE_OF_CONDUCT.md).
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).
### Making your first contribution
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.
**Note**: If you wish to contribute documentation that is more tailored from your specific infrastructure
monitoring/troubleshooting experience, please consider submitting a blog post about your experience. Check out our [blog](https://github.com/netdata/blog#readme) repo! Any blog submissions that have
widespread or universal application will be integrated into our permanent documentation.
### 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](https://github.com/netdata/netdata/blob/master/docs/contributing/style-guide.md) 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.
## 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.
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.
The following sections describe situations in which a specific syntax is required.
#### Syntax standards (`remark-lint`)
The Netdata team uses [`remark-lint`](https://github.com/remarkjs/remark-lint) for Markdown code styling.
- Use a maximum of 120 characters per line.
- Begin headings with hashes, such as `# H1 heading`, `## H2 heading`, and so on.
- Use `_` for italics/emphasis.
- Use `**` for bold.
- Use dashes `-` to begin an unordered list, and put a single space after the dash.
- Tables should be padded so that pipes line up vertically with added whitespace.
If you want to see all the settings, open the
[`remarkrc.js`](https://github.com/netdata/netdata/blob/master/.remarkrc.js) file in the `netdata/netdata` repository.
#### MDX and markdown
While writing in Docusaurus, you might want to take leverage of it's features that are supported in MDX formatted files.
One of those that we use is [Tabs](https://docusaurus.io/docs/next/markdown-features/tabs). They use an HTML syntax,
which requires some changes in the way we write markdown inside them.
In detail:
Due to a bug with docusaurus, we prefer to use `<h1>heading</h1> instead of # H1` so that docusaurus doesn't render the
contents of all Tabs on the right hand side, while not being able to navigate
them [relative link](https://github.com/facebook/docusaurus/issues/7008).
You can use markdown syntax for every other styling you want to do except Admonitions:
For admonitions, follow [this](https://docusaurus.io/docs/markdown-features/admonitions#usage-in-jsx) guide to use
admonitions inside JSX. While writing in JSX, all the markdown stylings have to be in HTML format to be rendered
properly.
#### Admonitions
Use admonitions cautiously. Admonitions may draw user's attention, to that end we advise you to use them only for side
content/info, without significantly interrupting the document flow.
You can find the supported admonitions in the docusaurus's [documentation](https://docusaurus.io/docs/markdown-features/admonitions).
#### Images
Don't rely on images to convey features, ideas, or instructions. Accompany every image with descriptive alt text.
In Markdown, use the standard image syntax, `![](/docs/agent/contributing)`, and place the alt text between the
brackets `[]`. Here's an example using our logo:
```markdown
![The Netdata logo](/docs/agent/web/gui/static/img/netdata-logomark.svg)
```
Reference in-product text, code samples, and terminal output with actual text content, not screen captures or other
images. Place the text in an appropriate element, such as a blockquote or code block, so all users can parse the
information.
#### Syntax highlighting
Our documentation site at [learn.netdata.cloud](https://learn.netdata.cloud) uses
[Prism](https://v2.docusaurus.io/docs/markdown-features#syntax-highlighting) for syntax highlighting. Netdata can use
any of
the [supported languages by prism-react-renderer](https://github.com/FormidableLabs/prism-react-renderer/blob/master/src/vendor/prism/includeLangs.js)
.
If no language is specified, Prism tries to guess the language based on its content.
Include the language directly after the three backticks (```` ``` ````) that start the code block. For highlighting C
code, for example:
````c
```c
inline char *health_stock_config_dir(void) {
char buffer[FILENAME_MAX + 1];
snprintfz(buffer, FILENAME_MAX, "%s/health.d", netdata_configured_stock_config_dir);
return config_get(CONFIG_SECTION_DIRECTORIES, "stock health config", buffer);
|