Skip to content

Update docs for entrypoints #4701

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.

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 2 commits into
base: main
Choose a base branch
from
Open
Show file tree
Hide file tree
Changes from 1 commit
Commits
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
77 changes: 77 additions & 0 deletions docs/sdk/entry_points.rst
Original file line number Diff line number Diff line change
@@ -0,0 +1,77 @@
Entry Points
============

OpenTelemetry Python uses Python's **entry points** mechanism to provide a pluggable architecture. Entry points allow you to register custom components (exporters, samplers, etc.) that can be discovered and loaded at runtime.
Copy link
Contributor

Choose a reason for hiding this comment

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

Can we link to the official entry point documentation here

Copy link
Author

Choose a reason for hiding this comment

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

done!


Configuration
-------------

Entry points are controlled via environment variables:
Copy link
Contributor

Choose a reason for hiding this comment

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

Maybe -- the name (I think that is the official term from the entry points doc) of the entry point is set to environment variables

Copy link
Contributor

@xrmx xrmx Jul 28, 2025

Choose a reason for hiding this comment

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

I'm not sure I agree with the PR here, e.g. for -contrib this is not true. Entry points is what we use for providing extensibility without coupling the code (i.e. a plugin system) from different python packages and in practice they are a system we use to load code from a configuration. Then you can add that some options leverage entry points, as Dylan wrote, requiring to specify the entry point name in order to load some specific code.

Copy link
Author

Choose a reason for hiding this comment

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

thanks! i've updated this - please lmk if this looks better

Copy link
Contributor

Choose a reason for hiding this comment

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

Can we link to something that lists all the environment variables

Copy link
Contributor

Choose a reason for hiding this comment

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

Yes I think we could link the API environment variables doc (sourced here and here) instead of duplicating here in the SDK docs.

Copy link
Author

Choose a reason for hiding this comment

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

done!


* ``OTEL_TRACES_EXPORTER`` - Trace exporters (e.g., ``console``, ``otlp_proto_grpc``)
Copy link
Contributor

Choose a reason for hiding this comment

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

Maybe we should have a 3 column table -- environment variables, entry point name, available options provided by otel python SDK/exporter package ?

Copy link
Author

Choose a reason for hiding this comment

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

done and added a 4th column to link to the base class as mentioned in one of the other comments!

Copy link
Member

Choose a reason for hiding this comment

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

Looks like there's not enough room for all four columns without hidden overflow. Another possibility would be to convert each row into its own block.

* ``OTEL_METRICS_EXPORTER`` - Metrics exporters (e.g., ``console``, ``prometheus``)
* ``OTEL_LOGS_EXPORTER`` - Log exporters (e.g., ``console``, ``otlp_proto_http``)
* ``OTEL_TRACES_SAMPLER`` - Trace samplers (e.g., ``always_on``, ``traceidratio``)
* ``OTEL_PROPAGATORS`` - Context propagators (e.g., ``tracecontext,baggage``)

Available Entry Point Groups
----------------------------

**Exporters** - Send telemetry data to backends:

* ``opentelemetry_traces_exporter`` - Trace exporters
Copy link
Contributor

Choose a reason for hiding this comment

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

I think when the code loads it in it checks the type, it'd be good if we could link to the actual type here. Maybe the actual definition in the .py file is best?

Copy link
Contributor

Choose a reason for hiding this comment

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

Agree

* ``opentelemetry_metrics_exporter`` - Metrics exporters
* ``opentelemetry_logs_exporter`` - Log exporters

**Configuration** - Control telemetry behavior:

* ``opentelemetry_traces_sampler`` - Decide which traces to collect
* ``opentelemetry_id_generator`` - Generate trace/span IDs
* ``opentelemetry_resource_detector`` - Detect environment info
Copy link
Contributor

Choose a reason for hiding this comment

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

Again if possible can we link to the expected type? I appreciate the very brief explanation of what the thing is tho..


**Context** - Manage distributed tracing context:

* ``opentelemetry_propagator`` - Cross-service context propagation
* ``opentelemetry_context`` - Context storage mechanism

**Providers** - Core telemetry factories:

* ``opentelemetry_tracer_provider`` - Create tracers
* ``opentelemetry_meter_provider`` - Create meters
* ``opentelemetry_logger_provider`` - Create loggers

Creating a Custom Exporter
Copy link
Contributor

Choose a reason for hiding this comment

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

I think this section is useful. It would be good to put this information somewhere without duplicating what the API and SDK docs already describe (e.g. the env vars mentioned above). Alternative locations could be as a new example or as a special exporters topic. Or maybe in the otel.io docs.

---------------------------

1. **Create your exporter class**:

.. code-block:: python

from opentelemetry.sdk.trace.export import SpanExporter

class MyExporter(SpanExporter):
def export(self, spans):
# Your export logic here
for span in spans:
print(f"Exporting: {span.name}")

2. **Register in pyproject.toml**:

.. code-block:: toml

[project.entry-points.opentelemetry_traces_exporter]
my_exporter = "mypackage.exporters:MyExporter"

3. **Use it**:

.. code-block:: bash

export OTEL_TRACES_EXPORTER=my_exporter
python your_app.py

See Also
--------

* :doc:`trace` - Trace SDK documentation
* :doc:`metrics` - Metrics SDK documentation
* :doc:`environment_variables` - Environment variable reference
1 change: 1 addition & 0 deletions docs/sdk/index.rst
Original file line number Diff line number Diff line change
Expand Up @@ -12,3 +12,4 @@ OpenTelemetry Python SDK
metrics
error_handler
environment_variables
entry_points