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

Introduce additional textlint rules (#3011) 

Co-authored-by: Patrice Chalin <chalin@users.noreply.github.com>
This commit is contained in:
Severin Neumann 2023-07-12 16:06:50 +02:00 committed by GitHub
parent 03a4f2870d
commit 8023bf0b94
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
81 changed files with 260 additions and 205 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

54
.textlintrc.json
View File

@ -27,34 +27,86 @@
"skip": [],
"terms": [
".NET",
"Ajax",
"Apache",
"API",
"AWS",
"Azure",
"CNCF",
"eBPF",
"ECMAScript",
"Elixir",
"Erlang",
"GCP",
"GitHub",
"gRPC",
"GraphQL",
"ID",
"iOS",
"HTTP",
"Jaeger",
"Java",
"JavaScript",
"Jetty",
"JMX",
"K8s",
"Kafka",
"KubeCon",
"Kubernetes",
"MacBook",
"macOS",
"MySQL",
"NGINX",
"OK",
"OpenTelemetry Collector",
"OTel",
"OTEP",
"Phoenix",
"PHP",
"Python",
"PostgreSQL",
"protobuf",
"Rails",
"Redis",
"Ruby",
"Rust",
"SemVer",
"SDK",
"SQL",
"SQLite",
"Swift",
"Thanos",
"Traefik",
"TypeScript",
"URL",
"WordPress",
"YouTube",
"Zend",
"Zipkin",
["3rd[- ]party", "third-party"],
["bug[- ]fix(es)?", "bugfix$1"],
["cpp", "C++"],
["dotnet", ".NET"],
["[^\\.]json", "JSON"],
["[^\\.]html", "HTML"],
["he or she", "they"],
["he/she", "they"],
["\\(s\\)he", "they"],
["id['’]?s", "IDs"],
["Mac ?OS", "macOS"],
["meta[- ]data", "metadata"],
["[Nn]ode\\.?[Jj][sS]", "Node.js"],
["open-source", "open source"],
["[Oo]pen[- ]?[Tt]elemetry", "OpenTelemetry"],
["OS X", "macOS"],
["postgres", "PostgreSQL"],
["psr[ -]?([0-9]+)", "PSR-$1"],
["regexes", "regular expressions"]
["React[ .]js", "React"],
["regexp?(s)?", "regular expression$1"],
["repo\\b", "repository"],
["repos", "repositories"],
["screen[- ]shot(s)?", "screenshot$1"],
["time[- ]stamp(s)?", "timestamp$1"]
]
}
}

6
content/en/blog/2022/collector-builder-sample/index.md
View File

