open-telemetry
/
opentelemetry-collector
mirror of https://github.com/open-telemetry/opentelemetry-collector.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Fix broken link to Configuration spec (#451) 

The link needs to be updated since the original doc was part of Omnition
GSuite that is now migrated to Splunk GSuite.
This commit is contained in:
Tigran Najaryan 2019-12-09 12:28:59 -05:00 committed by GitHub
parent 5d463fe488
commit 87c4058a71
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
3 changed files with 4 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
docs/design.md
View File

@ -36,7 +36,7 @@ service:
The above example defines a pipeline for “traces” type of telemetry data, with 3 receivers, 4 processors and 4 exporters.
For details of config file format see [this document](https://docs.google.com/document/d/1GWOzV0H0RTN1adiwo7fTmkjfCATDDFGuOB4jp3ldCc8/edit#).
For details of config file format see [this document](https://docs.google.com/document/d/1NeheFG7DmcUYo_h2vLtNRlia9x5wOJMlV4QKEK05FhQ/edit#).
### Receivers
@ -59,7 +59,7 @@ service:
exporters: [opencensus]
```
In the above example “opencensus” receiver will send the same data to pipeline “traces” and to pipeline “traces/2”. (Note: the configuration uses composite key names in the form of `type[/name]` as defined in [this document](https://docs.google.com/document/d/1GWOzV0H0RTN1adiwo7fTmkjfCATDDFGuOB4jp3ldCc8/edit#)).
In the above example “opencensus” receiver will send the same data to pipeline “traces” and to pipeline “traces/2”. (Note: the configuration uses composite key names in the form of `type[/name]` as defined in [this document](https://docs.google.com/document/d/1NeheFG7DmcUYo_h2vLtNRlia9x5wOJMlV4QKEK05FhQ/edit#)).
When the Collector loads this config the result will look like this (part of processors and exporters are omitted from the diagram for brevity):

2
docs/migrating-from-opencensus.md
View File

@ -29,7 +29,7 @@ The new codebase will contain improvements which are already in progress and whi
- Introduction of receiver and exporter factories that can be individually registered to activate them.
- Implementation of the [new configuration format](https://docs.google.com/document/d/1GWOzV0H0RTN1adiwo7fTmkjfCATDDFGuOB4jp3ldCc8/edit#) that makes use of factories and allows for greater flexibility in the configuration.
- Implementation of the [new configuration format](https://docs.google.com/document/d/1NeheFG7DmcUYo_h2vLtNRlia9x5wOJMlV4QKEK05FhQ/edit#) that makes use of factories and allows for greater flexibility in the configuration.
The functionally of the new `otsvc` will heavily lean on existing implementation and will be mostly a superset of the current agent/collector functionality when considering core receivers and exporters only (however we will allow deviations if it saves significant implementation effort and makes the service better).

2
docs/service-extensions.md
View File

@ -72,7 +72,7 @@ The configuration, analogous to pipelines, allows to have multiple extensions of
the same type. Implementers of extensions need to take care to return error
if it can only execute a single instance. (Note: the configuration uses composite
key names in the form of `type[/name]`
as defined in this [this document](https://docs.google.com/document/d/1GWOzV0H0RTN1adiwo7fTmkjfCATDDFGuOB4jp3ldCc8/edit#)).
as defined in this [this document](https://docs.google.com/document/d/1NeheFG7DmcUYo_h2vLtNRlia9x5wOJMlV4QKEK05FhQ/edit#)).
The factory follows the same pattern established for pipeline configuration: