Update prettier to 3.4.0 (#5684)
Signed-off-by: svrnm <neumanns@cisco.com>
This commit is contained in:
Severin Neumann
GitHub
parent
f7c0ac79b4
commit
1505d05656
|
|
@ -44,8 +44,8 @@ We, the OTel Communications SIG, meet every two weeks on Monday at 10:00 PT.
|
|||
Check out the [OpenTelemetry community calendar][] for the Zoom link and any
|
||||
updates to this schedule.
|
||||
|
||||
Meeting notes are available as a public [Google doc][]. If you have trouble accessing
|
||||
the doc, get in touch in the `#otel-comms` channel on [Slack][].
|
||||
Meeting notes are available as a public [Google doc][]. If you have trouble
|
||||
accessing the doc, get in touch in the `#otel-comms` channel on [Slack][].
|
||||
|
||||
## Roles
|
||||
|
||||
|
|
@ -74,8 +74,8 @@ Here is a list of community roles with current and previous members:
|
|||
- [Morgan McLean](https://github.com/mtwo)
|
||||
- [jparsana](https://github.com/jparsana)
|
||||
|
||||
Learn more about roles in the [community repository][]. Thanks to [all who have already
|
||||
contributed][contributors]!
|
||||
Learn more about roles in the [community repository][]. Thanks to [all who have
|
||||
already contributed][contributors]!
|
||||
|
||||
## Licenses
|
||||
|
||||
|
|
|
|||
|
|
@ -74,6 +74,7 @@ your questions!
|
|||
Thanks [Sarah Novotny](https://twitter.com/sarahnovotny) for review and
|
||||
feedback!
|
||||
|
||||
_A version of this article was [originally posted][] on [medium.com/opentelemetry](https://medium.com/opentelemetry)._
|
||||
_A version of this article was [originally posted][] on
|
||||
[medium.com/opentelemetry](https://medium.com/opentelemetry)._
|
||||
|
||||
[originally posted]: {{% param canonical_url %}}
|
||||
|
|
|
|||
|
|
@ -6,6 +6,7 @@ canonical_url: https://medium.com/opentelemetry/announcing-the-2021-opentelemetr
|
|||
---
|
||||
|
||||
The OpenTelemetry project is excited to announce the 2021 OpenTelemetry
|
||||
Governance Committee (GC) election. For all the details, see the [original post][].
|
||||
Governance Committee (GC) election. For all the details, see the [original
|
||||
post][].
|
||||
|
||||
[original post]: {{% param canonical_url %}}
|
||||
|
|
|
|||
|
|
@ -6,6 +6,7 @@ canonical_url: https://medium.com/opentelemetry/opentelemetry-observes-internati
|
|||
---
|
||||
|
||||
Happy International Women’s Day! The OpenTelemetry project would like to extend
|
||||
our thanks to all our women contributors. For all the details, see the [original post][].
|
||||
our thanks to all our women contributors. For all the details, see the [original
|
||||
post][].
|
||||
|
||||
[original post]: {{% param canonical_url %}}
|
||||
|
|
|
|||
|
|
@ -229,8 +229,8 @@ in the NGINX module and we need to fix that.
|
|||
|
||||
### The fix
|
||||
|
||||
To fix our problem we [added some checks to the module for NGINX][], that make sure
|
||||
that the trace headers are only set once.
|
||||
To fix our problem we [added some checks to the module for NGINX][], that make
|
||||
sure that the trace headers are only set once.
|
||||
|
||||
This fix is contained in the [v1.0.1 release of the otel-webserver-module][].
|
||||
This means you can update the `Dockerfile` to install the NGINX module like the
|
||||
|
|
|
|||
|
|
@ -40,12 +40,13 @@ The SDK is used to configure what happens with the data collected by the API.
|
|||
This typically includes processing it and exporting it out of process for
|
||||
analysis, often to an observability platform.
|
||||
|
||||
The API entry point for metrics is the [meter provider][]. It provides meters for
|
||||
different scopes, where a scope is just a logical unit of application code. For example,
|
||||
instrumentation for an HTTP client library would have a different scope and therefore
|
||||
a different meter than instrumentation for a database client library. You use meters
|
||||
to obtain instruments. You use instruments to report measurements, which consist
|
||||
of a value and set of attributes. This Java code snippet demonstrates the workflow:
|
||||
The API entry point for metrics is the [meter provider][]. It provides meters
|
||||
for different scopes, where a scope is just a logical unit of application code.
|
||||
For example, instrumentation for an HTTP client library would have a different
|
||||
scope and therefore a different meter than instrumentation for a database client
|
||||
library. You use meters to obtain instruments. You use instruments to report
|
||||
measurements, which consist of a value and set of attributes. This Java code
|
||||
snippet demonstrates the workflow:
|
||||
|
||||
```java
|
||||
OpenTelemetry openTelemetry = // declare OpenTelemetry instance
|
||||
|
|
@ -73,7 +74,8 @@ and when the sum of the things is more important than their individual values
|
|||
the distribution of measurements is relevant for analysis. For example, a
|
||||
histogram is a natural choice for tracking response times for HTTP servers,
|
||||
because it's useful to analyze the distribution of response times to evaluate
|
||||
SLAs and identify trends. To learn more, see the guidelines for [instrument selection][].
|
||||
SLAs and identify trends. To learn more, see the guidelines for [instrument
|
||||
selection][].
|
||||
|
||||
I mentioned earlier that the SDK aggregates measurements from instruments. Each
|
||||
instrument type has a default aggregation strategy (or simply [aggregation][])
|
||||
|
|
@ -125,10 +127,10 @@ request, you can determine:
|
|||
requests resolve quickly but a small number of requests take a long time and
|
||||
bring down the average.
|
||||
|
||||
The second type of OpenTelemetry histogram is the [exponential
|
||||
bucket histogram][]. Exponential bucket histograms have buckets and bucket
|
||||
counts, but instead of explicitly defining the bucket boundaries, the boundaries
|
||||
are computed based on an exponential scale. More specifically, each bucket is
|
||||
The second type of OpenTelemetry histogram is the [exponential bucket
|
||||
histogram][]. Exponential bucket histograms have buckets and bucket counts, but
|
||||
instead of explicitly defining the bucket boundaries, the boundaries are
|
||||
computed based on an exponential scale. More specifically, each bucket is
|
||||
defined by an index _i_ and has bucket boundaries _(base\*\*i, base\*\*(i+1)]_,
|
||||
where _base\*\*i_ means that _base_ is raised to the power of _i_. The base is
|
||||
derived from a scale factor that is adjustable to reflect the range of reported
|
||||
|
|
@ -197,13 +199,14 @@ large range of measurement values.
|
|||
|
||||
Let's bring everything together with a proper demonstration comparing explicit
|
||||
bucket histograms to exponential bucket histograms. I've put together some
|
||||
[example code][] that simulates tracking response time to an HTTP server in milliseconds.
|
||||
It records one million samples to an explicit bucket histogram with the default buckets,
|
||||
and to an exponential bucket histogram with a number of buckets that produces roughly
|
||||
the same size of [OTLP][] -encoded, Gzip-compressed payload as the explicit bucket
|
||||
defaults. Through trial and error, I determined that ~40 exponential buckets produce
|
||||
an equivalent payload size to the default explicit bucket histogram with 11 buckets.
|
||||
(Your results may vary.)
|
||||
[example code][] that simulates tracking response time to an HTTP server in
|
||||
milliseconds. It records one million samples to an explicit bucket histogram
|
||||
with the default buckets, and to an exponential bucket histogram with a number
|
||||
of buckets that produces roughly the same size of [OTLP][] -encoded,
|
||||
Gzip-compressed payload as the explicit bucket defaults. Through trial and
|
||||
error, I determined that ~40 exponential buckets produce an equivalent payload
|
||||
size to the default explicit bucket histogram with 11 buckets. (Your results may
|
||||
vary.)
|
||||
|
||||
I wanted the distribution of samples to reflect what we might see in an actual
|
||||
HTTP server, with bands of response times corresponding to different operations.
|
||||
|
|
|
|||
|
|
@ -8,12 +8,13 @@ cSpell:ignore: Centos centos7 Debajit debuggability libmod uncompress webserver
|
|||
---
|
||||
|
||||
If you are using Apache HTTP Server and in dire need of some observability tool
|
||||
to monitor your web server, the [OpenTelemetry Module for Apache HTTP Server][] is
|
||||
the right candidate for you: it enables tracing of incoming requests to the server
|
||||
and it will capture the response time of many modules (including `mod_proxy`) involved
|
||||
in such an incoming request. With that you will get hierarchical time consumption
|
||||
by each module. This article demonstrates the monitoring capabilities of the OpenTelemetry
|
||||
Module for Apache HTTP Server and quick guide to get started with the module.
|
||||
to monitor your web server, the [OpenTelemetry Module for Apache HTTP Server][]
|
||||
is the right candidate for you: it enables tracing of incoming requests to the
|
||||
server and it will capture the response time of many modules (including
|
||||
`mod_proxy`) involved in such an incoming request. With that you will get
|
||||
hierarchical time consumption by each module. This article demonstrates the
|
||||
monitoring capabilities of the OpenTelemetry Module for Apache HTTP Server and
|
||||
quick guide to get started with the module.
|
||||
|
||||
## Getting Started with OpenTelemetry Module
|
||||
|
||||
|
|
|
|||
|
|
@ -172,10 +172,11 @@ reducing the scope of the collector service account to a single namespace.
|
|||
|
||||
## Using Resource detector processor
|
||||
|
||||
As of [recently][pr#832], the [OpenTelemetry operator][] sets the `OTEL_RESOURCE_ATTRIBUTES`
|
||||
environment variable on the collector container with the K8s pod attributes. This
|
||||
lets you to use the resource detector processor, which attaches the environment variable
|
||||
values to the spans. This only works when the collector is deployed in sidecar mode.
|
||||
As of [recently][pr#832], the [OpenTelemetry operator][] sets the
|
||||
`OTEL_RESOURCE_ATTRIBUTES` environment variable on the collector container with
|
||||
the K8s pod attributes. This lets you to use the resource detector processor,
|
||||
which attaches the environment variable values to the spans. This only works
|
||||
when the collector is deployed in sidecar mode.
|
||||
|
||||
For example, if you deploy the following manifest:
|
||||
|
||||
|
|
|
|||
|
|
@ -8,8 +8,8 @@ cSpell:ignore: Kowall Logz Pothulapati unconference Vineeth
|
|||
|
||||
The OpenTelemetry project maintainers, and members of the governance committee
|
||||
and technical committee are excited to be at [KubeCon NA][] in a few weeks! Join
|
||||
in to meet up in person or virtually for [OpenTelemetry](/) activities in Detroit
|
||||
from October 24 - 28, 2022.
|
||||
in to meet up in person or virtually for [OpenTelemetry](/) activities in
|
||||
Detroit from October 24 - 28, 2022.
|
||||
|
||||
There are talks, workshops, an unconference as well as a project booth where you
|
||||
are welcome to stop by, say Hi! and tell us about how you are using
|
||||
|
|
|
|||
|
|
@ -350,8 +350,8 @@ Before I wrap this up, I do want to give a HUGE shoutout to
|
|||
[Luiz Aoqui](https://www.linkedin.com/in/luizaoqui/) of HashiCorp, who helped me
|
||||
tweak my Nomad jobspecs, and to
|
||||
[Riaan Nolan](https://www.linkedin.com/in/riaannolan/), for his continued work
|
||||
on HashiQube. (Aside, both [Luiz] and [Riaan] were my guests on the [On-Call
|
||||
Me Maybe Podcast]!)
|
||||
on HashiQube. (Aside, both [Luiz] and [Riaan] were my guests on the [On-Call Me
|
||||
Maybe Podcast]!)
|
||||
|
||||
I will now leave you with a picture of Phoebe the rat, peering out of a pink
|
||||
basket. Doesn’t she look cute? 🥰
|
||||
|
|
|
|||
|
|
@ -25,9 +25,9 @@ projects? I don't know about you, but for me, up until last year, the prospect
|
|||
of contributing to open source was just plain _scary_!! I mean, when you open up
|
||||
a
|
||||
[pull request](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-pull-requests)
|
||||
(PR), _[you are putting yourself out there]_, to be judged by those little GitHub
|
||||
avatars that make up the approvers list for the repository you're contributing to.
|
||||
YIKES!
|
||||
(PR), _[you are putting yourself out there]_, to be judged by those little
|
||||
GitHub avatars that make up the approvers list for the repository you're
|
||||
contributing to. YIKES!
|
||||
|
||||
But as scary as the thought of opening a PR might be, it's also SO VERY
|
||||
SATISFYING to see your contributions merged into a codebase. And most
|
||||
|
|
|
|||
|
|
@ -47,12 +47,13 @@ and join the discussion on our
|
|||
|
||||
- [Announcement from Elastic][]
|
||||
- [OpenTelemetry Semantic Conventions][]
|
||||
- [OTEP 199: Merge Elastic Common Schema with OpenTelemetry Semantic Conventions][]
|
||||
- [OTEP Issue 197: Proposal: Add support for Elastic Common Schema (ECS)
|
||||
in OpenTelemetry][]
|
||||
- [OTEP 199: Merge Elastic Common Schema with OpenTelemetry Semantic
|
||||
Conventions][]
|
||||
- [OTEP Issue 197: Proposal: Add support for Elastic Common Schema (ECS) in
|
||||
OpenTelemetry][]
|
||||
- [OTEP Pull Request 199: Support Elastic Common Schema in OpenTelemetry][]
|
||||
- [OTEP Pull Request 222: Support Elastic Common Schema (ECS)
|
||||
in OpenTelemetry][]
|
||||
- [OTEP Pull Request 222: Support Elastic Common Schema (ECS) in
|
||||
OpenTelemetry][]
|
||||
|
||||
[Announcement from Elastic]:
|
||||
https://elastic.co/blog/ecs-elastic-common-schema-otel-opentelemetry-announcement
|
||||
|
|
|
|||
|
|
@ -6,13 +6,14 @@ cSpell:ignore: Ganesh Ruslan subsetting Vernekar Vovalov
|
|||
canonical_url: https://dyladan.me/histograms/2023/05/04/exponential-histograms/
|
||||
---
|
||||
|
||||
Previously, in [Why Histograms?][] and [Histograms vs Summaries][], I went over the
|
||||
basics of histograms and summaries, explaining the tradeoffs, benefits, and limitations
|
||||
of each. Because they're easy to understand and demonstrate, those posts focused
|
||||
on so-called explicit bucket histograms. The exponential bucket histogram, also referred
|
||||
to as native histogram in Prometheus, is a low-cost, efficient alternative to explicit
|
||||
bucket histograms. In this post, I go through what they are, how they work, and the
|
||||
problems they solve that explicit bucket histograms struggle with.
|
||||
Previously, in [Why Histograms?][] and [Histograms vs Summaries][], I went over
|
||||
the basics of histograms and summaries, explaining the tradeoffs, benefits, and
|
||||
limitations of each. Because they're easy to understand and demonstrate, those
|
||||
posts focused on so-called explicit bucket histograms. The exponential bucket
|
||||
histogram, also referred to as native histogram in Prometheus, is a low-cost,
|
||||
efficient alternative to explicit bucket histograms. In this post, I go through
|
||||
what they are, how they work, and the problems they solve that explicit bucket
|
||||
histograms struggle with.
|
||||
|
||||
## Types of histograms
|
||||
|
||||
|
|
@ -129,9 +130,8 @@ relative error = (bucketWidth / 2) / bucketMidpoint
|
|||
= 4.329%
|
||||
```
|
||||
|
||||
For more information regarding histogram errors, see [OTEP 149][] and the [specification
|
||||
for
|
||||
exponential histogram aggregations][].
|
||||
For more information regarding histogram errors, see [OTEP 149][] and the
|
||||
[specification for exponential histogram aggregations][].
|
||||
|
||||
## Choosing a scale
|
||||
|
||||
|
|
|
|||
|
|
@ -8,8 +8,8 @@ author: '[Severin Neumann](https://github.com/svrnm)'
|
|||
---
|
||||
|
||||
The OpenTelemetry project maintainers, members of the governance committee, and
|
||||
technical committee are excited to be at [KubeCon EU][] in Amsterdam from April 18 -
|
||||
21, 2023!
|
||||
technical committee are excited to be at [KubeCon EU][] in Amsterdam from April
|
||||
18 - 21, 2023!
|
||||
|
||||
Read on to learn about all the things related OpenTelemetry during KubeCon.
|
||||
|
||||
|
|
@ -41,14 +41,15 @@ Come network with OpenTelemetry maintainers and core contributors during the
|
|||
[OpenTelemetry project meeting](https://sched.co/1JWS7), on Tuesday April 18,
|
||||
2023 from 16:00 - 17:00. You can attend with a _standard in-person pass_.
|
||||
|
||||
[Observability Day][] _fosters collaboration, discussion, and knowledge sharing of
|
||||
cloud-native observability projects_. This event will be held on April 18, 2023 from
|
||||
9:00 - 17:00. There will be several sessions on OpenTelemetry as well.
|
||||
[Observability Day][] _fosters collaboration, discussion, and knowledge sharing
|
||||
of cloud-native observability projects_. This event will be held on April 18,
|
||||
2023 from 9:00 - 17:00. There will be several sessions on OpenTelemetry as well.
|
||||
|
||||
> <i class="far fa-exclamation-triangle"></i> **IMPORTANT access note**: You
|
||||
> need an _in-person all-access_ pass for on-site access to **Observability
|
||||
> Day**. For details, see [KubeCon registration][]. If you have a virtual ticket,
|
||||
> you will be able to follow **Observability Day** through a live stream.
|
||||
> Day**. For details, see [KubeCon registration][]. If you have a virtual
|
||||
> ticket, you will be able to follow **Observability Day** through a live
|
||||
> stream.
|
||||
|
||||
## OpenTelemetry Project Booth
|
||||
|
||||
|
|
@ -66,9 +67,9 @@ You will find us in the Solutions Showcase in Hall 5, Kiosk Number 20.
|
|||
|
||||
You can help us improve the project by sharing your thoughts and feedback about
|
||||
your OpenTelemetry adoption, implementation, and usage! We also invite you to
|
||||
fill out our [community survey][]. We will create action items from your comments
|
||||
as appropriate. Check [#otel-user-research][] in CNCF's Slack instance for survey
|
||||
results and action item updates to come after KubeCon EU.
|
||||
fill out our [community survey][]. We will create action items from your
|
||||
comments as appropriate. Check [#otel-user-research][] in CNCF's Slack instance
|
||||
for survey results and action item updates to come after KubeCon EU.
|
||||
|
||||
Come join us to listen, learn, and get involved in OpenTelemetry.
|
||||
|
||||
|
|
|
|||
|
|
@ -8,8 +8,8 @@ author: '[Severin Neumann](https://github.com/svrnm) (Cisco)'
|
|||
---
|
||||
|
||||
The OpenTelemetry project maintainers, members of the governance committee, and
|
||||
technical committee are thrilled to be at [KubeCon NA][] in Chicago from November
|
||||
6 - 9, 2023.
|
||||
technical committee are thrilled to be at [KubeCon NA][] in Chicago from
|
||||
November 6 - 9, 2023.
|
||||
|
||||
Read on to learn about all the things related OpenTelemetry during KubeCon.
|
||||
|
||||
|
|
@ -78,14 +78,15 @@ OpenTelemetry maintainers in making OpenTelemetry better for everyone during the
|
|||
|
||||
## Co-located Events
|
||||
|
||||
[Observability Day][] _fosters collaboration, discussion, and knowledge sharing of
|
||||
cloud-native observability projects_. This event will be held on November 6, 2023
|
||||
from 9am - 5pm. There will be several sessions on OpenTelemetry as well.
|
||||
[Observability Day][] _fosters collaboration, discussion, and knowledge sharing
|
||||
of cloud-native observability projects_. This event will be held on November 6,
|
||||
2023 from 9am - 5pm. There will be several sessions on OpenTelemetry as well.
|
||||
|
||||
> <i class="far fa-exclamation-triangle"></i> **IMPORTANT access note**: You
|
||||
> need an _in-person all-access_ pass for on-site access to **Observability
|
||||
> Day**. For details, see [KubeCon registration][]. If you have a virtual ticket,
|
||||
> you will be able to follow **Observability Day** through a live stream.
|
||||
> Day**. For details, see [KubeCon registration][]. If you have a virtual
|
||||
> ticket, you will be able to follow **Observability Day** through a live
|
||||
> stream.
|
||||
|
||||
## OpenTelemetry Project Booth
|
||||
|
||||
|
|
@ -101,9 +102,9 @@ Project Pavilion. If you’re lucky, you may even pick up some OpenTelemetry swa
|
|||
|
||||
You can help us improve the project by sharing your thoughts and feedback about
|
||||
your OpenTelemetry adoption, implementation, and usage. We also invite you to
|
||||
fill out our [community survey][]. We will create action items from your comments
|
||||
as appropriate. Check [#otel-user-research][] in CNCF's Slack instance for survey
|
||||
results and action item updates to come after KubeCon NA.
|
||||
fill out our [community survey][]. We will create action items from your
|
||||
comments as appropriate. Check [#otel-user-research][] in CNCF's Slack instance
|
||||
for survey results and action item updates to come after KubeCon NA.
|
||||
|
||||
## OpenTelemetry Observatory
|
||||
|
||||
|
|
|
|||
|
|
@ -420,8 +420,8 @@ extend Yoda's code to do the following:
|
|||
[transform or attributes processors](/docs/collector/transforming-telemetry/).
|
||||
1. Add [tracing](/docs/concepts/signals/traces/) support by emitting spans,
|
||||
where it makes sense.
|
||||
1. Add an Observability backend such as OpenSearch (along with [Data Prepper]) to
|
||||
the setup, allowing to ingest spans and logs in OTLP format.
|
||||
1. Add an Observability backend such as OpenSearch (along with [Data Prepper])
|
||||
to the setup, allowing to ingest spans and logs in OTLP format.
|
||||
1. Once you have traces and logs ingested in a backend, try to correlate these
|
||||
two telemetry signal types in the backend along with a frontend such as
|
||||
Grafana.
|
||||
|
|
|
|||
|
|
@ -13,7 +13,8 @@ across many popular languages, OpenTelemetry reduces the cognitive load of
|
|||
polyglot teams by providing one vocabulary and one toolkit.
|
||||
|
||||
While that’s all true, today I’d like to zoom in on a specific signal and
|
||||
language, and talk about the performance of the [OpenTelemetry Java][] metrics SDK.
|
||||
language, and talk about the performance of the [OpenTelemetry Java][] metrics
|
||||
SDK.
|
||||
|
||||
## Metrics Primer
|
||||
|
||||
|
|
@ -472,9 +473,11 @@ benefit every application, but are especially important to applications with
|
|||
high cardinality and with strict performance SLAs.
|
||||
|
||||
If you’re reading this and considering Java metric systems, I hope you chose
|
||||
[OpenTelemetry Java][]. It’s a powerful and highly performant tool on its own, but
|
||||
comes with APIs for other key observability signals, a [rich instrumentation ecosystem](https://github.com/open-telemetry/opentelemetry-java-instrumentation/blob/main/docs/supported-libraries.md),
|
||||
[implementations in a variety of other languages](/docs/languages/), and a well-supported
|
||||
[OpenTelemetry Java][]. It’s a powerful and highly performant tool on its own,
|
||||
but comes with APIs for other key observability signals, a
|
||||
[rich instrumentation ecosystem](https://github.com/open-telemetry/opentelemetry-java-instrumentation/blob/main/docs/supported-libraries.md),
|
||||
[implementations in a variety of other languages](/docs/languages/), and a
|
||||
well-supported
|
||||
[open governance structure](https://github.com/open-telemetry/community).
|
||||
|
||||
## Acknowledgements
|
||||
|
|
|
|||
|
|
@ -10,8 +10,9 @@ author: '[Severin Neumann](https://github.com/svrnm) (Cisco)'
|
|||
---
|
||||
|
||||
The OpenTelemetry project maintainers, members of the governance committee, and
|
||||
technical committee are thrilled to be at [KubeCon + CloudNativeCon Europe][] and
|
||||
at the co-located [Observability Day](https://events.linuxfoundation.org/kubecon-cloudnativecon-europe/co-located-events/observability-day/)
|
||||
technical committee are thrilled to be at [KubeCon + CloudNativeCon Europe][]
|
||||
and at the co-located
|
||||
[Observability Day](https://events.linuxfoundation.org/kubecon-cloudnativecon-europe/co-located-events/observability-day/)
|
||||
in Paris from March 19 - 22, 2024.
|
||||
|
||||
Read on to learn about all the things related OpenTelemetry during KubeCon.
|
||||
|
|
@ -45,9 +46,9 @@ it again right before KubeCon!
|
|||
|
||||
## Observability Day
|
||||
|
||||
_[Observability Day][] fosters collaboration, discussion, and knowledge sharing of
|
||||
cloud-native observability projects_. This event will be held on March 19, 2024 from
|
||||
9:00 - 17:35. There will be several sessions on OpenTelemetry as well:
|
||||
_[Observability Day][] fosters collaboration, discussion, and knowledge sharing
|
||||
of cloud-native observability projects_. This event will be held on March 19,
|
||||
2024 from 9:00 - 17:35. There will be several sessions on OpenTelemetry as well:
|
||||
|
||||
- **[Welcome + Project Updates](https://sched.co/1YGT9)**<br> by Eduardo Silva,
|
||||
FluentBit & Austin Parker, honeycomb.io<br> Tuesday, March 19th • 09:00 -
|
||||
|
|
@ -89,8 +90,8 @@ cloud-native observability projects_. This event will be held on March 19, 2024
|
|||
{{% alert title="Important access note" color="danger" %}}
|
||||
|
||||
You need an _in-person all-access_ pass for on-site access to **Observability
|
||||
Day**. For details, see [KubeCon registration][]. If you have a virtual ticket, you
|
||||
will be able to follow **Observability Day** through a live stream.
|
||||
Day**. For details, see [KubeCon registration][]. If you have a virtual ticket,
|
||||
you will be able to follow **Observability Day** through a live stream.
|
||||
|
||||
[kubecon registration]:
|
||||
https://events.linuxfoundation.org/kubecon-cloudnativecon-europe/register/
|
||||
|
|
|
|||
|
|
@ -8,8 +8,8 @@ author: '[Severin Neumann](https://github.com/svrnm) (Cisco)'
|
|||
---
|
||||
|
||||
The OpenTelemetry project maintainers, members of the governance committee, and
|
||||
technical committee are thrilled to be at [KubeCon NA][] in Salt Lake City from November
|
||||
12 - 15, 2024.
|
||||
technical committee are thrilled to be at [KubeCon NA][] in Salt Lake City from
|
||||
November 12 - 15, 2024.
|
||||
|
||||
Read on to learn about all the things related OpenTelemetry during KubeCon.
|
||||
|
||||
|
|
@ -78,15 +78,17 @@ first steps: documentation, Collector, Java, JS, Ruby, Python, .NET, and more.
|
|||
|
||||
## Observability Day
|
||||
|
||||
_[Observability Day][] fosters collaboration, discussion, and knowledge sharing of
|
||||
cloud-native observability projects_. This event will be held on November 12, 2024
|
||||
from 9am to 6pm. [Check the full schedule](https://colocatedeventsna2024.sched.com/overview/type/Observability+Day)
|
||||
_[Observability Day][] fosters collaboration, discussion, and knowledge sharing
|
||||
of cloud-native observability projects_. This event will be held on November 12,
|
||||
2024 from 9am to 6pm.
|
||||
[Check the full schedule](https://colocatedeventsna2024.sched.com/overview/type/Observability+Day)
|
||||
to find your favorite talks about Observability and OpenTelemetry.
|
||||
|
||||
> <i class="far fa-exclamation-triangle"></i> **IMPORTANT access note**: You
|
||||
> need an _in-person all-access_ pass for on-site access to **Observability
|
||||
> Day**. For details, see [KubeCon registration][]. If you have a virtual ticket,
|
||||
> you will be able to follow **Observability Day** through a live stream.
|
||||
> Day**. For details, see [KubeCon registration][]. If you have a virtual
|
||||
> ticket, you will be able to follow **Observability Day** through a live
|
||||
> stream.
|
||||
|
||||
## OpenTelemetry Observatory
|
||||
|
||||
|
|
|
|||
|
|
@ -3,9 +3,9 @@ title: Distributions
|
|||
weight: 25
|
||||
---
|
||||
|
||||
The OpenTelemetry project currently offers [pre-built distributions][] of the collector.
|
||||
The components included in the [distributions][] can be found by in the `manifest.yaml`
|
||||
of each distribution.
|
||||
The OpenTelemetry project currently offers [pre-built distributions][] of the
|
||||
collector. The components included in the [distributions][] can be found by in
|
||||
the `manifest.yaml` of each distribution.
|
||||
|
||||
[pre-built distributions]:
|
||||
https://github.com/open-telemetry/opentelemetry-collector-releases/releases
|
||||
|
|
|
|||
|
|
@ -10,8 +10,8 @@ systems and architectures. The following instructions show how to download and
|
|||
install the latest stable version of the Collector.
|
||||
|
||||
If you aren't familiar with the deployment models, components, and repositories
|
||||
applicable to the OpenTelemetry Collector, first review the [Data Collection][] and
|
||||
[Deployment Methods][] page.
|
||||
applicable to the OpenTelemetry Collector, first review the [Data Collection][]
|
||||
and [Deployment Methods][] page.
|
||||
|
||||
## Docker
|
||||
|
||||
|
|
@ -84,10 +84,10 @@ The previous example is meant to serve as a starting point, to be extended and
|
|||
customized before actual production usage. For production-ready customization
|
||||
and installation, see [OpenTelemetry Helm Charts][].
|
||||
|
||||
You can also use the [OpenTelemetry Operator][] to provision and maintain an OpenTelemetry
|
||||
Collector instance, with features such as automatic upgrade handling, `Service` configuration
|
||||
based on the OpenTelemetry configuration, automatic sidecar injection into deployments,
|
||||
and more.
|
||||
You can also use the [OpenTelemetry Operator][] to provision and maintain an
|
||||
OpenTelemetry Collector instance, with features such as automatic upgrade
|
||||
handling, `Service` configuration based on the OpenTelemetry configuration,
|
||||
automatic sidecar injection into deployments, and more.
|
||||
|
||||
For guidance on how to use the Collector with Kubernetes, see
|
||||
[Kubernetes Getting Started](/docs/kubernetes/getting-started/).
|
||||
|
|
|
|||
|
|
@ -5,8 +5,8 @@ aliases: [../instrumenting-library]
|
|||
weight: 40
|
||||
---
|
||||
|
||||
OpenTelemetry provides [instrumentation libraries][] for many libraries, which is
|
||||
typically done through library hooks or monkey-patching library code.
|
||||
OpenTelemetry provides [instrumentation libraries][] for many libraries, which
|
||||
is typically done through library hooks or monkey-patching library code.
|
||||
|
||||
Native library instrumentation with OpenTelemetry provides better observability
|
||||
and developer experience for users, removing the need for libraries to expose
|
||||
|
|
@ -245,8 +245,8 @@ already have OpenTelemetry integration. To find out, see the
|
|||
context on all logs, so users can correlate them.
|
||||
|
||||
If your language and ecosystem don't have common logging support, use [span
|
||||
events][] to share additional app details. Events maybe more convenient if you want
|
||||
to add attributes as well.
|
||||
events][] to share additional app details. Events maybe more convenient if you
|
||||
want to add attributes as well.
|
||||
|
||||
As a rule of thumb, use events or logs for verbose data instead of spans. Always
|
||||
attach events to the span instance that your instrumentation created. Avoid
|
||||
|
|
|
|||
|
|
@ -43,9 +43,9 @@ The pages in this section describe how to contribute to OpenTelemetry
|
|||
**documentation**.
|
||||
|
||||
For guidance on how to contribute to the OpenTelemetry project in general, see
|
||||
the community [OpenTelemetry New Contributor Guide]. Every [OTel repository][org]
|
||||
for language implementations, the Collector, and conventions have their own project-specific
|
||||
contributing guides.
|
||||
the community [OpenTelemetry New Contributor Guide]. Every [OTel
|
||||
repository][org] for language implementations, the Collector, and conventions
|
||||
have their own project-specific contributing guides.
|
||||
|
||||
[OpenTelemetry New Contributor Guide]:
|
||||
https://github.com/open-telemetry/community/blob/main/guides/contributor
|
||||
|
|
|
|||
|
|
@ -6,10 +6,10 @@ weight: 25
|
|||
cSpell:ignore: shortcodes
|
||||
---
|
||||
|
||||
The OTel website uses Hugo's [multilingual framework] to support page localizations.
|
||||
English is the default language, with US English as the default (implicit) localization.
|
||||
A growing number of other localizations are supported, as can be seen from the languages
|
||||
dropdown menu in the top nav.
|
||||
The OTel website uses Hugo's [multilingual framework] to support page
|
||||
localizations. English is the default language, with US English as the default
|
||||
(implicit) localization. A growing number of other localizations are supported,
|
||||
as can be seen from the languages dropdown menu in the top nav.
|
||||
|
||||
## English language maintainer guidance
|
||||
|
||||
|
|
|
|||
|
|
@ -384,9 +384,9 @@ close the terminal window.
|
|||
|
||||
### Site deploys and PR previews
|
||||
|
||||
If you submit a PR, Netlify creates a [deploy preview][] so that you can review your
|
||||
changes. Once your PR is merged, Netlify deploys the updated site to the production
|
||||
server.
|
||||
If you submit a PR, Netlify creates a [deploy preview][] so that you can review
|
||||
your changes. Once your PR is merged, Netlify deploys the updated site to the
|
||||
production server.
|
||||
|
||||
> **Note**: PR previews include _draft pages_, but production builds do not.
|
||||
|
||||
|
|
|
|||
|
|
@ -3,8 +3,8 @@ title: Forking the demo repository
|
|||
linkTitle: Forking
|
||||
---
|
||||
|
||||
The [demo repository][] is designed to be forked and used as a tool to show off what
|
||||
you are doing with OpenTelemetry.
|
||||
The [demo repository][] is designed to be forked and used as a tool to show off
|
||||
what you are doing with OpenTelemetry.
|
||||
|
||||
Setting up a fork or a demo usually only requires overriding some environment
|
||||
variables and possibly replacing some container images.
|
||||
|
|
|
|||
|
|
@ -267,10 +267,11 @@ end
|
|||
### Semantic Attributes
|
||||
|
||||
Semantic Attributes are attributes that are defined by the [OpenTelemetry
|
||||
Specification][] in order to provide a shared set of attribute keys across multiple
|
||||
languages, frameworks, and runtimes for common concepts like HTTP methods, status
|
||||
codes, user agents, and more. These attribute keys are generated from the specification
|
||||
and provided in [opentelemetry_semantic_conventions](https://hex.pm/packages/opentelemetry_semantic_conventions).
|
||||
Specification][] in order to provide a shared set of attribute keys across
|
||||
multiple languages, frameworks, and runtimes for common concepts like HTTP
|
||||
methods, status codes, user agents, and more. These attribute keys are generated
|
||||
from the specification and provided in
|
||||
[opentelemetry_semantic_conventions](https://hex.pm/packages/opentelemetry_semantic_conventions).
|
||||
|
||||
For example, an instrumentation for an HTTP client or server would need to
|
||||
include semantic attributes like the scheme of the URL:
|
||||
|
|
|
|||
|
|
@ -185,10 +185,10 @@ span.SetAttributes(myKey.String("a value"))
|
|||
#### Semantic Attributes
|
||||
|
||||
Semantic Attributes are attributes that are defined by the [OpenTelemetry
|
||||
Specification][] in order to provide a shared set of attribute keys across multiple
|
||||
languages, frameworks, and runtimes for common concepts like HTTP methods, status
|
||||
codes, user agents, and more. These attributes are available in the `go.opentelemetry.io/otel/semconv/v1.26.0`
|
||||
package.
|
||||
Specification][] in order to provide a shared set of attribute keys across
|
||||
multiple languages, frameworks, and runtimes for common concepts like HTTP
|
||||
methods, status codes, user agents, and more. These attributes are available in
|
||||
the `go.opentelemetry.io/otel/semconv/v1.26.0` package.
|
||||
|
||||
For details, see [Trace semantic conventions][].
|
||||
|
||||
|
|
|
|||
|
|
@ -22,9 +22,10 @@ Ensure that you have the following installed locally:
|
|||
|
||||
## Example Application
|
||||
|
||||
The following example uses a basic [Spring Boot] application. You can use another
|
||||
web framework, such as Apache Wicket or Play. For a complete list of libraries and
|
||||
supported frameworks, consult the [registry](/ecosystem/registry/?component=instrumentation&language=java).
|
||||
The following example uses a basic [Spring Boot] application. You can use
|
||||
another web framework, such as Apache Wicket or Play. For a complete list of
|
||||
libraries and supported frameworks, consult the
|
||||
[registry](/ecosystem/registry/?component=instrumentation&language=java).
|
||||
|
||||
For more elaborate examples, see [examples](../examples/).
|
||||
|
||||
|
|
@ -145,8 +146,8 @@ agent][] in a number of ways, the steps below use environment variables.
|
|||
to the JAR file.{{% /alert %}}
|
||||
|
||||
2. Set and export variables that specify the Java agent JAR and a [console
|
||||
exporter][], using a notation suitable for your shell/terminal environment —
|
||||
we illustrate a notation for bash-like shells:
|
||||
exporter][], using a notation suitable for your shell/terminal environment
|
||||
— we illustrate a notation for bash-like shells:
|
||||
|
||||
```sh
|
||||
export JAVA_TOOL_OPTIONS="-javaagent:PATH/TO/opentelemetry-javaagent.jar" \
|
||||
|
|
@ -248,7 +249,8 @@ For more:
|
|||
- Try [zero-code instrumentation](/docs/zero-code/java/agent/) on one of your
|
||||
own apps.
|
||||
- For light-weight customized telemetry, try [annotations][].
|
||||
- Learn about [manual instrumentation][] and try out more [examples](../examples/).
|
||||
- Learn about [manual instrumentation][] and try out more
|
||||
[examples](../examples/).
|
||||
- Take a look at the [OpenTelemetry Demo](/docs/demo/), which includes Java
|
||||
based [Ad Service](/docs/demo/services/ad/) and Kotlin based
|
||||
[Fraud Detection Service](/docs/demo/services/fraud-detection/)
|
||||
|
|
|
|||
|
|
@ -134,8 +134,8 @@ collector.
|
|||
#### Use OTLP exporter with HTTP/JSON or HTTP/protobuf
|
||||
|
||||
[OpenTelemetry Collector Exporter with gRPC][] works only with Node.js,
|
||||
therefore you are limited to use the [OpenTelemetry Collector Exporter
|
||||
with HTTP/JSON][] or [OpenTelemetry Collector Exporter with HTTP/protobuf][].
|
||||
therefore you are limited to use the [OpenTelemetry Collector Exporter with
|
||||
HTTP/JSON][] or [OpenTelemetry Collector Exporter with HTTP/protobuf][].
|
||||
|
||||
Make sure that the receiving end of your exporter (collector or observability
|
||||
backend) accepts `http/json` if you are using [OpenTelemetry Collector Exporter
|
||||
|
|
@ -161,8 +161,9 @@ If your website and collector are hosted at a different origin, your browser
|
|||
might block the requests going out to your collector. You need to configure
|
||||
special headers for Cross-Origin Resource Sharing (CORS).
|
||||
|
||||
The OpenTelemetry Collector provides [a feature][] for http-based receivers to add
|
||||
the required headers to allow the receiver to accept traces from a web browser:
|
||||
The OpenTelemetry Collector provides [a feature][] for http-based receivers to
|
||||
add the required headers to allow the receiver to accept traces from a web
|
||||
browser:
|
||||
|
||||
```yaml
|
||||
receivers:
|
||||
|
|
|
|||
|
|
@ -12,13 +12,13 @@ Node.js SDK.
|
|||
|
||||
## Setup
|
||||
|
||||
Follow the instructions in the [Getting Started - Node.js][], so that you have the
|
||||
files `package.json`, `app.js` and `tracing.js`.
|
||||
Follow the instructions in the [Getting Started - Node.js][], so that you have
|
||||
the files `package.json`, `app.js` and `tracing.js`.
|
||||
|
||||
## Process & Environment Resource Detection
|
||||
|
||||
Out of the box, the Node.js SDK detects [process and process
|
||||
runtime resources][] and takes attributes from the environment variable
|
||||
Out of the box, the Node.js SDK detects [process and process runtime
|
||||
resources][] and takes attributes from the environment variable
|
||||
`OTEL_RESOURCE_ATTRIBUTES`. You can verify what it detects by turning on
|
||||
diagnostic logging in `tracing.js`:
|
||||
|
||||
|
|
|
|||
|
|
@ -265,7 +265,8 @@ For more:
|
|||
|
||||
- Run this example with another [exporter][] for telemetry data.
|
||||
- Try [automatic instrumentation](/docs/zero-code/net/) on one of your own apps.
|
||||
- Learn about [manual instrumentation][] and try out more [examples](/docs/languages/net/examples/).
|
||||
- Learn about [manual instrumentation][] and try out more
|
||||
[examples](/docs/languages/net/examples/).
|
||||
- Take a look at the [OpenTelemetry Demo](/docs/demo/), which includes .NET
|
||||
based [Cart Service](/docs/demo/services/cart/).
|
||||
|
||||
|
|
|
|||
|
|
@ -8,8 +8,8 @@ cSpell:ignore: myhost pcarter uuidgen
|
|||
|
||||
## Setup
|
||||
|
||||
Follow the instructions in the [Getting Started][], so that you have a running .NET
|
||||
app exporting data to the console.
|
||||
Follow the instructions in the [Getting Started][], so that you have a running
|
||||
.NET app exporting data to the console.
|
||||
|
||||
## Adding resources with environment variables
|
||||
|
||||
|
|
|
|||
|
|
@ -489,7 +489,8 @@ For more:
|
|||
|
||||
- Run this example with another [exporter][] for telemetry data.
|
||||
- Try [zero-code instrumentation](/docs/zero-code/php/) on one of your own apps.
|
||||
- Learn more about [manual instrumentation][] and try out some [examples](/docs/languages/php/examples/).
|
||||
- Learn more about [manual instrumentation][] and try out some
|
||||
[examples](/docs/languages/php/examples/).
|
||||
- Take a look at the [OpenTelemetry Demo](/docs/demo/), which includes the PHP
|
||||
based [Quote Service](/docs/demo/services/quote/).
|
||||
|
||||
|
|
|
|||
|
|
@ -177,12 +177,12 @@ Adding tracing to a single service is a great first step. OpenTelemetry provides
|
|||
a few more features that will allow you gain even deeper insights!
|
||||
|
||||
- [Exporters][] allow you to export your data to a preferred backend.
|
||||
- [Context propagation][] is perhaps one of the most powerful concepts in OpenTelemetry
|
||||
because it will upgrade your single service trace into a _distributed trace_, which
|
||||
makes it possible for OpenTelemetry vendors to visualize a request from end-to-end
|
||||
across process and network boundaries.
|
||||
- [Span events][] allow you to add a human-readable message on a span that represents
|
||||
"something happening" during its lifetime.
|
||||
- [Context propagation][] is perhaps one of the most powerful concepts in
|
||||
OpenTelemetry because it will upgrade your single service trace into a
|
||||
_distributed trace_, which makes it possible for OpenTelemetry vendors to
|
||||
visualize a request from end-to-end across process and network boundaries.
|
||||
- [Span events][] allow you to add a human-readable message on a span that
|
||||
represents "something happening" during its lifetime.
|
||||
- [Instrumentation][instrumentation] will give provide you the ability to enrich
|
||||
your traces with domain specific data.
|
||||
- [The OpenTelemetry Demo](/docs/demo/) includes the Ruby based
|
||||
|
|
|
|||
|
|
@ -7,9 +7,9 @@ weight: 950
|
|||
## OpenTracing and OpenCensus
|
||||
|
||||
OpenTelemetry was created as a merger of OpenTracing and OpenCensus. From the
|
||||
start, OpenTelemetry was considered [to be the next major version of
|
||||
both OpenTracing and OpenCensus][]. Because of that, one of the [key goals][] of
|
||||
the OpenTelemetry project is to provide backward compatibility with both projects
|
||||
start, OpenTelemetry was considered [to be the next major version of both
|
||||
OpenTracing and OpenCensus][]. Because of that, one of the [key goals][] of the
|
||||
OpenTelemetry project is to provide backward compatibility with both projects
|
||||
and a migration story for existing users.
|
||||
|
||||
If you come from one of these projects, you can follow the migration guides for
|
||||
|
|
|
|||
|
|
@ -3,8 +3,8 @@ title: Zero-code Instrumentation
|
|||
weight: 260
|
||||
---
|
||||
|
||||
OpenTelemetry [zero-code instrumentation][] is supported for the languages listed
|
||||
below in the section index.
|
||||
OpenTelemetry [zero-code instrumentation][] is supported for the languages
|
||||
listed below in the section index.
|
||||
|
||||
If you are using Kubernetes, you can use the [OpenTelemetry Operator for
|
||||
Kubernetes][otel-op] to [inject zero-code instrumentation] for .NET, Java,
|
||||
|
|
|
|||
|
|
@ -107,8 +107,8 @@ dotnet run
|
|||
## Instrumentation
|
||||
|
||||
Next, you'll use a [OpenTelemetry .NET Automatic Instrumentation](../) to
|
||||
instrument the application at launch time. While you can [configure
|
||||
.NET Automatic Instrumentation][] in a number of ways, the steps below use Unix-shell
|
||||
instrument the application at launch time. While you can [configure .NET
|
||||
Automatic Instrumentation][] in a number of ways, the steps below use Unix-shell
|
||||
or PowerShell scripts.
|
||||
|
||||
> **Note**: PowerShell commands require elevated (administrator) privileges.
|
||||
|
|
@ -150,10 +150,10 @@ or PowerShell scripts.
|
|||
|
||||
{{% /tab %}} {{< /tabpane >}}
|
||||
|
||||
3. Set and export variables that specify a [console exporter][], then execute script
|
||||
configuring other necessary environment variables using a notation suitable for
|
||||
your shell/terminal environment — we illustrate a notation for bash-like
|
||||
shells and PowerShell:
|
||||
3. Set and export variables that specify a [console exporter][], then execute
|
||||
script configuring other necessary environment variables using a notation
|
||||
suitable for your shell/terminal environment — we illustrate a notation
|
||||
for bash-like shells and PowerShell:
|
||||
|
||||
{{< tabpane text=true >}} {{% tab Unix-shell %}}
|
||||
|
||||
|
|
|
|||
|
|
@ -7,13 +7,13 @@ description: How to add entries to the registry.
|
|||
Do you maintain or contribute to an integration for OpenTelemetry? We'd love to
|
||||
feature your project in the [registry](../)!
|
||||
|
||||
To add your project, submit a [pull request][]. You'll need to create a data file
|
||||
in [data/registry][] for your project, by using the following template: [registry-entry.yml][].
|
||||
To add your project, submit a [pull request][]. You'll need to create a data
|
||||
file in [data/registry][] for your project, by using the following template:
|
||||
[registry-entry.yml][].
|
||||
|
||||
Make sure that your project names and descriptions follow our [marketing
|
||||
guidelines][] and are in line with the Linux Foundation’s branding and [trademark
|
||||
usage
|
||||
guidelines][].
|
||||
guidelines][] and are in line with the Linux Foundation’s branding and
|
||||
[trademark usage guidelines][].
|
||||
|
||||
[data/registry]:
|
||||
https://github.com/open-telemetry/opentelemetry.io/tree/main/data/registry
|
||||
|
|
|
|||
|
|
@ -85,8 +85,8 @@ líneas de código.
|
|||
|
||||
{{% blocks/section color="secondary" type="cncf" %}}
|
||||
|
||||
**OpenTelemetry es un proyecto [CNCF][] [en incubación][]**.<br> Se formó a partir
|
||||
de la fusión de los proyectos OpenTracing y OpenCensus.
|
||||
**OpenTelemetry es un proyecto [CNCF][] [en incubación][]**.<br> Se formó a
|
||||
partir de la fusión de los proyectos OpenTracing y OpenCensus.
|
||||
|
||||
[![CNCF logo][]][cncf]
|
||||
|
||||
|
|
|
|||
|
|
@ -388,9 +388,9 @@ Para detener la instancia local de Hugo, vuelve a la terminal y escriba
|
|||
|
||||
### Implementaciones del sitio y vistas previas de PR
|
||||
|
||||
Si envías una PR, Netlify crea una [Vista Previa de Implementación][] para que puedas
|
||||
revisar sus cambios. Una vez que se fusiona su PR, Netlify implementa el sitio actualizado
|
||||
en el servidor de producción.
|
||||
Si envías una PR, Netlify crea una [Vista Previa de Implementación][] para que
|
||||
puedas revisar sus cambios. Una vez que se fusiona su PR, Netlify implementa el
|
||||
sitio actualizado en el servidor de producción.
|
||||
|
||||
> **Nota**: Las vistas previas de PR incluyen _páginas de borrador_, pero las
|
||||
> compilaciones de producción no.
|
||||
|
|
|
|||
|
|
@ -29,10 +29,9 @@ el siguiente:
|
|||
{{% alert title="Importante" color="warning" %}}
|
||||
|
||||
Independientemente del estado de un API/SDK, si tu instrumentación depende de
|
||||
[convenciones semánticas] que estén marcadas como [Experimental] en la [especificación
|
||||
de
|
||||
convenciones semánticas], tu flujo de datos podría estar sujeto a **cambios
|
||||
importantes**.
|
||||
[convenciones semánticas] que estén marcadas como [Experimental] en la
|
||||
[especificación de convenciones semánticas], tu flujo de datos podría estar
|
||||
sujeto a **cambios importantes**.
|
||||
|
||||
[convenciones semánticas]: /docs/concepts/semantic-conventions/
|
||||
[Experimental]: /docs/specs/otel/document-status/
|
||||
|
|
|
|||
|
|
@ -246,7 +246,7 @@ Para mais detalhes sobre registros de log e campos de log, consulte
|
|||
|
||||
### Especificação {#specification}
|
||||
|
||||
Para saber mais sobre logs no OpenTelemetry, consulte a [especificação
|
||||
de logs][].
|
||||
Para saber mais sobre logs no OpenTelemetry, consulte a [especificação de
|
||||
logs][].
|
||||
|
||||
[especificação de logs]: /docs/specs/otel/overview/#log-signal
|
||||
|
|
|
|||
|
|
@ -30,8 +30,7 @@ seguir:
|
|||
|
||||
Independente do estado de um API/SDK, se a sua instrumentação depende de
|
||||
[convenções semânticas] que são marcadas como [Experimental] na [especificação
|
||||
de
|
||||
convenções semânticas], seu fluxo de dados pode estar sujeito à **quebra de
|
||||
de convenções semânticas], seu fluxo de dados pode estar sujeito à **quebra de
|
||||
compatibilidade**
|
||||
|
||||
[convenções semânticas]: /docs/concepts/semantic-conventions/
|
||||
|
|
|
|||
|
|
@ -51,8 +51,8 @@ them up.
|
|||
|
||||
<div class="alert alert-info" role="alert"><h4 class="alert-heading">Note</h4>
|
||||
|
||||
If you use [zero-code instrumentation](/docs/zero-code/{{ $l }}), you can learn how
|
||||
to set up exporters by following the [Configuration
|
||||
If you use [zero-code instrumentation](/docs/zero-code/{{ $l }}), you can learn
|
||||
how to set up exporters by following the [Configuration
|
||||
Guide](/docs/zero-code/{{ $l }}/configuration/).
|
||||
|
||||
</div>
|
||||
|
|
|
|||
|
|
@ -3,7 +3,8 @@
|
|||
## Custom exporters
|
||||
|
||||
Finally, you can also write your own exporter. For more information, see the
|
||||
[SpanExporter Interface in the API documentation]({{ $spanExporterInterfaceUrl }}).
|
||||
[SpanExporter Interface in the API
|
||||
documentation]({{ $spanExporterInterfaceUrl }}).
|
||||
|
||||
## Batching span and log records
|
||||
|
||||
|
|
|
|||
|
|
@ -123,7 +123,7 @@
|
|||
"markdown-link-check": "^3.13.6",
|
||||
"markdownlint": "^0.36.1",
|
||||
"postcss-cli": "^11.0.0",
|
||||
"prettier": "^3.3.3",
|
||||
"prettier": "^3.4.0",
|
||||
"require-dir": "^1.2.0",
|
||||
"textlint": "^14.3.0",
|
||||
"textlint-filter-rule-allowlist": "^4.0.0",
|
||||
|
|
|
|||
Loading…
Reference in New Issue