|
1 | 1 | # Metadata Generator
|
2 | 2 |
|
3 |
| -Components must contain a `metadata.yaml` file that documents various aspects of the component including: |
| 3 | +Every component's documentation should include a brief description of the component and guidance on how to use it. |
| 4 | +There is also some information about the component (or metadata) that should be included to help end-users understand the current state of the component and whether it is right for their use case. |
| 5 | +Examples of this metadata about a component are: |
4 | 6 |
|
5 | 7 | * its stability level
|
6 | 8 | * the distributions containing it
|
7 | 9 | * the types of pipelines it supports
|
8 | 10 | * metrics emitted in the case of a scraping receiver
|
9 | 11 |
|
10 |
| -Current examples: |
| 12 | +The metadata generator defines a schema for specifying this information to ensure it is complete and well-formed. |
| 13 | +The metadata generator is then able to ingest the metadata, validate it against the schema and produce documentation in a standardized format. |
| 14 | +An example of how this generated documentation looks can be found in [documentation.md](./documentation.md). |
11 | 15 |
|
12 |
| -* hostmetricsreceiver scrapers like the [cpuscraper](https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/main/receiver/hostmetricsreceiver/internal/scraper/cpuscraper/metadata.yaml) |
| 16 | +## Using the Metadata Generator |
13 | 17 |
|
14 |
| -See [metric-metadata.yaml](metric-metadata.yaml) for file format documentation. |
| 18 | +In order for a component to benefit from the metadata generator (`mdatagen`) these requirements need to be met: |
| 19 | +1. A `metadata.yaml` file containing the metadata needs to be included in the component |
| 20 | +2. The component should declare a `go:generate mdatagen` directive which tells `mdatagen` what to generate |
15 | 21 |
|
16 |
| -If adding a new receiver a `doc.go` file should also be added to trigger the generation. See below for details. |
| 22 | +As an example, here is a minimal `metadata.yaml` for the [OTLP receiver](https://github.com/open-telemetry/opentelemetry-collector/tree/main/receiver/otlpreceiver): |
| 23 | +```yaml |
| 24 | +type: otlp |
| 25 | +status: |
| 26 | + class: receiver |
| 27 | + stability: |
| 28 | + beta: [logs] |
| 29 | + stable: [metrics, traces] |
| 30 | +``` |
17 | 31 |
|
18 |
| -## Generating |
| 32 | +Detailed information about the schema of `metadata.yaml` can be found in [metadata-schema.yaml](./metadata-schema.yaml). |
19 | 33 |
|
20 |
| -`make generate` triggers the following actions: |
| 34 | +The `go:generate mdatagen` directive is usually defined in a `doc.go` file in the same package as the component, for example: |
| 35 | +```go |
| 36 | +//go:generate mdatagen metadata.yaml |
21 | 37 |
|
22 |
| -1. `cd cmd/mdatagen && $(GOCMD) install .` to install `mdatagen` tool in`GOBIN` |
| 38 | +package main |
| 39 | +``` |
23 | 40 |
|
24 |
| -2. All `go:generate mdatagen` directives that are usually defined in `doc.go` files of the metric scrapers will be |
25 |
| - executed. For example, |
26 |
| - [/receiver/hostmetricsreceiver/internal/scraper/cpuscraper/doc.go](../../receiver/hostmetricsreceiver/internal/scraper/cpuscraper/doc.go) |
27 |
| - runs `mdatagen` for the [metadata.yaml](../../receiver/hostmetricsreceiver/internal/scraper/cpuscraper/metadata.yaml) |
28 |
| - which generates the metrics builder code in |
29 |
| - [internal/metadata](../../receiver/hostmetricsreceiver/internal/scraper/cpuscraper/internal/metadata) |
30 |
| - and [documentation.md](../../receiver/hostmetricsreceiver/internal/scraper/cpuscraper/internal/metadata) with |
31 |
| - generated documentation about emitted metrics. |
| 41 | +Below are some more examples that can be used for reference: |
32 | 42 |
|
33 |
| -## Development |
| 43 | +* The ElasticSearch receiver has an extensive [metadata.yaml](../../receiver/elasticsearchreceiver/metadata.yaml) |
| 44 | +* The host metrics receiver has internal subcomponents, each with their own `metadata.yaml` and `doc.go`. See [cpuscraper](../../receiver/hostmetricsreceiver/internal/scraper/cpuscraper) for example. |
34 | 45 |
|
35 |
| -In order to introduce support of a new functionality in metadata.yaml: |
| 46 | +You can run `cd cmd/mdatagen && $(GOCMD) install .` to install the `mdatagen` tool in `GOBIN` and then run `mdatagen metadata.yaml` to generate documentation for a specific component or you can run `make generate` to generate documentation for all components. |
36 | 47 |
|
37 |
| -1. Make code changes in the (generating code)[./loader.test] and (templates)[./templates/]. |
38 |
| -2. Add usage of the new functionality in (metadata.yaml)[./metadata.yaml]. |
39 |
| -3. Run `make mdatagen-test`. |
40 |
| -4. Make sure all tests are passing including (generated tests)[./internal/metadata/generated_metrics_test.go]. |
41 |
| -5. Run `make generate`. |
| 48 | +## Contributing to the Metadata Generator |
42 | 49 |
|
| 50 | +The code for generating the documentation can be found in [loader.go](./loader.go) and the templates for rendering the documentation can be found in [templates](./templates). |
| 51 | +When making updates to the metadata generator or introducing support for new functionality: |
| 52 | + |
| 53 | +1. Ensure the [metadata-schema.yaml](./metadata-schema.yaml) and [./metadata.yaml](metadata.yaml) files reflect the changes. |
| 54 | +2. Run `make mdatagen-test`. |
| 55 | +3. Make sure all tests are passing including [generated tests](./internal/metadata/generated_metrics_test.go). |
| 56 | +4. Run `make generate`. |
0 commit comments