OpenTelemetry

Is your feature request related to a problem?

The first step towards app optimization

Please describe.
Configure whyDidYouRender under the development env

**Note: make sure it is compatible with all the custom hooks that we are using in the project **

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

Instrument name has to be validated as per the spec. The .NET API itself does not validate this, so the SDK has to validate the instrument name (upon instrument creation), and ignore the instrument (after logging that we are ignoring an instrument due to ... reason).

For Views, whi

#3615 improves reload behavior by failing with an error rather than hanging, if the config is invalid. This issue tracks creating an automated test to verify this going forward.

(Guessing there's an actual way to make this a test, maintainers will know better ;) )

_Originally posted by @carlosalberto in open-telemetry/opentelemetry-collector#3615 (comment)

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 generate Github Action checks if any code generation scripts were missed by the contributor and need to be run before the PR can be merged. It should also ensure that website_docs are up to date and the contributor ran ./scripts/generate_website_docs.sh if they made changes to the source material

The TracerProvider::force_flush method is part of the sdk spec but not the api spec.

Auto-generated report for loadtest-with-github-reports job build.

Link to failed build: https://circleci.com/gh/open-telemetry/opentelemetry-collector-contrib/165110

Test Failures

• TestBallastMemory

Note: Information about any subsequent build failures that happen while
this issue is open, will be added as comments with more information to this issue.

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.

We'd like to add some documentation to the opentelemetry.io website.

the website_docs folder pushes all of its contents to https://opentelemetry.io/docs/php/

We should include our documentation in there in order to make it easier for end users to adopt our library.

Our Rack instrumentation allows configuration of a URL quantization function https://github.com/open-telemetry/opentelemetry-ruby/blob/1c37b00dc82d490dace1f92739977aa4674d7039/instrumentation/rack/lib/opentelemetry/instrumentation/rack/middlewares/tracer_middleware.rb#L122-L137

We should add the same functionality to the Sinatra instrumentation. @genebean reported this requirement in Gitter:

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.

As part of #868 and #872 , currently we are embedding semantic convention attributes manually into C++ code. This can be automated.
This ticket is to check the feasibility of automatic generation of C++ code from semantic convention YAML data model using Jinja template engine.

Reference:
YAML data model for semantic conventions: https://github.com/open-telemetry/opentelemetry-specification

The current Getting Started guide includes a demo that use Zipkin, Jaeger and Prometheus. I am looking for a more simpler guide. Something that would show how to send a metric(s) using a utility like CURL and seeing the metric being recorded in a local file. This would help confirm that the installation of OTEL Collector is working normally.

Currently we can access logs, traces and metrics locally. Could you explain how to integrate it with Grafana cloud?

typeorm tests are creating a new db connection in each test. If something goes wrong (assertion fails, exception thrown), the test does not close this connection which causes the following tests to fail as well.
We need to move the logic into afterEach hook so tests clean the environment after they are done for whatever reason.