Skip to content

pass meter provider to avoid using the global otel instance #7475

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 5 commits into
base: main
Choose a base branch
from
+34 −9
Open

pass meter provider to avoid using the global otel instance #7475

Show file tree
Hide file tree
Changes from 4 commits
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
2272652
pass meter provider to avoid using the global otel instance
zeitlinger Jul 8, 2025
7e389f5
format
zeitlinger Jul 9, 2025
b08f400
fix
zeitlinger Jul 9, 2025
750f710
fix
zeitlinger Jul 9, 2025
6506694
field order
zeitlinger Jul 14, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
12 changes: 12 additions & 0 deletions ...in/java/io/opentelemetry/sdk/extension/incubator/fileconfig/DeclarativeConfigContext.java
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -7,6 +7,7 @@

import io.opentelemetry.api.incubator.config.DeclarativeConfigException;
import io.opentelemetry.api.incubator.config.DeclarativeConfigProperties;
import io.opentelemetry.api.metrics.MeterProvider;
import io.opentelemetry.sdk.autoconfigure.internal.SpiHelper;
import io.opentelemetry.sdk.autoconfigure.spi.internal.ComponentProvider;
import java.io.Closeable;
Expand All @@ -15,11 +16,13 @@
import java.util.List;
import java.util.function.Function;
import java.util.stream.Collectors;
import javax.annotation.Nullable;