@ -284,12 +284,12 @@ config changes and new components as compiled into the updated image.
## Automate builds for secure, up-to-date images
Building your own Collector allows you to control updates and rollouts of the
Collector image. In this repo, we have some samples of how you can own your
Collector build on GCP.
Collector image. In this repository, we have some samples of how you can own
your Collector build on GCP.
Using a [Cloud Build](https://cloud.google.com/build) configuration supports
serverless, automated builds for your Collector. By doing so you can benefit
from new releases, features, and bug fixes in Collector components with minimal
from new releases, features, and bugfixes in Collector components with minimal
delay. Combined with
[Artifact Registry](https://cloud.google.com/artifact-registry), these builds
can be pushed as Docker images in your GCP project. This provides portability

20
content/en/blog/2022/debug-otel-with-otel/index.md
View File

@ -17,7 +17,7 @@ of OpenTelemetry to identify the root cause of bug in another feature.
In this blog post, we want to share this interesting experience with you. By
that, you will learn that minor differences in the language-specific
implementations can have interesting implications and that you have a feature
for java & python, which is here to help you to debug context propagation
for Java and Python, which is here to help you to debug context propagation
issues.
## The issue
@ -27,14 +27,14 @@ issues.
For the blog post [Learn how to instrument NGINX with OpenTelemetry][] we
created a small sample app that had a frontend application in Node.js, that
called an NGINX, which acted as a reverse proxy for a backend application in
python.
Python.
Our goal was to create a re-usable `docker-compose` that would not only show
people how to instrument NGINX with OpenTelemetry, but also how a distributed
trace crossing the web server would look like.
While Jaeger showed us a trace flowing from the frontend application down to the
NGINX, the connection between NGINX and python app was not visible: we had two
NGINX, the connection between NGINX and Python app was not visible: we had two
disconnected traces.
This came as a surprise, because in a prior test with a Java application as
@ -44,7 +44,7 @@ application.
### Steps to reproduce
Follow the instructions on how you can [put NGINX between two services][].
Replace the java-based application with a python application, e.g. put following
Replace the java-based application with a Python application, e.g. put following
three files into the `backend` folder instead:
- `app.py`:
@ -156,21 +156,21 @@ the `frontend` down to NGINX, and another one only for the `python-app`.
### The hints
Since the setup worked with a java application in the backend, we knew that the
problem was either caused by the python application or by the combination of the
NGINX instrumentation and the python application.
Since the setup worked with a Java application in the backend, we knew that the
problem was either caused by the Python application or by the combination of the
NGINX instrumentation and the Python application.
We could quickly rule out that the python application alone was the issue:
We could quickly rule out that the Python application alone was the issue:
trying out a simple Node.js application as backend, we got the same result: two
traces, one from frontend to NGINX, another one for the Node.js application
alone.
With that, we knew that we had a propagation issue: the trace context was not
transferred successfully from NGINX down to the python and Node.js application.
transferred successfully from NGINX down to the Python and Node.js application.
### The analysis
Knowing that the issue does not occur with java and that it is likely a broken
Knowing that the issue does not occur with Java and that it is likely a broken
propagation, we knew what we had to do: we needed to see the trace headers.
Gladly, the instrumentations for [Java][] and [Python][] have a feature that

6
content/en/blog/2022/demo-announcement/index.md
View File

@ -14,7 +14,7 @@ represented, demo support will be extended to Metrics and Logs, and canonical
scenarios will be documented for each signal, with fault injection, and more!
If you want to skip the details then clone our
[repo](https://github.com/open-telemetry/opentelemetry-demo) then run
[repository](https://github.com/open-telemetry/opentelemetry-demo) then run
`docker compose up`[^1] from the command line. There are a couple
[technology requirements](https://github.com/open-telemetry/opentelemetry-demo-webstore#local-quickstart)
so be sure to check those out too.
@ -73,7 +73,7 @@ Otherwise the pre-existing feature set from the GCP demo remains the same:
Node.js, Python, and Ruby)
- Ruby support was added within the last 2 weeks of publishing date
- Designed to work on docker locally
- Uses redis cache
- Uses Redis cache
- Auto-instrumentation using instrumentation libraries Tracing support for the
gRPC, Redis, and HTTP libraries
- Jaeger visualizations for distributed traces, forwarded by OpenTelemetry
@ -148,7 +148,7 @@ ourselves to just the items listed here.
We’re still at the beginning of our journey but there’s great momentum behind
this project. If you’re interested in contributing we’d love your support. There
are links in our GitHub repo on how to get involved and you can
are links in our GitHub repository on how to get involved and you can
[track our overall progress](https://github.com/open-telemetry/opentelemetry-demo/issues)
from there.

4
content/en/blog/2022/gc-elections.md
View File

@ -61,8 +61,8 @@ the community.
## Questions?
For any election related questions, please file an issue on the
[community repo](https://github.com/open-telemetry/community/issues) here and
tag [@jpkrohling](https://github.com/jpkrohling),
[community repository](https://github.com/open-telemetry/community/issues) here
and tag [@jpkrohling](https://github.com/jpkrohling),
[@bogdandrutu](https://github.com/bogdandrutu), and
[@bhs](https://github.com/bhs). Or send us a message on
[CNCF Slack](https://slack.cncf.io/) in

2
content/en/blog/2022/go-web-app-instrumentation/index.md
View File

@ -15,7 +15,7 @@ with OpenTelemetry Go without prior knowledge.
We will start with creating a simple to-do app that uses Mongo and the Gin
framework. Then, we will send tracing data to Jaeger Tracing for visualization.
You can find all the relevant files in this
[Github repository](https://github.com/aspecto-io/opentelemetry-examples/tree/master/go).
[GitHub repository](https://github.com/aspecto-io/opentelemetry-examples/tree/master/go).
![OpenTelemetry Go - The Mandalorian](OpenTelemetry-Go-The-Mandalorian-2048x1406.png)

6
content/en/blog/2022/instrument-apache-httpd-server/index.md
View File

@ -22,7 +22,7 @@ quick guide to get started with the module.
Getting started with the OpenTelemetry module for Apache HTTP Server is pretty
simple, all you need is a docker engine and git. Download the source code from
github and then build the docker image on CentOS7[^1]:
GitHub and then build the docker image on CentOS7[^1]:
```sh
git clone https://github.com/open-telemetry/opentelemetry-cpp-contrib
@ -99,8 +99,8 @@ Zipkin backend. The following steps are required to be done.
![Php-Config](php-config.png)
- Create a file named as `index.html` in the **/var/www/html** directory and add
the following text
- Create a file named as `index.html` in the `**/var/www/html**` directory and
add the following text
```html
<!doctype html>

2
content/en/blog/2022/instrument-nginx/index.md
View File

@ -195,7 +195,7 @@ might be a service calling NGINX to reach that down stream service.
Add two more services to the running example:
- A Node.js service called `frontend` that sits at the front and calls the NGINX
- A java service called `backend` that sits behind the NGINX
- A Java service called `backend` that sits behind the NGINX
Update the `docker-compose` file to contain those 2 services and to overwrite
the `default.conf` in NGINX:

4
content/en/blog/2022/k8s-otel-expose/index.md
View File

@ -39,7 +39,7 @@ article
[How TLS provides identification, authentication, confidentiality, and integrity](https://www.ibm.com/docs/en/ibm-mq/9.1?topic=tls-how-provides-identification-authentication-confidentiality-integrity)
and the Collector
[TLS-Config](https://github.com/open-telemetry/opentelemetry-collector/blob/v0.58.0/config/configtls/README.md)
description on Github.
description on GitHub.
If you are interested in using an external authentication provider, I advise you
to have a look at the article
@ -421,7 +421,7 @@ Kubernetes components, the configurations differ a lot. Overall the
configuration is very error-prone. In the future the exposing of the collector
should be simplified with the help of the OpenTelemetry operator. If you are
interested in the development, you can follow
[Github issue #902](https://github.com/open-telemetry/opentelemetry-operator/issues/902)
[GitHub issue #902](https://github.com/open-telemetry/opentelemetry-operator/issues/902)
to stay updated.
## References

19
content/en/blog/2022/otel-demo-app-nomad/index.md
View File

@ -42,15 +42,16 @@ In order to run the example in this tutorial, you’ll need the following:
- [Docker](https://docker.com) (version 20.10.21 at the time of this writing)
- [Vagrant](https://vagrantup.com) (version 2.3.1 at the time of this writing)
### Tutorial Repos
### Tutorial Repositories
Below are the repos that we’ll be using for today’s tutorial:
Below are the repositories that we’ll be using for today’s tutorial:
- My modified [HashiQube Repo](https://github.com/avillela/hashiqube) (fork of
[servian/hashiqube](https://github.com/servian/hashiqube)). If you’re curious,
you can see what modifications I’ve made
- My modified [HashiQube Repository](https://github.com/avillela/hashiqube)
(fork of [servian/hashiqube](https://github.com/servian/hashiqube)). If you’re
curious, you can see what modifications I’ve made
[here](https://github.com/avillela/hashiqube).
- My [Nomad Conversions](https://github.com/avillela/nomad-conversions) repo
- My [Nomad Conversions](https://github.com/avillela/nomad-conversions)
repository
### HashiQube Setup
@ -59,7 +60,7 @@ Before you start, just a friendly reminder that HashiQube by default runs
on Docker. In addition, we’ll be deploying 21 job specs to Nomad. This means
that we’ll need a decent amount of CPU and RAM, so please make sure that you
have enough resources allocated in your Docker desktop. For reference, I’m
running an M1 Macbook Pro with 8 cores and 32 GB RAM. My Docker Desktop Resource
running an M1 MacBook Pro with 8 cores and 32 GB RAM. My Docker Desktop Resource
settings are as follows:
- **CPUs:** 3
@ -125,7 +126,7 @@ vagrant ssh
We’re finally ready to deploy the OTel Demo App!
First, let’s clone the repo, and go to our working directory:
First, let’s clone the repository, and go to our working directory:
```shell
git clone https://github.com/avillela/nomad-conversions.git
@ -229,7 +230,7 @@ of the services:
![Screen capture of Consul service health. All services healthy.](consul-service-health.png 'Screen capture of Consul service health. All services healthy.')
By default, unhealthy services show up at the top, with a red “x” next to them.
Since we don’t see any nasty red “x”s in the above screen shot, we know that our
Since we don’t see any nasty red “x”s in the above screenshot, we know that our
services are lookin’ good!
#### 5- Access the OTel Demo App

6
content/en/blog/2022/tail-sampling/index.md
View File

@ -134,8 +134,8 @@ You also have the flexibility to add other policies. Here are a few examples:
- `latency`: Sample based on the duration of the trace. For example, you could
sample all traces that take longer than 5 seconds.
- `string_attribute`: Sample based on string attribute values, both exact and
regex value matches are supported. For example, you could sample based on
specific custom attribute values.
regular expression value matches are supported. For example, you could sample
based on specific custom attribute values.
## Potential issues with tail sampling
@ -215,7 +215,7 @@ under active development, including the tail sampling processor and the
collector. For the tail sampling processor, there is currently an
[open issue](https://github.com/open-telemetry/opentelemetry-collector-contrib/issues/1797)
in the
[collector-contrib repo](https://github.com/open-telemetry/opentelemetry-collector-contrib)
[collector-contrib repository](https://github.com/open-telemetry/opentelemetry-collector-contrib)
to discuss the future of this processor that centers around replacing it with
separate processors, so that the chain of events is well-defined and understood.
One of the main issues the community is trying to figure out is whether using

12
content/en/blog/2022/troubleshooting-nodejs.md
View File

@ -77,8 +77,8 @@ To use an auto instrumentation library in your service, you’ll need to:
For most users, the following should cover it:
```js
// First run `npm install @opentelemetry/instrumentation-foo @opentelemetry/instrumentation-bar
// Replace foo and bar with the actual packages you need to instrument (http/mysql/redis etc)
// First run: npm install @opentelemetry/instrumentation-foo @opentelemetry/instrumentation-bar
// Replace foo and bar with the actual packages you need to instrument (HTTP/mySQL/Redis etc)
import { FooInstrumentation } from '@opentelemetry/instrumentation-foo';
import { BarInstrumentation } from '@opentelemetry/instrumentation-bar';
import { registerInstrumentations } from '@opentelemetry/instrumentation';
@ -88,7 +88,7 @@ registerInstrumentations({
});
```
For advanced users who choose to use the low-level api instead of calling
For advanced users who choose to use the low-level API instead of calling
`registerInstrumentations`, make sure your instrumentation is set to use the
right tracer provider and that you call `enable()` if appropriate.
@ -152,9 +152,9 @@ might not be supported and thus no spans will be created.
Consult the documentation of the library you are using to verify if your version
is compatible. This data is usually found in the README for the instrumentation,
for example see the [redis README][].
for example see the [Redis README][].
[redis readme]:
[Redis readme]:
https://www.npmjs.com/package/@opentelemetry/instrumentation-redis
## No Recording and Non-Sampled Spans
@ -367,7 +367,7 @@ channels:
### Resources
- [Opentelemetry-js GitHub repo](https://github.com/open-telemetry/opentelemetry-js)
- [Opentelemetry-js GitHub repository](https://github.com/open-telemetry/opentelemetry-js)
- [The OpenTelemetry Bootcamp](https://www.aspecto.io/opentelemetry-bootcamp/)
- [OpenTelemetry docs](/docs/)

2
content/en/blog/2022/v1.0-trio.md
View File

@ -6,7 +6,7 @@ canonical_url: https://medium.com/opentelemetry/opentelemetry-erlang-elixir-java
---
We are kicking off the new year with a bang! In the last couple months, three
new languages (Ruby, Javascript, and Erlang/Elixir) have had their first 1.0
new languages (Ruby, JavaScript, and Erlang/Elixir) have had their first 1.0
releases, joining the existing GA releases from C++, Go, Java, .Net, Python and
Swift. Read all the details from the [announcement][].

4
content/en/blog/2023/demo-birthday/index.md
View File

@ -15,7 +15,7 @@ since we declared general availability with our
### Project Milestones
The demo has achieved remarkable milestones in its first year, with more than
**70 contributors, 20 official vendor forks, 780 Github stars, and 180K Docker
**70 contributors, 20 official vendor forks, 780 GitHub stars, and 180K Docker
pulls**. The project team has been hard at work adding new capabilities and
improving on existing ones with more than _460 merged PRs, 5 re-written services
in new languages, and 7 brand new components / services_.
@ -33,7 +33,7 @@ changed between our 1.0.0 and 1.4.0 releases? Quite a lot actually.
Helm_
- **More out of the box dashboards like our
[Collector Data Flow Dashboard](/docs/demo/collector-data-flow-dashboard/)**
- **A myriad of frontend bug fixes**
- **A myriad of frontend bugfixes**
- _Our first
[Connector](https://github.com/open-telemetry/opentelemetry-collector/blob/main/connector/README.md)
in the Collector to demonstrate how telemetry pipelines can be linked_

6
content/en/blog/2023/end-user-discussions-01.md
View File

@ -196,8 +196,8 @@ Please also check out
**A:** Implementing correlation takes time and is a work in progress.
Correlation work is more mature for some languages (e.g. Java, Go) than for
others. The best approach is to raise this issue in one of the language-specific
repos that pertains to your situation. A possible work-around is to start traces
at the log level, whereby every log will have its own associated trace.
repositories that pertains to your situation. A possible work-around is to start
traces at the log level, whereby every log will have its own associated trace.
#### 3- Profiling
@ -206,7 +206,7 @@ at the log level, whereby every log will have its own associated trace.
**A:** There is an OTel proposal on profiling, which has been accepted and is
being actively being worked on and discussed. The current focus is on finalizing
the protocol, before SDK work can start. You can check out the
[profiling repo on GitHub](https://github.com/open-telemetry/opentelemetry-profiling),
[profiling repository on GitHub](https://github.com/open-telemetry/opentelemetry-profiling),
as well as the
[Profiling Vision pull request on GitHub](https://github.com/open-telemetry/oteps/pull/212).

2
content/en/blog/2023/end-user-discussions-03.md
View File

@ -248,7 +248,7 @@ CNCF’s Slack instance.
**Q:** Where do you go to find documentation and answers to your questions?
**A:** We have many resources, including official documentation and Github
repos.
repositories.
To help us improve our resources, it would be helpful to gather feedback from
you as an end user – what is your process for finding OTel information? Do you

8
content/en/blog/2023/end-user-q-and-a-01.md
View File

@ -269,9 +269,9 @@ OpenTelemetry has a small number of language maintainers, and as a result, they
don’t necessarily have enough cycles to work on all the things. Thus, they
currently focus on keeping up with spec changes to update the SDK and API. This
means that they often don’t have time (and sometimes not even the expertise) to
manage the contrib repos (e.g. GraphQL). This is a known problem, and there is
currently no solution in place. The OpenTelemetry Community welcomes any
suggestions for improvement!
manage the contrib repositories (e.g. GraphQL). This is a known problem, and
there is currently no solution in place. The OpenTelemetry Community welcomes
any suggestions for improvement!
There is also a huge focus on
[stabilizing semantic conventions](https://docs.google.com/document/d/1ghvajKaipiNZso3fDtyNxU7x1zx0_Eyd02OGpMGEpLE/edit#),
@ -287,7 +287,7 @@ JavaScript environments are akin to the Wild West of Development due to:
- Two similar, but different server-side runtimes: Node.js and
[Deno](https://deno.land)
One of J’s suggestions is to treat OTel Javascript as a hierarchy, which starts
One of J’s suggestions is to treat OTel JavaScript as a hierarchy, which starts
with a Core JavaScript team that splits into two subgroups: front-end web group,
and back-end group. Front-end and back-end would in turn split. For example, for
the back-end, have a separate Deno and Node.js group.

4
content/en/blog/2023/end-user-q-and-a-02.md
View File

@ -246,8 +246,8 @@ World” program to send data to the Collector, and nothing is showing up, and
need some guidance around this. How do we help folks who aren’t super familiar
with Docker and aren’t super familiar with OpenTelemetry? Can we have some super
simple reference implementations to hold folks’ hands as they get started? For
example, for a Ruby developer, clone X repo, run `docker compose up`[^1], and
everything should be up and running. That way, they can focus on learning
example, for a Ruby developer, clone X repository, run `docker compose up`[^1],
and everything should be up and running. That way, they can focus on learning
OpenTelemetry, rather than mess around with Docker networking and other
distracting things.

4
content/en/blog/2023/jmx-metric-insight/index.md
View File

@ -58,9 +58,9 @@ To start Zookeeper:
zookeeper-server-start /usr/local/etc/kafka/zookeeper.properties
```
### Attach the OpenTelemetry java instrumentation agent
### Attach the OpenTelemetry Java instrumentation agent
Before starting the kafka broker, attach the OpenTelemetry java instrumentation
Before starting the Kafka broker, attach the OpenTelemetry Java instrumentation
agent to Kafka Broker by providing options in the KAFKA_OPTS environment
variable. You can download the latest release of the agent from
[here](https://github.com/open-telemetry/opentelemetry-java-instrumentation/releases).

2
content/en/blog/2023/k8s-runtime-observability/index.md
View File

@ -467,7 +467,7 @@ The
[example sources](https://github.com/kubeshop/tracetest/tree/main/examples/tracetesting-kubernetes/kubetracing)
used in this article, and
[setup instructions](https://github.com/kubeshop/tracetest/blob/main/examples/tracetesting-kubernetes/setup-k8s-with-k3d.md)
are available from the Tracetest repo.
are available from the Tracetest repository.
## References

4
content/en/blog/2023/lambda-release.md
View File

@ -17,7 +17,7 @@ Services (AWS) Lambdas.
If you've been monitoring Lambdas using OTel for a while now, you may be
slightly confused by this announcement. You might think something like: OTel has
had a
[repo for Lambda layers](https://github.com/open-telemetry/opentelemetry-lambda)
[repository for Lambda layers](https://github.com/open-telemetry/opentelemetry-lambda)
and they've been available on AWS for years.
You're totally correct. Rest assured, we're not reinventing the wheel. However,
@ -35,7 +35,7 @@ there are some pre-existing problems that may impact users:
The FaaS SIG has addressed the above-mentioned shortcomings:
- We have written new Github Actions to release the Lambda layers ourselves,
- We have written new GitHub Actions to release the Lambda layers ourselves,
thus empowering the community to make its own release decisions.
- Separated the Collector and instrumentation layers to give users options when
instrumenting their Lambdas. We now offer a standalone Lambda layer for the

6
content/en/blog/2023/otel-in-focus-01.md
View File

@ -27,10 +27,10 @@ release notes.
other changes.
- [Go v1.12.0/v0.35.0](https://github.com/open-telemetry/opentelemetry-go/releases/tag/v1.12.0)
celebrates an important release of updated semantic conventions and metric
instruments, along with a handful of bug fixes and other important changes.
instruments, along with a handful of bugfixes and other important changes.
- [JavaScript](https://github.com/open-telemetry/opentelemetry-js/releases) has
released v1.4.0 of the API, v.1.9.0 of core, and v0.35.0 of experimental
packages! These releases include important bug fixes in tracing around clock
packages! These releases include important bugfixes in tracing around clock
drift, as well as other deprecations and enhancements.
- [Java v1.22.0](https://github.com/open-telemetry/opentelemetry-java/releases/tag/v1.22.0)
includes several fixes and enhancements for exporters, as well as other
@ -40,7 +40,7 @@ release notes.
instrumentations for Spring Web MVC, JMS 3.0 (Jakarta), and Spring JMS 6.0.
- [Operator v0.68.0](https://github.com/open-telemetry/opentelemetry-operator/releases/tag/v0.68.0)
brings with it a new OpAMP Bridge service,and a fix to allow for deployment to
OpenShift clusters, along with other bug fixes.
OpenShift clusters, along with other bugfixes.
- [Collector v1.0.0 (RC4)](https://github.com/open-telemetry/opentelemetry-collector/releases/tag/v0.70.0)
and
[Collector Contrib v0.70.0](https://github.com/open-telemetry/opentelemetry-collector-contrib/releases/tag/v0.70.0)

4
content/en/blog/2023/otel-in-focus-02.md
View File

@ -40,7 +40,7 @@ have been released with several major changes to be aware of:
have been added! These are components that act as exporters and receivers,
allowing you to route data through pipelines. Please see the component docs
for more information.
- Many bug fixes and enhancements.
- Many bugfixes and enhancements.
##### [Go](/docs/instrumentation/go/)
@ -72,7 +72,7 @@ planning a release of new documentation for PHP soon.
[v1.16](https://github.com/open-telemetry/opentelemetry-python/releases/tag/v1.16.0)
has been released with deprecations to Jaeger exporters, several performance
improvements and bug fixes, and changes to Prometheus export.
improvements and bugfixes, and changes to Prometheus export.
##### [.NET](/docs/instrumentation/net/)

2
content/en/blog/2023/otel-in-focus-04.md
View File

@ -48,7 +48,7 @@ has been released for the collector. The
[operator](https://github.com/open-telemetry/opentelemetry-operator/releases/tag/v0.75.0)
has been updated to v0.75.0, adding support for feature gates in the operator.
This release includes several bug fixes and improvements to connectors, along
This release includes several bugfixes and improvements to connectors, along
with a breaking change to the `confmap` component.
##### [Go](/docs/instrumentation/go/)

10
content/en/blog/2023/otel-in-focus-05.md
View File

@ -57,14 +57,14 @@ marks the stable release of the OpenTelemetry Metric API in Go.
is the Release Candidate for the Log Bridge. This release enables log appenders
to bridge logs from existing log frameworks, allowing users to configure the Log
SDK and dictate how logs are processed and exported. In addition,
opentelemetry-opentracing-shim is now stable, as well as other bug fixes and
opentelemetry-opentracing-shim is now stable, as well as other bugfixes and
improvements.
[Java Instrumentation](https://github.com/open-telemetry/opentelemetry-java-instrumentation/releases/tag/v1.26.0)
includes instrumentation support for vertx-sql-client, as well as several bug
fixes.
#### [Javascript](/docs/instrumentation/js/)
#### [JavaScript](/docs/instrumentation/js/)
[Version 1.13](https://github.com/open-telemetry/opentelemetry-js/releases/tag/v1.13.0)
has been released, adding support for gRPC log export. In addition, a couple
@ -74,8 +74,8 @@ bugs have been fixed.
[Version 1.18](https://github.com/open-telemetry/opentelemetry-python/releases/tag/v1.18.0)
adds a new feature that allows histogram aggregation to be set using an
environment variable, as well as various bug fixes related to resource
detection, exporting, and suppressing instrumentation.
environment variable, as well as various bugfixes related to resource detection,
exporting, and suppressing instrumentation.
- Add ability to select histogram aggregation with an environment variable
- Move protobuf encoding to its own package
@ -87,7 +87,7 @@ detection, exporting, and suppressing instrumentation.
#### [.NET](/docs/instrumentation/net/)
[Version 1.5.0-rc1](https://github.com/open-telemetry/opentelemetry-dotnet/releases/tag/core-1.5.0-rc.1)
includes many bug fixes across a variety of packages.
includes many bugfixes across a variety of packages.
## Project and Community Updates

26
content/en/blog/2023/otel-in-focus-06.md
View File

@ -40,11 +40,11 @@ is the `service.PipelineConfig` in favor of the `pipelines.Config`. Enhancements
include the addition of a dry run flag, allowing TLS settings to be provided in
memory, updates to the connector nodes, and updates to various modules.
0.79.0 includes deprecations, enhancements, and bug fixes. The release
deprecates the `Host.GetExporters` function, adds connectors to the output of
the components command, improves the behavior of the scraperhelper, optimizes
the multiBatcher to avoid a global lock, and fixes a bug related to data
replication in connectors.
0.79.0 includes deprecations, enhancements, and bugfixes. The release deprecates
the `Host.GetExporters` function, adds connectors to the output of the
components command, improves the behavior of the scraperhelper, optimizes the
multiBatcher to avoid a global lock, and fixes a bug related to data replication
in connectors.
In addition,
[collector-contrib](https://github.com/open-telemetry/opentelemetry-collector-contrib/releases/tag/v0.80.0)
@ -52,7 +52,7 @@ has been released. Some notable changes include the addition of the WebSocket
processor, updates to metric units in various receivers, and deprecation of
options in the SumoLogic exporter. Check the release notes for more details.
0.79.0 included a number of bug fixes and enhancements, including breaking
0.79.0 included a number of bugfixes and enhancements, including breaking
changes to hashing algorithms and changes to endpoint requirements. Enhancements
include improved metric retrieval and new configuration options, while bug fixes
address issues with subprocess cancellation and incorrect log stream filtering.
@ -61,18 +61,18 @@ There were three releases of the
[Operator](https://github.com/open-telemetry/opentelemetry-operator/releases/tag/v0.80.0)
in June. The latest, release v0.80.0, introduces enhancements such as adding a
Skywalking parser and populating credentials for Prometheus CR scrape configs.
Bug fixes include a fix for the upgrade mechanism and empty global scrape
Bugfixes include a fix for the upgrade mechanism and empty global scrape
interval, and a new component was added for NGINX auto-instrumentation in the
operator.
0.79.0 of the Operator includes enhancements such as Prometheus metric exporter
support for Node.js auto-instrumentation and the ability to inject the service
version into the environment of the instrumented application. There is also a
bug fix regarding the OpenTelemetry Collector version not displaying properly in
bugfix regarding the OpenTelemetry Collector version not displaying properly in
the status field.
0.78.0 includes enhancements such as updating various packages, support for
scaling on Pod custom metrics, and improved config validation. Bug fixes include
scaling on Pod custom metrics, and improved config validation. Bugfixes include
addressing issues related to prometheus relabel configs and setting the default
go auto-instrumentation version correctly. Components that were updated include
the OpenTelemetry Collector, OpenTelemetry Contrib, Java auto-instrumentation,
@ -88,7 +88,7 @@ opentelemetry-sdk-extension-autoconfigure. The release also includes various bug
fixes and improvements for the API, SDK, metrics, exporters, testing, SDK
extensions, and semantic conventions.
Remember - the Log Bridge API is not intended for end-users. It is used to
Remember - the Log Bridge API is not intended for end users. It is used to
bridge existing appenders (e.g., Log4j, SLf4J, Logback, JUL) into OpenTelemetry.
[Java Instrumentation](https://github.com/open-telemetry/opentelemetry-java-instrumentation/releases/tag/v1.27.0)
@ -103,10 +103,10 @@ 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.
- Bug fixes related to Logback MDC instrumentation, kafka metrics reporter,
jetty context leak, filtering scalar Mono/Flux instances, and others.
- Bugfixes related to Logback MDC instrumentation, Kafka metrics reporter, jetty
context leak, filtering scalar Mono/Flux instances, and others.
#### [Javascript](/docs/instrumentation/js/)
#### [JavaScript](/docs/instrumentation/js/)
[Version 1.14](https://github.com/open-telemetry/opentelemetry-js/releases/tag/v1.14.0)
includes an optional `forceFlush` method to the `SpanExporter` interface.

10
content/en/blog/2023/php-auto-instrumentation/index.md
View File

@ -78,11 +78,11 @@ function helloWorld() {
In the same way, we have implemented tracing support for some of the most
important `interfaces/libraries/frameworks` that are parts of
[Contrib](https://github.com/open-telemetry/opentelemetry-php-contrib/tree/main/src/Instrumentation)
repo. Each `auto-instrumentation` package uses above `hook` function in order to
register and provide tracing functionality. One missing thing, not mentioned yet
is an `API` `SDK` used to create traces and other necessary components. This is
the responsibility of the opentelemetry-php
[main](https://github.com/open-telemetry/opentelemetry-php) repo which is
repository. Each `auto-instrumentation` package uses above `hook` function in
order to register and provide tracing functionality. One missing thing, not
mentioned yet is an `API` `SDK` used to create traces and other necessary
components. This is the responsibility of the opentelemetry-php
[main](https://github.com/open-telemetry/opentelemetry-php) repository which is
foundation for everything.
![php-rel](php-rel.png)

4
content/en/blog/2023/php-beta-release.md
View File

@ -19,8 +19,8 @@ if you’d like to see a bug squashed or a new feature added.
There are many ways you can get started with our project:
- There are [examples](/docs/instrumentation/php/examples/) in the repo to get
you started.
- There are [examples](/docs/instrumentation/php/examples/) in the repository to
get you started.
- The [getting started guide](/docs/instrumentation/php/getting-started/) can
help you to instrument a sample PHP file.
- The [quote service](/docs/demo/services/quote/), is a demo application built

5
content/en/blog/2023/sunsetting-opencensus.md
View File

@ -69,7 +69,7 @@ package repositories like NPM and PyPI. **We encourage all OpenCensus users to
begin planning their project's migration to OpenTelemetry now.**
One exception to this is the [census-instrumentation/opencensus-python][]
repo[^python-timeline].
repository[^python-timeline].
[go shim]:
https://github.com/open-telemetry/opentelemetry-go/tree/main/bridge/opencensus
@ -86,7 +86,8 @@ repo[^python-timeline].
A number of projects within the `opencensus-python` repository are still
being used as recommended production solutions. These projects will continue
to be maintained. For details regarding maintenance timeline, next steps for
migration, and general support questions, reach out to repo maintainers.
migration, and general support questions, reach out to repository
maintainers.
[^shim-next-release]: Python and JavaScript shim packages will be released soon.
[^shim-support]:

2
content/en/community/_index.md
View File

@ -18,7 +18,7 @@ OpenTelemetry maintainers? Check out the
We organize the community into Special Interest Groups (SIGs) in order to
improve our workflow and more easily manage a community project.
[Read more](https://github.com/open-telemetry/community#special-interest-groups)
from our [community repo](https://github.com/open-telemetry/community).
from our [community repository](https://github.com/open-telemetry/community).
## Ecosystem

2
content/en/docs/collector/trace-receiver.md
View File

@ -1953,7 +1953,7 @@ func appendTraceSpans(backend *BackendSystem, backendScopeSpans *ptrace.ScopeSpa
> #### Check your work
>
> - Added `traceId` and `backendSpanId` variables to respectively represent the
> trace and the span id and initialized them with the helper functions created
> trace and the span ID and initialized them with the helper functions created
> previously
> - Added `backendSpanStartTime` and `backendSpanFinishTime` to represent the
> start and the end time of the operation. For the tutorial, any

2
content/en/docs/collector/troubleshooting.md
View File

@ -35,4 +35,4 @@ following:
For detailed recommendations, including common problems, see
[Troubleshooting](https://github.com/open-telemetry/opentelemetry-collector/blob/main/docs/troubleshooting.md)
from the Collector repo.
from the Collector repository.

10
content/en/docs/concepts/instrumentation/libraries.md
View File

@ -40,7 +40,7 @@ without the user's input or configuration.
If you have any feedback or want to add a new convention - please come and
contribute!
[Instrumentation Slack](https://cloud-native.slack.com/archives/C01QZFGMLQ7) or
[Specification repo](https://github.com/open-telemetry/opentelemetry-specification)
[Specification repository](https://github.com/open-telemetry/opentelemetry-specification)
are a good places to start!
## When **not** to instrument
@ -88,14 +88,14 @@ considerations to help you decide how to minimize dependency hell:
avoid updating it unless you have to use new features.
- While your instrumentation stabilizes, consider shipping it as a separate
package, so that will never cause issues for users who don't use it. You can
keep it in your repo, or
keep it in your repository, or
[add it to OpenTelemetry](https://github.com/open-telemetry/oteps/blob/main/text/0155-external-modules.md#contrib-components),
so it will ship with other instrumentation packages.
- Semantic Conventions are [stable, but subject to evolution][]: while this does
not cause any functional issues, you may need to update your instrumentation
every once in a while. Having it in a preview plugin or in OpenTelemetry
contrib repo may help keeping conventions up-to-date without breaking changes
for your users.
contrib repository may help keeping conventions up-to-date without breaking
changes for your users.
[stable, but subject to evolution]:
/docs/specs/otel/versioning-and-stability/#semantic-conventions-stability
@ -308,7 +308,7 @@ There might be some exceptions:
- downstream service supports custom correlation protocol.
- best effort with custom propagator: use OpenTelemetry trace context if
compatible.
- or generate and stamp custom correlation ids on the span.
- or generate and stamp custom correlation IDs on the span.
### In-process

2
content/en/docs/concepts/signals/baggage.md
View File

@ -38,7 +38,7 @@ headers alongside the current context. If your relevant network traffic is
entirely within your own network, then this caveat may not apply.
Common use cases include information that’s only accessible further up a stack.
This can include things like Account Identification, User Ids, Product Ids, and
This can include things like Account Identification, User IDs, Product IDs, and
origin IPs, for example. Passing these down your stack allows you to then add
them to your Spans in downstream services to make it easier to filter when
you’re searching in your Observability back-end.

2
content/en/docs/concepts/signals/traces.md
View File

@ -339,7 +339,7 @@ HTTP request or remote procedure call.
#### Internal
Internal spans represent operations which do not cross a process boundary.
Things like instrumenting a function call or an express middleware may use
Things like instrumenting a function call or an Express middleware may use
internal spans.
#### Producer

26
content/en/docs/demo/manual-span-attributes.md
View File

@ -23,9 +23,9 @@ demo:
| Name | Type | Description |
| ---------------------- | ------ | ------------------------------ |
| `app.cart.items.count` | number | Number of unique items in cart |
| `app.product.id` | string | Product Id for cart item |
| `app.product.id` | string | Product ID for cart item |
| `app.product.quantity` | string | Quantity for cart item |
| `app.user.id` | string | User Id |
| `app.user.id` | string | User ID |
## CheckoutService
@ -33,13 +33,13 @@ demo:
| ---------------------------- | ------ | ------------------------------- |
| `app.cart.items.count` | number | Total number of items in cart |
| `app.order.amount` | number | Order amount |
| `app.order.id` | string | Order Id |
| `app.order.id` | string | Order ID |
| `app.order.items.count` | number | Number of unique items in order |
| `app.payment.transaction.id` | string | Payment transaction Id |
| `app.payment.transaction.id` | string | Payment transaction ID |
| `app.shipping.amount` | number | Shipping amount |
| `app.shipping.tracking.id` | string | Shipping tracking Id |
| `app.shipping.tracking.id` | string | Shipping tracking ID |
| `app.user.currency` | string | User currency |
| `app.user.id` | string | User Id |
| `app.user.id` | string | User ID |
## CurrencyService
@ -53,7 +53,7 @@ demo:
| Name | Type | Description |
| --------------------- | ------ | --------------------------------- |
| `app.email.recipient` | string | Email used for order confirmation |
| `app.order.id` | string | Order Id |
| `app.order.id` | string | Order ID |
## FeatureFlagService
@ -74,12 +74,12 @@ demo:
| `app.currency` | string | User currency |
| `app.currency.new` | string | New currency to set |
| `app.order.total` | number | Order total cost |
| `app.product.id` | string | Product Id |
| `app.product.id` | string | Product ID |
| `app.product.quantity` | number | Product quantity |
| `app.products.count` | number | Total products displayed |
| `app.request.id` | string | Request Id |
| `app.session.id` | string | Session Id |
| `app.user.id` | string | User Id |
| `app.request.id` | string | Request ID |
| `app.session.id` | string | Session ID |
| `app.user.id` | string | User ID |
## LoadGenerator
@ -100,7 +100,7 @@ demo:
| Name | Type | Description |
| --------------------------- | ------ | ------------------------------------- |
| `app.product.id` | string | Product Id |
| `app.product.id` | string | Product ID |
| `app.product.name` | string | Product name |
| `app.products.count` | number | Number of products in catalog |
| `app.products_search.count` | number | Number of products returned in search |
@ -127,5 +127,5 @@ demo:
| -------------------------- | ------ | ----------------------------- |
| `app.shipping.cost.total` | number | Total shipping cost |
| `app.shipping.items.count` | number | Total items to ship |
| `app.shipping.tracking.id` | string | Shipping tracking Id |
| `app.shipping.tracking.id` | string | Shipping tracking ID |
| `app.shipping.zip_code` | string | Zip code used to ship item(s) |

2
content/en/docs/demo/service-table.md
View File

@ -10,7 +10,7 @@ View [Service Graph](../architecture/) to visualize request flows.
| ----------------------------------------------------- | ------------- | -------------------------------------------------------------------------------------------------------------------------------------------- |
| [accountingservice](../services/accounting/) | Go | Processes incoming orders and count the sum of all orders (mock/). |
| [adservice](../services/ad/) | Java | Provides text ads based on given context words. |
| [cartservice](../services/cart/) | DotNet | Stores the items in the user's shopping cart in Redis and retrieves it. |
| [cartservice](../services/cart/) | .NET | Stores the items in the user's shopping cart in Redis and retrieves it. |
| [checkoutservice](../services/checkout/) | Go | Retrieves user cart, prepares order and orchestrates the payment, shipping and the email notification. |
| [currencyservice](../services/currency/) | C++ | Converts one money amount to another currency. Uses real values fetched from European Central Bank. It's the highest QPS service. |
| [emailservice](../services/email/) | Ruby | Sends users an order confirmation email (mock/). |

4
content/en/docs/demo/services/currency.md
View File

@ -78,8 +78,8 @@ Adding span events is accomplished using `Span->AddEvent(name)`.
### Set span status
Make sure to set your span status to Ok, or Error accordingly. You can do this
using `Span->SetStatus(status)`
Make sure to set your span status to `Ok`, or `Error` accordingly. You can do
this using `Span->SetStatus(status)`
```cpp
span->SetStatus(StatusCode::kOk);

2
content/en/docs/demo/services/kafka.md
View File

@ -13,7 +13,7 @@ accounting and fraud detection services.
This service relies on the OpenTelemetry Java Agent and the built in
[JMX Metric Insight Module](https://github.com/open-telemetry/opentelemetry-java-instrumentation/tree/main/instrumentation/jmx-metrics/javaagent)
to capture
[kafka broker metrics](https://github.com/open-telemetry/opentelemetry-java-instrumentation/blob/main/instrumentation/jmx-metrics/javaagent/kafka-broker.md)
[Kafka broker metrics](https://github.com/open-telemetry/opentelemetry-java-instrumentation/blob/main/instrumentation/jmx-metrics/javaagent/kafka-broker.md)
and send them off to the collector via OTLP.
The agent is passed into the process using the `-javaagent` command line

2
content/en/docs/demo/services/product-catalog.md
View File

@ -85,7 +85,7 @@ context.
```
Adding attributes to a span is accomplished using `SetAttributes` on the span
object. In the `GetProduct` function an attribute for the product id is added to
object. In the `GetProduct` function an attribute for the product ID is added to
the span.
```go

2
content/en/docs/demo/services/recommendation.md
View File

@ -6,7 +6,7 @@ spelling: cSpell:ignore instrumentor cpython NOTSET
---
This service is responsible to get a list of recommended products for the user
based on existing product ids the user is browsing.
based on existing product IDs the user is browsing.
[Recommendation service source](https://github.com/open-telemetry/opentelemetry-demo/blob/main/src/recommendationservice/)

6
content/en/docs/demo/services/shipping.md
View File

@ -13,10 +13,10 @@ Shipping service is built primarily with Tonic, Reqwest, and OpenTelemetry
Libraries/Components. Other sub-dependencies are included in `Cargo.toml`.
Depending on your framework and runtime, you may consider consulting
[rust docs](/docs/instrumentation/rust/) to supplement. You'll find examples of
async and sync spans in quote requests and tracking ID's respectively.
[Rust docs](/docs/instrumentation/rust/) to supplement. You'll find examples of
async and sync spans in quote requests and tracking IDs respectively.
The `build.rs` supports development outside docker, given a rust installation.
The `build.rs` supports development outside docker, given a Rust installation.
Otherwise, consider building with `docker compose` to edit / assess changes as
needed.

4
content/en/docs/instrumentation/cpp/manual.md
View File

@ -96,8 +96,8 @@ auto new_context = propagator->Extract(carrier, current_ctx);
auto remote_span = opentelemetry::trace::propagation::GetSpan(new_context);
```
`Context` contains the meta-data of the currently active Span including Span Id,
Trace Id, and flags. Context Propagation is an important mechanism in
`Context` contains the metadata of the currently active Span including Span ID,
Trace ID, and flags. Context Propagation is an important mechanism in
distributed tracing to transfer this Context across service boundary often
through HTTP headers. OpenTelemetry provides a text-based approach to propagate
context to remote services using the W3C Trace Context HTTP headers.

2
content/en/docs/instrumentation/erlang/_index.md
View File

@ -23,7 +23,7 @@ OpenTelemetry Erlang supports Erlang 23+ and Elixir 1.13+.
## Repositories
- [opentelemetry-erlang](https://github.com/open-telemetry/opentelemetry-erlang):
Main repo containing the API, SDK and OTLP Exporter.
Main repository containing the API, SDK and OTLP Exporter.
- [opentelemetry-erlang-contrib](https://github.com/open-telemetry/opentelemetry-erlang-contrib):
Helpful libraries and instrumentation libraries for Erlang/Elixir projects
like [Phoenix](https://www.phoenixframework.org/) and

2
content/en/docs/instrumentation/erlang/exporters.md
View File

@ -17,7 +17,7 @@ collector, which can then export Spans to a self-hosted service like Zipkin or
Jaeger, as well as commercial services. For a full list of available exporters,
see the [registry](/ecosystem/registry/?component=exporter).
For testing purposes the `opentelemetry-erlang` repo has a Collector
For testing purposes the `opentelemetry-erlang` repository has a Collector
configuration,
[config/otel-collector-config.yaml](https://github.com/open-telemetry/opentelemetry-erlang/blob/main/config/otel-collector-config.yaml)
that can be used as a starting point. This configuration is used in

8
content/en/docs/instrumentation/erlang/getting-started.md
View File

@ -16,8 +16,8 @@ the Phoenix Web Framework.
### Prerequisites
Ensure that you have erlang, elixir, postgres (or the database of your choice),
and phoenix installed locally. The phoenix
Ensure that you have Erlang, Elixir, PostgreSQL (or the database of your
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.
@ -279,8 +279,8 @@ name because it does not have an `http.route`.
This is the custom span we added to our private method. You'll notice it only
has the one attribute that we set, `roll => 2`. You should also note that it is
part of the same trace as our `<<"/api/rolldice">>` span,
`224439009126930788594246993907621543552` and has a parent span id of
`5581431573601075988` which is the span id of the `<<"/api/rolldice">>` span.
`224439009126930788594246993907621543552` and has a parent span ID of
`5581431573601075988` which is the span ID of the `<<"/api/rolldice">>` span.
That means that this span is a child of that one, and will be shown below it
when rendered in your tracing tool of choice.

2
content/en/docs/instrumentation/java/automatic/_index.md
View File

@ -18,7 +18,7 @@ service or app code, see [Manual instrumentation](../manual).
## Setup
1. Download [opentelemetry-javaagent.jar][] from [Releases][] of the
`opentelemetry-java-instrumentation` repo and place the JAR in your
`opentelemetry-java-instrumentation` repository and place the JAR in your
preferred directory. The JAR file contains the agent and instrumentation
libraries.
2. Add `-javaagent:path/to/opentelemetry-javaagent.jar` and other config to

8
content/en/docs/instrumentation/java/getting-started.md
View File

@ -8,7 +8,7 @@ weight: 10
This page will show you how to get started with OpenTelemetry in Java.
You will learn how you can instrument a simple java application automatically,
You will learn how you can instrument a simple Java application automatically,
in such a way that [traces][], [metrics][] and [logs][] are emitted to the
console.
@ -23,7 +23,7 @@ Ensure that you have the following installed locally:
The following example uses a basic
[Spring Boot](https://spring.io/guides/gs/spring-boot/) application. If you are
not using Spring Boot, that's ok — you can use OpenTelemetry Java with other web
not using Spring Boot, that's OK — you can use OpenTelemetry Java with other web
frameworks as well, such as Apache Wicket and Play. For a complete list of
libraries for supported frameworks, see the
[registry](/ecosystem/registry/?component=instrumentation&language=java).
@ -131,8 +131,8 @@ application at launch time. While you can [configure the Java agent][] in a
number of ways, the steps below use environment variables.
1. Download [opentelemetry-javaagent.jar][] from [Releases][] of the
`opentelemetry-java-instrumentation` repo. The JAR file contains the agent
and all automatic instrumentation packages:
`opentelemetry-java-instrumentation` repository. The JAR file contains the
agent and all automatic instrumentation packages:
```console
curl -L -O https://github.com/open-telemetry/opentelemetry-java-instrumentation/releases/latest/download/opentelemetry-javaagent.jar

8
content/en/docs/instrumentation/java/manual.md
View File

@ -137,7 +137,7 @@ As an aside, if you are writing library instrumentation, it is strongly
recommended that you provide your users the ability to inject an instance of
`OpenTelemetry` into your instrumentation code. If this is not possible for some
reason, you can fall back to using an instance from the `GlobalOpenTelemetry`
class. Note that you can't force end-users to configure the global, so this is
class. Note that you can't force end users to configure the global, so this is
the most brittle option for library instrumentation.
## Traces
@ -658,7 +658,7 @@ To use this workflow:
A log appender bridges logs from a log framework into the OpenTelemetry
[Log SDK](#logs-sdk) using the [Logs Bridge API][logs bridge API]. Log appenders
are available for various popular java log frameworks:
are available for various popular Java log frameworks:
- [Log4j2 Appender][log4j2 appender]
- [Logback Appender][logback appender]
@ -700,7 +700,7 @@ Log correlation with traces is available by installing
#### Log context instrumentation
OpenTelemetry provides components which enrich log context with trace context
for various popular java log frameworks:
for various popular Java log frameworks:
- [Log4j context data instrumentation][log4j context instrumentation]
- [Logback MDC instrumentation][logback context instrumentation]
@ -870,7 +870,7 @@ Views provide a mechanism for controlling how measurements are aggregated into
metrics. They consist of an `InstrumentSelector` and a `View`. The instrument
selector consists of a series of options for selecting which instruments the
view applies to. Instruments can be selected by a combination of name, type,
meter name, meter version, and meter schema url. The view describes how
meter name, meter version, and meter schema URL. The view describes how
measurement should be aggregated. The view can change the name, description, the
aggregation, and define the set of attribute keys that should be retained.

4
content/en/docs/instrumentation/js/getting-started/browser.md
View File

@ -73,7 +73,7 @@ tsc --init
```
Then acquire [parcel](https://parceljs.org/), which will (among other things)
let you work in Typescript.
let you work in TypeScript.
```shell
npm install --save-dev parcel
@ -231,7 +231,7 @@ developer toolbar you should see some traces being exported:
### Add Instrumentations
If you want to instrument AJAX requests, User Interactions and others, you can
If you want to instrument Ajax requests, User Interactions and others, you can
register additional instrumentations for those:
```javascript

6
content/en/docs/instrumentation/js/getting-started/nodejs.md
View File

@ -22,7 +22,7 @@ Ensure that you have the following installed locally:
## Example Application
The following example uses a basic [Express](https://expressjs.com/)
application. If you are not using Express, that's ok — you can use OpenTelemetry
application. If you are not using Express, that's OK — you can use OpenTelemetry
JavaScript with other web frameworks as well, such as Koa and Nest.JS. For a
complete list of libraries for supported frameworks, see the
[registry](/ecosystem/registry/?component=instrumentation&language=js).
@ -59,7 +59,7 @@ npm install express
### Create and launch an HTTP Server
Create a file named `app.ts` (or `app.js` if not using typescript) and add the
Create a file named `app.ts` (or `app.js` if not using TypeScript) and add the
following code to it:
<!-- prettier-ignore-start -->
@ -161,7 +161,7 @@ application code. One tool commonly used for this task is the
[--require](https://nodejs.org/api/cli.html#-r---require-module) flag.
Create a file named `instrumentation.ts` (or `instrumentation.js` if not using
typescript) , which will contain your instrumentation setup code.
TypeScript) , which will contain your instrumentation setup code.
<!-- prettier-ignore-start -->
{{< tabpane langEqualsHeader=true >}}

2
content/en/docs/instrumentation/js/manual.md
View File

@ -447,7 +447,7 @@ const doWork = () => {
A [Span Event](/docs/concepts/signals/traces/#span-events) is a human-readable
message on an [`Span`](/docs/concepts/signals/traces/#spans) that represents a
discrete event with no duration that can be tracked by a single time stamp. You
discrete event with no duration that can be tracked by a single timestamp. You
can think of it like a primitive log.
```js

2
content/en/docs/instrumentation/js/propagation.md
View File

@ -39,7 +39,7 @@ you're using to have services communicate with one another. Or you many have
requirements that instrumentation libraries cannot fulfill, even if they exist.
When you must propagate context manually, you can use the
[context api](/docs/instrumentation/js/context).
[context API](/docs/instrumentation/js/context).
The following generic example demonstrates how you can propagate trace context
manually.

2
content/en/docs/instrumentation/js/resources.md
View File

@ -139,7 +139,7 @@ process.on('SIGINT', function () {
});
```
To get the id of your container detected automatically for you, install the
To get the ID of your container detected automatically for you, install the
following additional dependency:
```sh

2
content/en/docs/instrumentation/php/automatic.md
View File

@ -86,7 +86,7 @@ The extension can be installed via pecl,
{{< tab "Linux (apt)" >}}sudo apt-get install gcc make autoconf{{< /tab >}}
{{< tab "MacOS (homebrew)" >}}brew install gcc make autoconf{{< /tab >}}
{{< tab "macOS (homebrew)" >}}brew install gcc make autoconf{{< /tab >}}
{{< /tabpane >}}

6
content/en/docs/instrumentation/php/getting-started.md
View File

@ -42,8 +42,8 @@ packages.{{% /alert %}}
The following example uses a basic
[Slim Framework](https://www.slimframework.com/) application. If you are not
using Slim, that's ok — you can use OpenTelemetry PHP with other web frameworks
as well, such as Wordpress, Symfony and Laravel. For a complete list of
using Slim, that's OK — you can use OpenTelemetry PHP with other web frameworks
as well, such as WordPress, Symfony and Laravel. For a complete list of
libraries for supported frameworks, see the
[registry](/ecosystem/registry/?component=instrumentation&language=php).
@ -106,7 +106,7 @@ Next, you’ll use the OpenTelemetry PHP extension to
{{< tab "Linux (apt)" >}}sudo apt-get install gcc make autoconf{{< /tab >}}
{{< tab "MacOS (homebrew)" >}}brew install gcc make autoconf{{< /tab >}}
{{< tab "macOS (homebrew)" >}}brew install gcc make autoconf{{< /tab >}}
{{< /tabpane >}}

2
content/en/docs/instrumentation/php/manual.md
View File

@ -634,7 +634,7 @@ $eventLogger->logEvent('foo', $record);
</details>
### Integrations for 3rd-party logging libraries
### Integrations for third-party logging libraries
#### Monolog

2
content/en/docs/instrumentation/php/propagation.md
View File

@ -53,7 +53,7 @@ library. There may not be an instrumentation library that matches a library
you're using to have services communicate with one another. Or you many have
requirements that instrumentation libraries cannot fulfill, even if they exist.
When you must propagate context manually, you can use the context api.
When you must propagate context manually, you can use the context API.
The following presents an example of an outgoing HTTP request:

4
content/en/docs/instrumentation/python/_index.md
View File

@ -48,8 +48,8 @@ implementations, etc., visit the [Registry](/ecosystem/registry/?s=python).
### Installing Cutting-edge Packages
There is some functionality that has not yet been released to PyPI. In that
situation, you may want to install the packages directly from the repo. This can
be done by cloning the repository and doing an
situation, you may want to install the packages directly from the repository.
This can be done by cloning the repository and doing an
[editable install](https://pip.pypa.io/en/stable/reference/pip_install/#editable-installs):
```sh

4
content/en/docs/instrumentation/python/automatic/agent-config.md
View File

@ -65,7 +65,7 @@ For example, `exporter_otlp_endpoint` would convert to
## Python-specific Configuration
There are some python specific configuration options you can set by prefixing
There are some Python specific configuration options you can set by prefixing
environment variables with `OTEL_PYTHON_`.
### Excluded URLs
@ -152,7 +152,7 @@ export OTEL_PYTHON_INSTRUMENTATION_SANITIZE_REDIS=true
## Disabling Specific Instrumentations
The Python agent by default will detect a python program's packages and
The Python agent by default will detect a Python program's packages and
instrument any packages it can. This makes instrumentation easy, but can result
in too much or unwanted data.

2
content/en/docs/instrumentation/python/automatic/example.md
View File

@ -8,7 +8,7 @@ spelling: cSpell:ignore instrumentor Referer Starlette WSGI MSIE
This page demonstrates how to use Python auto-instrumentation in OpenTelemetry.
The example is based on an [OpenTracing example][]. You can download or view the
[source files][] used in this page from the `opentelemetry-python` repo.
[source files][] used in this page from the `opentelemetry-python` repository.
This example uses three different scripts. The main difference between them is
how they are instrumented:

2
content/en/docs/instrumentation/python/getting-started.md
View File

@ -20,7 +20,7 @@ Ensure that you have the following installed locally:
## Example Application
The following example uses a basic [Flask](https://flask.palletsprojects.com/)
application. If you are not using Flask, that's ok — you can use OpenTelemetry
application. If you are not using Flask, that's OK — you can use OpenTelemetry
Python with other web frameworks as well, such as Django and FastAPI. For a
complete list of libraries for supported frameworks, see the
[registry](/ecosystem/registry/?component=instrumentation&language=python).

4
content/en/docs/instrumentation/ruby/automatic.md
View File

@ -6,7 +6,7 @@ spelling: cSpell:ignore faraday sinatra
weight: 20
---
Automatic instrumentation in ruby is done via instrumentation packages, and most
Automatic instrumentation in Ruby is done via instrumentation packages, and most
commonly, the `opentelemetry-instrumentation-all` package. These are called
Instrumentation Libraries.
@ -93,7 +93,7 @@ end
### Next steps
Instrumentation libraries are the easiest way to generate lots of useful
telemetry data about your ruby apps. But they don't generate data specific to
telemetry data about your Ruby apps. But they don't generate data specific to
your application's logic! To do that, you'll need to enrich the automatic
instrumentation from instrumentation libraries with
[manual instrumentation](../manual).

2
content/en/docs/instrumentation/ruby/getting-started.md
View File

@ -31,7 +31,7 @@ While tested, support for `truffleruby` is on a best-effort basis at this time.
## Example Application
The following example uses a basic [Rails](https://rubyonrails.org/)
application. If you are not using Rails, that's ok — you can use OpenTelemetry
application. If you are not using Rails, that's OK — you can use OpenTelemetry
Ruby with other web frameworks as well, such as Sinatra and Rack. For a complete
list of libraries for supported frameworks, see the
[registry](/ecosystem/registry/?component=instrumentation&language=ruby).

2
content/en/docs/instrumentation/ruby/manual.md
View File

@ -37,7 +37,7 @@ TracerProvider. If you are using
Rails app, then one will be registered for you.
```ruby
# If in a rails app, this lives in config/initializers/opentelemetry.rb
# If in a Rails app, this lives in config/initializers/opentelemetry.rb
require "opentelemetry/sdk"
OpenTelemetry::SDK.configure do |c|

2
content/en/docs/instrumentation/swift/manual.md
View File

@ -145,7 +145,7 @@ to access the current span from an arbitrary point in your code.
Spans can also be annotated with additional attributes. All spans will be
automatically annotated with the `Resource` attributes attached to the tracer
provider. The Opentelemetry-swift sdk already provides instrumentation of common
provider. The Opentelemetry-swift SDK already provides instrumentation of common
attributes in the `SDKResourceExtension` instrumentation. In this example a span
for a network request capturing details about that request using existing
[semantic conventions](/docs/specs/otel/trace/semantic_conventions/).

2
content/en/docs/k8s-operator/automatic.md
View File

@ -297,7 +297,7 @@ spec:
EOF
```
By default, the Instrumentation resource that auto-instruments python services
By default, the Instrumentation resource that auto-instruments Python services
uses `otlp` with the `http/protobuf` protocol. This means that the configured
endpoint must be able to receive OTLP over `http/protobuf`. Therefore, the
example uses `http://demo-collector:4318`, which will connect to the `http` port

6
content/en/docs/migration/opentracing.md
View File

@ -25,7 +25,7 @@ of the OpenTracing and OpenTelemetry APIs are listed in the table below.
| [Go][] | 1.13 | 1.16 |
| [Java][] | 7 | 8 |
| [Python][] | 2.7 | 3.6 |
| [Javascript][] | 6 | 8.5 |
| [JavaScript][] | 6 | 8.5 |
| [.NET][] | 1.3 | 1.4 |
| [C++][] | 11 | 11 |
@ -157,9 +157,9 @@ be switched to OpenTelemetry at the same time. Be sure to check that any
critical baggage items are still being propagated before rolling these changes
into production.
### Context management in Javascript
### Context management in JavaScript
In Javascript, the OpenTelemetry API makes use of commonly available context
In JavaScript, the OpenTelemetry API makes use of commonly available context
managers, such as `async_hooks` for Node.js and `Zones.js` for the browser.
These context managers make tracing instrumentation a much less invasive and
onerous task, compared to adding a span as a parameter to every method which

6
content/en/docs/specs/status.md
View File

@ -33,7 +33,7 @@ Deprecated, Removed.
- **Draft** components are under design, and have not been added to the
specification.
- **Experimental** components are released and available for beta testing.
- **Stable** components are backwards compatible and covered under long term
- **Stable** components are backward compatible and covered under long term
support.
- **Deprecated** components are stable but may eventually be removed.
@ -47,8 +47,8 @@ Note that while the OpenTelemetry clients conform to a shared specification,
they are developed independently.
Checking the current status for each client in the README of its
[github repo](https://github.com/open-telemetry) is recommended. Client support
for specific features can be found in the
[GitHub repository](https://github.com/open-telemetry) is recommended. Client
support for specific features can be found in the
[specification compliance tables](https://github.com/open-telemetry/opentelemetry-specification/blob/main/spec-compliance-matrix.md).
Note that, for each of the following sections, the **Collector** status is the

2
content/en/ecosystem/demo.md
View File

@ -33,4 +33,4 @@ If you find yourself asking questions like:
For more information, see:
- [Demo documentation](/docs/demo/)
- [Demo repo](https://github.com/open-telemetry/opentelemetry-demo)
- [Demo repository](https://github.com/open-telemetry/opentelemetry-demo)

28
content/en/ecosystem/integrations.md
View File

@ -12,20 +12,20 @@ projects.
OpenTelemetry provides integration with the following open source projects.
| External Project\* | OpenTelemetry Supported Components |
| --------------------------------------------------------- | -------------------------------------------------------- |
| [Apache Kafka](https://kafka.apache.org/) | Collector |
| [Apache SkyWalking](https://skywalking.apache.org) | Collector |
| [Elasticsearch](https://github.com/elastic/elasticsearch) | Collector, C++, Java, Python |
| [Fluent Bit](https://fluentbit.io/) | Collector |
| [Graphite](https://graphiteapp.org/) | Collector |
| [Jaeger](https://www.jaegertracing.io/) | Collector, DotNet, Go, Java, JS, PHP, Python, Ruby, Rust |
| [OpenCensus](https://opencensus.io/) | Collector, Python |
| [OpenTracing](https://opentracing.io/) | DotNet, Go, Java, JS, Python, Ruby |
| [OpenMetrics](https://openmetrics.io/) [^partial-support] | Collector |
| [Prometheus](https://prometheus.io/) [^partial-support] | Collector, C++, Go, Java, JS, Rust |
| [Zipkin](https://zipkin.io/) | Collector, DotNet, Go, Java, JS, PHP, Python, Rust |
| [W3C trace-context](https://www.w3.org/TR/trace-context/) | DotNet, Go, Java, JS, Python, Ruby |
| External Project\* | OpenTelemetry Supported Components |
| --------------------------------------------------------- | ------------------------------------------------------ |
| [Apache Kafka](https://kafka.apache.org/) | Collector |
| [Apache SkyWalking](https://skywalking.apache.org) | Collector |
| [Elasticsearch](https://github.com/elastic/elasticsearch) | Collector, C++, Java, Python |
| [Fluent Bit](https://fluentbit.io/) | Collector |
| [Graphite](https://graphiteapp.org/) | Collector |
| [Jaeger](https://www.jaegertracing.io/) | Collector, .NET, Go, Java, JS, PHP, Python, Ruby, Rust |
| [OpenCensus](https://opencensus.io/) | Collector, Python |
| [OpenTracing](https://opentracing.io/) | .NET, Go, Java, JS, Python, Ruby |
| [OpenMetrics](https://openmetrics.io/) [^partial-support] | Collector |
| [Prometheus](https://prometheus.io/) [^partial-support] | Collector, C++, Go, Java, JS, Rust |
| [Zipkin](https://zipkin.io/) | Collector, .NET, Go, Java, JS, PHP, Python, Rust |
| [W3C trace-context](https://www.w3.org/TR/trace-context/) | .NET, Go, Java, JS, Python, Ruby |
\* _Projects are listed alphabetically_.

4
data/registry/collector-receiver-kafkametrics.yml
View File

@ -9,7 +9,7 @@ tags:
repo: https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/receiver/kafkametricsreceiver
license: Apache 2.0
description:
Kafka metrics receiver collects kafka metrics (brokers, topics, partitions,
consumer groups) from kafka server,
Kafka metrics receiver collects Kafka metrics (brokers, topics, partitions,
consumer groups) from Kafka server,
authors: OpenTelemetry Authors
otVersion: latest

2
data/registry/collector-receiver-loki.yml
View File

@ -8,6 +8,6 @@ tags:
- collector
repo: https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/receiver/lokireceiver
license: Apache 2.0
description: The Loki receiver implements the Loki push api
description: The Loki receiver implements the Loki Push API
authors: OpenTelemetry Authors
otVersion: latest

2
data/registry/collector-receiver-saphana.yml
View File

@ -10,7 +10,7 @@ repo: https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/mai
license: Apache 2.0
description:
This receiver can fetch stats from a SAP HANA instance. It leverages the
driver written by SAP for connecting to SAP HANA with the golang sql module to
driver written by SAP for connecting to SAP HANA with the golang SQL module to
execute several monitoring queries.
authors: OpenTelemetry Authors
otVersion: latest

3
data/registry/instrumentation-dotnet-awslambda.yml
View File

@ -9,6 +9,7 @@ tags:
repo: https://github.com/open-telemetry/opentelemetry-dotnet-contrib/tree/main/src/OpenTelemetry.Instrumentation.AWSLambda
license: Apache 2.0
description:
This repo contains SDK to instrument Lambda handler to create incoming span.
This repository contains SDK to instrument Lambda handler to create incoming
span.
authors: OpenTelemetry Authors
otVersion: latest

2
data/registry/instrumentation-go-splunksql.yml
View File

@ -1,4 +1,4 @@
title: splunksql -- Instrumentation for database/sql
title: splunksql -- Instrumentation for `database/sql`
registryType: instrumentation
isThirdParty: true
language: go

2
data/registry/instrumentation-go-xsam-database-sql.yml
View File

@ -1,4 +1,4 @@
title: otelsql -- Instrumentation for database/sql
title: otelsql -- Instrumentation for `database/sql`
registryType: instrumentation
isThirdParty: true
language: go

4
data/registry/instrumentation-js-pg.yml
View File

@ -1,4 +1,4 @@
title: Postgres Instrumentation
title: PostgreSQL Instrumentation
registryType: instrumentation
isThirdParty: false
language: js
@ -7,5 +7,5 @@ tags:
- instrumentation
repo: https://github.com/open-telemetry/opentelemetry-js-contrib/tree/main/plugins/node/opentelemetry-instrumentation-pg
license: Apache 2.0
description: Postgres instrumentation for Node.js.
description: PostgreSQL instrumentation for Node.js.
authors: OpenTelemetry Authors

4
data/registry/instrumentation-js-redis-4.yml
View File

@ -1,4 +1,4 @@
title: OpenTelemetry redis Instrumentation for Node.js
title: OpenTelemetry Redis Instrumentation for Node.js
registryType: instrumentation
isThirdParty: false
language: js
@ -9,5 +9,5 @@ tags:
repo: https://github.com/open-telemetry/opentelemetry-js-contrib/tree/main/plugins/node/opentelemetry-instrumentation-redis-4
license: Apache 2.0
description:
This module provides automatic instrumentation for the redis@^4.0.0 package.
This module provides automatic instrumentation for the `redis@^4.0.0` package.
otVersion: latest

4
data/registry/instrumentation-php-wordpress.yml
View File

@ -1,4 +1,4 @@
title: OpenTelemetry Wordpress auto-instrumentation
title: OpenTelemetry WordPress auto-instrumentation
registryType: instrumentation
isThirdParty: false
language: php
@ -8,6 +8,6 @@ tags:
- php
repo: https://github.com/open-telemetry/opentelemetry-php-contrib/tree/main/src/Instrumentation/Wordpress
license: Apache 2.0
description: Instrumentation Library for Wordpress
description: Instrumentation Library for WordPress
authors: OpenTelemetry Authors
otVersion: latest

2
data/registry/resource-detector-js-container.yml
View File

@ -9,7 +9,7 @@ tags:
repo: https://github.com/open-telemetry/opentelemetry-js-contrib/tree/main/detectors/node/opentelemetry-resource-detector-container
license: Apache 2.0
description:
Resource detector for container id. Compatible with OpenTelemetry JS API and
Resource detector for container ID. Compatible with OpenTelemetry JS API and
SDK 1.0+.
authors: OpenTelemetry Authors
otVersion: latest