As noted in #36073, having support for the different protocols for
exporting OpenTelemetry data would be useful, especially if this is
leading to users seeing issues when they have auto-injected
configuration being set.
Co-authored-by: Claude Sonnet 5 <jamie.tanna+claude-code@mend.io>
* feat(instrumentation): allow exporting OTLP JSON file
We've recently been investing in improvements to Renovate's
OpenTelemetry instrumentation to improve debuggability and
supportability.
However, not everyone has an immediately available OpenTelemetry
Collector, so the added instrumentation isn't useful to those users.
Instead, we can provide a way to export to the OTLP file format, which
provides a means to export the data to disk and then consume it later.
This will also support use-cases like running in a CI platform like
GitHub Actions and GitLab CI, where OpenTelemetry Collectors may not be
exposed in that environment, but a post-run execution can export it.
We now need to make sure that `RENOVATE_USE_CLOUD_METADATA_SERVICES` is
never set, as `isTracingEnabled` will now resolve true, and the Cloud
Metadata Resource Detectors will be used.
Co-authored-by: Claude Sonnet 4.6 <jamie.tanna+claude-code@mend.io>
Co-authored-by: Claude Sonnet 5 <jamie.tanna+claude-code@mend.io>
* fixup! feat(instrumentation): allow exporting OTLP JSON file
* fixup! fixup! feat(instrumentation): allow exporting OTLP JSON file
Co-authored-by: Claude Sonnet 5 <jamie.tanna+claude-code@mend.io>
* fixup! feat(instrumentation): allow exporting OTLP JSON file
---------
Co-authored-by: Claude Sonnet 4.6 <jamie.tanna+claude-code@mend.io>
* feat: timing statistics for getReleases
Adds collection and reporting of timing statistics for
`datasource.getReleases()` calls. Each call records the datasource, registryUrl,
packageName, and duration. The intent is to visibility into where
renovate is retrieving release information and how long that might take.
The report consists of a nested data-structure that provides increasing
detail as we descend datasource, registryUrl, and packageName.
The full report is logged at trace level
`getReleases statistics with packages`.
A summary report including only datasources and registryUrls is logged
at debug level `getReleases statistics summary`.
* add GetReleasesSpanProcessor
- Re-instrument getReleases calls using open telemetry.
- Adds GetReleasesSpanProcessor, which can adapt
`getReleases` spans to GetReleasesStats.
* fixup instrumentation tests
* pr feedback
* pr feedback: naming
* pr feedback: comments
* fix(instrumentation): always process Git Operation spans
As part of b5cd0317cf we added the ability
to report the `Git Operations Statistics` at the end of the Renovate
run, by introducing a `SpanProcessor`.
However, this didn't correctly take into account the fact that this
would only be enabled if Renovate was configured to log/export traces,
which is not the case in most deployments.
As noted in #42118, this leads to a blank log line output, which isn't
very useful.
To correct this, we nede to always process these spans, even if tracing
is not enabled.
Co-authored-by: Claude Sonnet 4.6 <jamie.tanna+claude-code@mend.io>
* fixup! fix(instrumentation): always process Git Operation spans
* fixup! fixup! fix(instrumentation): always process Git Operation spans
* fixup! fixup! fix(instrumentation): always process Git Operation spans
---------
Co-authored-by: Claude Sonnet 4.6 <jamie.tanna+claude-code@mend.io>
As noted by Michael, this was likely fixed as part of other changes he'd
made recently around logging.
Co-authored-by: Michael Kriese <1798109+viceice@users.noreply.github.com>
Now we have instrumented our Git operations with tracing, we can make
sure that users who are not using OpenTelemetry still get insights into
their Git operation usage using a debug log output.
Following how other insights are produced, we can introduce a new type
in `lib/util/stats` for `GitOperationStats`, which will track the
overall execution for each operation type, and output them in the same
style as we use for other timing reports.
At the end of a Renovate run, we'll then make sure that this is logged
into a debug log for further investigation.
To create the report, we can make sure that we introduce a new
OpenTelemetry `SpanProcessor`, which will run when we end our Run, and
store any Git operations in `GitOperationStats`.
This adapts code from GPT-4.1 and code from [0].
Co-authored-by: gpt-4.1 <jamie.tanna+github-copilot@mend.io>
[0]: https://github.com/yurisouza/monitoria-sdk/blob/ca9d751fa7c3a785a04f87b8966bb782b4617021/src/adapters/nestjs/span-duration-tracker.ts#L18-L27
When instrumenting, we specifically handle Promises. However, if we have
an object, like SimpleGit's `Response`:
```
export type Response<T> = SimpleGit & Promise<T>;
```
This does not get correctly instrumented, and we end up not waiting for
the function call to complete.
We can make sure we use `isPromise` to correctly check if it's a native
Promise, or something with a Promise-like API.
As part of a step towards better OpenTelemetry instrumentation as part
of #38609, we can start by introducing a known span attribute for the
repository "split" we're currently processing.
This requires a slight refactor of the `SpanOptions`, to use our custom
type, which enforces the `RenovateSplit` type when using the span name.
This adds it into each of the splits we currently instrument.
Co-authored-by: secustor <sebastian@poxhofer.at>
Without this, we cannot call `instrument` with the 4 parameters,
otherwise we receive a Typescript error.
Co-authored-by: gpt-4.1 <jamie.tanna+github-copilot@mend.io>
Jamie Tanna