[CI] Terminology fixes from patched terminology textlint rule (#3496)

Co-authored-by: Phillip Carter <pcarter@fastmail.com>
This commit is contained in:
Patrice Chalin 2023-11-05 10:50:44 -05:00 committed by GitHub
parent 47a33be8fb
commit e97f52208c
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
16 changed files with 19 additions and 19 deletions

View File

@ -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

View File

@ -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

View File

@ -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.
![OpenTelemetry Demo System Diagram](diagram.png)

View File

@ -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

View File

@ -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

View File

@ -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/)

View File

@ -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

View File

@ -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

View File

@ -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/),

View File

@ -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.

View File

@ -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,

View File

@ -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()`

View File

@ -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.

View File

@ -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

View File

@ -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)

View File

@ -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**