/** Declarative configuration context and state carrier. */
class DeclarativeConfigContext {

private final SpiHelper spiHelper;
@Nullable private MeterProvider meterProvider;
private final List<Closeable> closeables = new ArrayList<>();

DeclarativeConfigContext(SpiHelper spiHelper) {
Expand All @@ -39,6 +42,15 @@ List<Closeable> getCloseables() {
return Collections.unmodifiableList(closeables);
}

@Nullable
public MeterProvider getMeterProvider() {
return meterProvider;
}

public void setMeterProvider(MeterProvider meterProvider) {
this.meterProvider = meterProvider;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

any chance this needs to be cross-thread safe? In which case, putting a memory barrier around the assignment would be necessary.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

no, this doesn't need to be thread safe - it belongs to the set up logic that is done in a single thread at the start

}

/**
* Find a registered {@link ComponentProvider} with {@link ComponentProvider#getType()} matching
* {@code type}, {@link ComponentProvider#getName()} matching {@code name}, and call {@link
Expand Down
5 changes: 5 additions & 0 deletions ...n/java/io/opentelemetry/sdk/extension/incubator/fileconfig/LogRecordProcessorFactory.java
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -5,6 +5,7 @@

package io.opentelemetry.sdk.extension.incubator.fileconfig;

import io.opentelemetry.api.metrics.MeterProvider;
import io.opentelemetry.sdk.extension.incubator.fileconfig.internal.model.BatchLogRecordProcessorModel;
import io.opentelemetry.sdk.extension.incubator.fileconfig.internal.model.LogRecordExporterModel;
import io.opentelemetry.sdk.extension.incubator.fileconfig.internal.model.LogRecordProcessorModel;
Expand Down Expand Up @@ -52,6 +53,10 @@ public LogRecordProcessor create(
if (batchModel.getScheduleDelay() != null) {
builder.setScheduleDelay(Duration.ofMillis(batchModel.getScheduleDelay()));
}
MeterProvider meterProvider = context.getMeterProvider();
if (meterProvider != null) {
builder.setMeterProvider(meterProvider);
}

return context.addCloseable(builder.build());
}
Expand Down
20 changes: 11 additions & 9 deletions ...o/opentelemetry/sdk/extension/incubator/fileconfig/OpenTelemetryConfigurationFactory.java
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -9,6 +9,7 @@
import io.opentelemetry.sdk.OpenTelemetrySdk;
import io.opentelemetry.sdk.OpenTelemetrySdkBuilder;
import io.opentelemetry.sdk.extension.incubator.fileconfig.internal.model.OpenTelemetryConfigurationModel;
import io.opentelemetry.sdk.metrics.SdkMeterProvider;
import io.opentelemetry.sdk.resources.Resource;
import java.util.Objects;
import java.util.regex.Pattern;
Expand Down Expand Up @@ -53,6 +54,16 @@ public OpenTelemetrySdk create(
resource = ResourceFactory.getInstance().create(model.getResource(), context);
}

if (model.getMeterProvider() != null) {
SdkMeterProvider meterProvider =
MeterProviderFactory.getInstance()
.create(model.getMeterProvider(), context)
.setResource(resource)
.build();
context.setMeterProvider(meterProvider);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe it would be less error prone if context.setMeterProvider call addCloseable internally.
Then builder.setMeterProvider(context.addCloseable(meterProvider)); could be just: builder.setMeterProvider(meterProvider); and we would be guaranteed that meterProvider will always be closed.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it would work if we change the parameter type to SdkMeterProvider - but it would be harder to understand why the closeable logic is hidden here, but not for tracer and logger

builder.setMeterProvider(context.addCloseable(meterProvider));
}

if (model.getLoggerProvider() != null) {
builder.setLoggerProvider(
context.addCloseable(
Expand All @@ -77,15 +88,6 @@ public OpenTelemetrySdk create(
.build()));
}

if (model.getMeterProvider() != null) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Was there any reason to move this code block upper? If not then it leaving it in the same place would make changes analysis a bit simpler.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes, the meter provider is taken out of the context for logger and tracer

builder.setMeterProvider(
context.addCloseable(
MeterProviderFactory.getInstance()
.create(model.getMeterProvider(), context)
.setResource(resource)
.build()));
}

return context.addCloseable(builder.build());
}
}
6 changes: 6 additions & 0 deletions ...c/main/java/io/opentelemetry/sdk/extension/incubator/fileconfig/SpanProcessorFactory.java
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -5,6 +5,7 @@

package io.opentelemetry.sdk.extension.incubator.fileconfig;

import io.opentelemetry.api.metrics.MeterProvider;
import io.opentelemetry.sdk.extension.incubator.fileconfig.internal.model.BatchSpanProcessorModel;
import io.opentelemetry.sdk.extension.incubator.fileconfig.internal.model.SimpleSpanProcessorModel;
import io.opentelemetry.sdk.extension.incubator.fileconfig.internal.model.SpanExporterModel;
Expand Down Expand Up @@ -47,6 +48,11 @@ public SpanProcessor create(SpanProcessorModel model, DeclarativeConfigContext c
if (batchModel.getScheduleDelay() != null) {
builder.setScheduleDelay(Duration.ofMillis(batchModel.getScheduleDelay()));
}
MeterProvider meterProvider = context.getMeterProvider();
if (meterProvider != null) {
builder.setMeterProvider(meterProvider);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This partially solves the problem, but we still won't get the internal exporter telemetry.

The way we solve this in autoconfigure today is with the AutoConfigureListener. SDK components which are loaded via SPI and which report internal telemetry implement AutoConfigureListener and get a callback to update MeterProvider after OpenTelemetrySdk has been initialized. For example, see OtlpSpanExporterProvider.

I think what you've done here does work for SDK components which report internal telemetry and which are NOT loaded via SPI.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That SPI would implement create and can just take the meter provider from DeclarativeConfigContext IIUC.

opentelemetry-java/sdk-extensions/incubator/src/main/java/io/opentelemetry/sdk/extension/incubator/fileconfig/Factory.java

Line 17 in eec2120

ResultT create(ModelT model, DeclarativeConfigContext context);

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is the SPI guaranteed to be run on the same thread that set the value onto the context? If not, then we will need a memory barrier on the setting of the value into the context, I think.

}

return context.addCloseable(builder.build());
}

Expand Down
Loading