OpenTelemetry
OpenTelemetry provides a single set of APIs, libraries, agents, and collector services to capture distributed traces and metrics from your application. You can analyze them using Prometheus, Jaeger, and other observability tools.
Here are 361 public repositories matching this topic...
-
Updated
Jul 6, 2022 - Go
The current externalCall page has 4 charts which needs to move from promQl to query-builder APIs. Below are the charts in that page
- External Call Error Percentage
- External Call duration
- External Call RPS(by Address)
- External Call duration(by Address)
-
Updated
Jun 20, 2022 - Java
-
Updated
Mar 22, 2022 - TypeScript
I think I've had about a 10% success rate with markdownlint since it seems to get throttled by GitHub. I've heard this was an issue that should have improved, but it doesn't seem to have been and I can't find any context for that in this repo.
Perhaps switching markdownlint to a GitHub Action would work around the throttling "for free" (actions automatically have GitHub creds for the repo). Jus
It would be useful to have an option in the builder to pass Go build tags, so that we can test the functionality currently behind the enable_unstable build tag. We could either have an option to pass the build tags or have an option to pass arbitrary flags to the go command.
This would also help in open-telemetry/opentelemetry-collector-contrib/issues/11867 if we want to keep the `make otel
open-telemetry/opentelemetry-dotnet#3112 As a follow up to this, we can now modify the instrumentation libraries to leverage the new Status field on Activity.
In the doc page https://opentelemetry.io/docs/java/manual_instrumentation/, it would be nice if a layer could be added, using the latests dependencies, bom and inner project dependencies(api, sdk, and opentelemetry-exporters-otlp) to use the provided code.
It would be nice if the sample could provide the gradle/maven, etc. dependencies as a block to copy/paste int the https://opentelemetry.io/
The recently added flags in timescale/promscale#578 are yet to be updated in prom-migrator's readme which can be found here.
-
Updated
May 31, 2022 - Java
Kibana version: 8.2 Snapshot Kibana cloud environment
Host OS and Browser version: All, All
Build details:
VERSION: 8.2.0
BUILD: 51328
COMMIT: 2a93e80574f9c1052c541bc4083a440a623899e8
Preconditions:
- 8.2 Snapshot Kibana cloud environment should be available.
Steps to reproduce:
- Login to Kibana environment.
- Install Elastic APM integration and
Could you create an issue to change tracing to use Resource.to_json(), in a way that's not breaking?
Originally posted by @lzchen in open-telemetry/opentelemetry-python#2722 (comment)
We currently rely on a custom main.go file to make Collector builds on CI and locally (if someone e.g. runs make otelcontribcol).
For consistency with the core repository we could keep a manifest and use the [OpenTelemetry Collector Builder](https://github.com/open-telemetry/opentelemetr
-
Updated
Jul 6, 2022 - Vue
See the spec change for details open-telemetry/opentelemetry-specification#1269
每Pipeline不能多个Sink的问题
每Pipeline实现多Sink存在的问题在于:
1 多Sink时,如何解决单个Sink写下游失败时的重试的问题?
2 多Sink时,如何解决不同Sink的不同拦截器配置的问题?业务侧可能会想要不同Sink下游的数据中有不同的Intercepter配置呢?
从代码看已经实现了 sink.Interceptor可以与Sink关联 这个特性。
是否借助这个特性其实就可以解决以上两个问题了?
问题1 的解法
retry interceptor 与特定的Sink关联,这样就可以在不同的Sink间做独立的重试。
此时比如2个Sink其中有一个的下游阻塞了,则重试行为是同一个pipeline的不同sink应该都阻塞。
Roadmap计划是做成这个效果吗?
问题2的解法
为不同的Sink指定不同的拦截器,这样就可以解决不同数据下游需要不同处理
-
Updated
Jul 6, 2022 - Go
The current release process includes submitting pull requests to update the operator on the Operator Hub. However, this is not really required to release the operator proper. We still want this documented there, though. This ticket is about moving that item from the release process into its own section.
The ResourceConstants class has been deprecated since the introduction of semantic conventions in release 0.0.4. It should be removed now, since it's not used anywhere in the library or the contrib repository's components
Use Case
- Provide a sample application to test DBs, messaging systems and HTTP, GRPC backend resolution and call view.
Proposal
- A simple app where backend can be swapped or we can use multiple backends.
Open this issue since I don’t think #1463 Is well resolved, as we don’t find a good example how to instrument function call with async callback, in most condition, I/O operation will be made in an asynchrous fashion, but it doesn’t seem to be well supported by the cpp lib.
Currently (as of 0.7.0) NEOS tutorial that is opening up next to Cloud Shell window has 9 pages. 6 of them look similar but shorter versions of what's available in the user guide.
We want to shorten the NEOS tutorial and move details into the user guide. (Hugo static website under /website folder)
-
Updated
Jul 6, 2022 - Python
-
Updated
Jun 27, 2022
-
Updated
Jul 6, 2022 - Go
-
Updated
Jul 5, 2022 - Makefile
I was re-learning Rust last evening with aims to figure out how to write a decent Getting Started article. But I realized pretty quickly that there's some decision points to make about such an article, and I'm not equipped to make those decisions:
- What's the best web server framework to center the guide around? E.g., what's "Flask but for Rust"?
- As far as I can tell there's no automatic in
- Organization
- open-telemetry
- Website
- opentelemetry.io
Requirement - what kind of business use case are you trying to solve?
Actual the windows executables (jaeger-agent.exe, jaeger-collector.exe, ...) don't have a version set. It is hard to identify the current used version and check if the actual used version is outdated.
Probl