[CI] Terminology fixes from patched terminology textlint rule (#3496)
Co-authored-by: Phillip Carter <pcarter@fastmail.com>
This commit is contained in:
parent
47a33be8fb
commit
e97f52208c
|
|
@ -49,8 +49,8 @@ This repository will help you:
|
|||
|
||||
- **Keep your Collector deployment up-to-date.** By incorporating custom
|
||||
Collectors into your CI/CD pipeline, you can automate builds to ensure your
|
||||
Collector stays current with the latest features and fixes. In this repo,
|
||||
we'll show one way to do that with Cloud Build.
|
||||
Collector stays current with the latest features and fixes. In this
|
||||
repository, we'll show one way to do that with Cloud Build.
|
||||
|
||||
Each of these represents part of the “Getting Started” process with
|
||||
OpenTelemetry Collector, so by identifying and consolidating these steps we hope
|
||||
|
|
|
|||
|
|
@ -111,7 +111,7 @@ ourselves to just the items listed here.
|
|||
|
||||
- Language examples for
|
||||
[C++](https://github.com/open-telemetry/opentelemetry-demo/issues/36),
|
||||
Erlang/elixir,
|
||||
Erlang/Elixir,
|
||||
[PHP](https://github.com/open-telemetry/opentelemetry-demo/issues/34), and
|
||||
[Rust](https://github.com/open-telemetry/opentelemetry-demo/issues/35)
|
||||
- Extend support to
|
||||
|
|
|
|||
|
|
@ -68,7 +68,7 @@ Every microservice has a specific goal and can communicate with others by using
|
|||
a global gRPC definition. Persistent information is saved into a PostgreSQL
|
||||
database and there are outbound services that connect with third-party services
|
||||
to trigger events (such as confirmation emails). All of the microservices,
|
||||
including the front-end, are connected to the same OpenTelemetry collector
|
||||
including the front-end, are connected to the same OpenTelemetry Collector
|
||||
instance, which uses Jaeger as one of the data stores for the tracing data.
|
||||
|
||||

|
||||
|
|
|
|||
|
|
@ -297,7 +297,7 @@ Let's have a quick look on the most important edge collector settings. A
|
|||
node exists. The `basicauth` extension contains `username` and `password` to
|
||||
identify itself to the exposed remote collector. More container and node
|
||||
specific information are provided by the `k8sattributes` processor via the
|
||||
kubernetes
|
||||
Kubernetes
|
||||
[Kubernetes downward-api](https://kubernetes.io/docs/concepts/workloads/pods/downward-api/).
|
||||
What is not covered is the cluster availability zone and the cluster name. To be
|
||||
able to identify the reported spans later, they are inserted manually with the
|
||||
|
|
|
|||
|
|
@ -159,8 +159,8 @@ landing on a particular page which can be tracked with a counter.
|
|||
- Reach out to current OpenTelemetry maintainers and share the challenges
|
||||
- Create a list of maintainers from APAC region to whom people can reach to
|
||||
- Local in-person meetups for OpenTelemetry users
|
||||
- A good place to start would be `good first issues` in any of the OTel repos,
|
||||
and ask for help in GitHub issues
|
||||
- A good place to start would be `good first issues` in any of the OTel
|
||||
repositories, and ask for help in GitHub issues
|
||||
- Join
|
||||
[OTel slack community](https://communityinviter.com/apps/cloud-native/cncf)
|
||||
and ping in relevant channels
|
||||
|
|
|
|||
|
|
@ -106,7 +106,7 @@ has been released, requiring some migrations to be performed.
|
|||
- Enhancements including improvements in Micrometer bridge, Ktor
|
||||
instrumentations, AWS SDK support, OkHttp 3, Jetty 11, Spring Boot, AWS Lambda
|
||||
tracing, and type matching.
|
||||
- Bugfixes related to Logback MDC instrumentation, Kafka metrics reporter, jetty
|
||||
- Bugfixes related to Logback MDC instrumentation, Kafka metrics reporter, Jetty
|
||||
context leak, filtering scalar Mono/Flux instances, and others.
|
||||
|
||||
#### [JavaScript](/docs/instrumentation/js/)
|
||||
|
|
|
|||
|
|
@ -146,7 +146,7 @@ following result in
|
|||
|
||||
We have all necessary components in place:
|
||||
|
||||
- APIs and SDK as a foundation and implementation of opentelemetry
|
||||
- APIs and SDK as a foundation and implementation of OpenTelemetry
|
||||
specification.
|
||||
- C extension as a foundation for auto-instrumentation.
|
||||
- Auto Instrumentation support (WIP) for most important and popular libraries
|
||||
|
|
|
|||
|
|
@ -45,7 +45,7 @@ at KubeCon North America 2018.
|
|||
To perform a trace-based test, we execute an operation against the system, which
|
||||
generates a trace, following these steps:
|
||||
|
||||
1. Trigger an operation against the system and collect its output and trace id
|
||||
1. Trigger an operation against the system and collect its output and trace ID
|
||||
generated from the operation.
|
||||
2. Wait for the system to report the entire trace to the telemetry data store;
|
||||
3. Collect the trace data generated by the system during the operation. This
|
||||
|
|
|
|||
|
|
@ -5,7 +5,7 @@ menu: { main: { weight: 10 } }
|
|||
aliases: [/docs/workshop/*]
|
||||
---
|
||||
|
||||
OpenTelemetry, also known as OTel for short, is a vendor-neutral open-source
|
||||
OpenTelemetry, also known as OTel for short, is a vendor-neutral open source
|
||||
[Observability](concepts/observability-primer/#what-is-observability) framework
|
||||
for instrumenting, generating, collecting, and exporting telemetry data such as
|
||||
[traces](/docs/concepts/signals/traces/),
|
||||
|
|
|
|||
|
|
@ -5,7 +5,7 @@ weight: 23
|
|||
cSpell:ignore: AFVGQT backpressure distro GRRKNBJE hostmetrics loglevel
|
||||
---
|
||||
|
||||
This document describes how you can manage your OpenTelemetry collector
|
||||
This document describes how you can manage your OpenTelemetry Collector
|
||||
deployment at scale.
|
||||
|
||||
To get the most out of this page you should know how to install and configure
|
||||
|
|
@ -24,7 +24,7 @@ Typical agent management tasks include:
|
|||
1. Querying the agent information and configuration. The agent information can
|
||||
include its version, operating system related information, or capabilities.
|
||||
The configuration of the agent refers to its telemetry collection setup, for
|
||||
example, the OpenTelemetry collector
|
||||
example, the OpenTelemetry Collector
|
||||
[configuration][otel-collector-configuration].
|
||||
1. Upgrading/downgrading agents and management of agent-specific packages,
|
||||
including the base agent functionality and plugins.
|
||||
|
|
|
|||
|
|
@ -1458,7 +1458,7 @@ pair format represented by the `pcommon.Map` type.
|
|||
You can check the definition of the `pcommon.Map` type and the related helper
|
||||
functions to create attribute values using the supported formats in the
|
||||
[/pdata/pcommon/common.go](https://github.com/open-telemetry/opentelemetry-collector/blob/{{%
|
||||
param collectorVersion %}}/pdata/pcommon/common.go) file within the Otel
|
||||
param collectorVersion %}}/pdata/pcommon/common.go) file within the OTel
|
||||
Collector's GitHub project.
|
||||
|
||||
Key/value pairs provide a lot of flexibility to help model your `Resource` data,
|
||||
|
|
|
|||
|
|
@ -11,7 +11,7 @@ leveraged by the UI or other clients. The application is based on
|
|||
|
||||
## Server Instrumentation
|
||||
|
||||
It is recommended to use a Node required module when starting your NodeJS
|
||||
It is recommended to use a Node required module when starting your Node.js
|
||||
application to initialize the SDK and auto-instrumentation. When initializing
|
||||
the OpenTelemetry Node.js SDK, you optionally specify which auto-instrumentation
|
||||
libraries to leverage, or make use of the `getNodeAutoInstrumentations()`
|
||||
|
|
|
|||
|
|
@ -20,7 +20,7 @@ the Phoenix Web Framework.
|
|||
### Prerequisites
|
||||
|
||||
Ensure that you have Erlang, Elixir, PostgreSQL (or the database of your
|
||||
choice), and Phoenix installed locally. The phoenix
|
||||
choice), and Phoenix installed locally. The Phoenix
|
||||
[installation guide](https://hexdocs.pm/phoenix/installation.html) will help you
|
||||
get set up with everything you need.
|
||||
|
||||
|
|
|
|||
|
|
@ -169,7 +169,7 @@ Install the exporter package as a dependency for your application:
|
|||
composer require open-telemetry/exporter-zipkin
|
||||
```
|
||||
|
||||
Update the example to use the Zipkin exporter and to send data to your zipkin
|
||||
Update the example to use the Zipkin exporter and to send data to your Zipkin
|
||||
backend:
|
||||
|
||||
```php
|
||||
|
|
|
|||
|
|
@ -34,7 +34,7 @@ These are for exporter and instrumentation packages respectively. The Jaeger,
|
|||
Zipkin, Prometheus, OTLP and OpenCensus Exporters can be found in the
|
||||
[exporter](https://github.com/open-telemetry/opentelemetry-python/blob/main/exporter/)
|
||||
directory of the repository. Instrumentations and additional exporters can be
|
||||
found in the contrib repo
|
||||
found in the contrib repository
|
||||
[instrumentation](https://github.com/open-telemetry/opentelemetry-python-contrib/tree/main/instrumentation)
|
||||
and
|
||||
[exporter](https://github.com/open-telemetry/opentelemetry-python-contrib/tree/main/exporter)
|
||||
|
|
|
|||
|
|
@ -325,7 +325,7 @@ in the previous step.
|
|||
> As of operator v0.67.0, the Instrumentation resource automatically sets
|
||||
> `OTEL_EXPORTER_OTLP_TRACES_PROTOCOL` and `OTEL_EXPORTER_OTLP_METRICS_PROTOCOL`
|
||||
> to `http/protobuf` for Python services. If you use an older version of the
|
||||
> Operator you **MUST** set these env variables to `http/protobuf`, or python
|
||||
> Operator you **MUST** set these env variables to `http/protobuf`, or Python
|
||||
> auto-instrumentation will not work.
|
||||
|
||||
**Auto-instrumenting Python logs**
|
||||
|
|
|
|||
Loading…
Reference in New Issue