Muscles OpenTelemetry
Observability hooks and a neutral telemetry provider for Muscles lifecycle instrumentation.
This package traces real framework lifecycle points: strategy execution, server
dispatch, action dispatch, validation, rules/security and handler execution. The
current implementation ships an in-memory MusclesTracer that implements the
core TelemetryProvider interface. It does not configure an OpenTelemetry SDK,
OTLP exporter, collector or vendor backend by itself.
What This Package Is For
Use muscles-otel when a Muscles application or framework package needs a
single tracing surface without importing an observability vendor directly:
- applications install
OtelPackageonce during bootstrap; - other packages call
resolve_telemetry(app)frommuscles; - spans are recorded only when tracing is enabled;
- sensitive attributes are redacted before they reach span records.
This keeps instrumentation optional. If muscles-otel is not installed, core
falls back to NoopTelemetry, so package code can keep the same tracing calls.
What It Is Not Yet
muscles-otel is not yet a full OpenTelemetry distribution. It currently does
not export traces to Jaeger, Tempo, Honeycomb, Datadog or an OTLP collector. A
production exporter can be added behind the same TelemetryProvider surface
without changing packages that already use resolve_telemetry(app).
Related Repositories
muscles- core lifecycle, context, actions and dispatcher hooks.muscles-asgi- ASGI runtime spans and server dispatch surfaces.muscles-wsgi- WSGI runtime spans and server dispatch surfaces.muscles-data-sql- native SQL flows that can be traced by application instrumentation.muscles-benchmarks- observability overhead regression checks.
Concept Guardrails
- Observability must follow the Muscles application model and inspect contract, not individual transport implementation details only.
- A trace should show the same use case across ASGI, WSGI, CLI, SQL, MCP, JSON-RPC, and future adapters.
- Instrumentation must be optional and low overhead when disabled.
- Do not couple the framework to one vendor.
- Sensitive data must be redacted by default.
- Instrumentation must not own business dispatch or call handlers twice.
Implemented Features
Implemented opt-in lifecycle instrumentation:
- disabled mode: no span allocation and zero records;
- enabled mode: span duration and attributes are captured.
- package lifecycle entry point:
init_package(app, config)installsOtelPackagethrough Muscles core lifecycle; - provider registration: enabled tracer is registered as the neutral
TelemetryProviderservice, so other packages only depend onmuscles; OtelStrategyMixinformuscles.strategy.execute;OtelContextMixinformuscles.context.execute;instrument_server_dispatch()formuscles.server.dispatch;instrument_action_dispatch()for:muscles.action.execute;muscles.action.validate;muscles.action.rules;muscles.action.handler;
- error status/events for validation, permission, and execution failures;
- sensitive attribute redaction by default.
Implementation note: action lifecycle spans currently mirror the core dispatcher phases through the available dispatcher methods. A future core hook API can replace this with official callbacks without changing the public instrumentation surface.
Package Lifecycle Provider
Applications should install muscles-otel as an optional framework package:
from muscles import (
TelemetryProvider,
doctor_application,
inspect_application,
install_package,
)
from muscles.otel import OtelPackage, init_package
app = App()
tracer = install_package(
app,
{
"enabled": True,
"service_name": "booking-api",
"attributes": {"deployment.environment": "production"},
},
OtelPackage(),
)
telemetry = app.container.resolve(TelemetryProvider)
assert telemetry is tracer
contract = inspect_application(app)
doctor = doctor_application(app)
init_package(app, config) remains available for legacy auto-package loaders
and delegates to the same core lifecycle installer.
Framework packages such as muscles-ai and muscles-documents must not import
muscles.otel directly. They resolve telemetry through Muscles core:
from muscles import resolve_telemetry
telemetry = resolve_telemetry(app)
with telemetry.span("muscles.package.operation"):
...
When this package is not installed, core returns NoopTelemetry.
service_name and service.name both set the default service.name span
attribute. Values under attributes are added to every span after sensitive
keys such as tokens, API keys, prompts and payloads are removed. These are
MusclesTracer defaults today; they are not yet OpenTelemetry SDK Resource
configuration or exporter settings.
Adapters may enrich an active span with runtime facts that are only known after execution:
with telemetry.span("muscles.server.dispatch", **{"http.route": "/ready"}) as span:
response = dispatch()
if isinstance(span, dict):
span["http.status_code"] = response.status_code
Inspection reports the installed otel package and a safe capability payload:
from muscles import inspect_application, doctor_application
inspect_application(app)["capabilities"]["otel"]
# {
# "provider": "MusclesTracer",
# "enabled": True,
# "records.count": 0,
# "attributes.keys": ["deployment.environment", "service.name"],
# }
doctor_application(app)["packages"]["otel"]
# {"status": "ok", "checks": [{"name": "otel.telemetry_provider", ...}]}
Direct Instrumentation Helpers
The package also exposes mixins and helper functions for integration points that already own a concrete dispatch call:
OtelContextMixinformuscles.context.execute;OtelStrategyMixinformuscles.strategy.execute;instrument_server_dispatch(...)for server/request boundaries;instrument_action_dispatch(...)for action validation, rules and handler spans.
Use these helpers at runtime boundaries. Business packages should usually use
only resolve_telemetry(app) and neutral span names.
Run tests
python -m pytest -q
When testing against local core changes:
PYTHONPATH=../muscles/src:src python -m pytest -q
User docs:
- English: docs/otel-lifecycle.en.md
- Русский: docs/otel-lifecycle.ru.md
Metadata
Release files for muscles-otel 2.0.0
For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.
Source distribution (sdist)
| File | Size | Uploaded | Provenance | Actions |
|---|---|---|---|---|
| muscles_otel-2.0.0.tar.gz | 13.4 kB | With provenance | Details for muscles_otel-2.0.0.tar.gz |
Built distribution (wheel)
| File | Interpreter | ABI | Platform | Actions Reset |
|---|---|---|---|---|
| muscles_otel-2.0.0-py3-none-any.whl | Python 3 | none | any | Details for muscles_otel-2.0.0-py3-none-any.whl |
Total release size: 21.8 kB
Release files / muscles_otel-2.0.0.tar.gz
| Download URL | muscles_otel-2.0.0.tar.gz |
|---|---|
| Size | 13.4 kB |
| Tags | Source |
|
SHA-256 checksum How to use checksums |
8fd56bf8330fd0b40b355c51f7aa66e900d8ae5bacc77b8cc71727478d8d193a
|
|
BLAKE2b-256 checksum How to use checksums |
50220d88a24591b383bc5f1e4642c7cf698e32d6460ca858370af670af0e3ae1
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/7.0.0 CPython/3.13.16
|
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Nov 4, 2026.
Transparency logRelease files / muscles_otel-2.0.0-py3-none-any.whl
| Download URL | muscles_otel-2.0.0-py3-none-any.whl |
|---|---|
| Size | 8.4 kB |
| Tags | Python 3 |
|
SHA-256 checksum How to use checksums |
7b74a3cc633ce947013438f367465d53becb3fc3f0cf76a47d080e16368e84e2
|
|
BLAKE2b-256 checksum How to use checksums |
4b1eac5d9d9bc51a08da95a5b0148739b037820002794a6032c4881edcfee152
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/7.0.0 CPython/3.13.16
|
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Nov 4, 2026.
Transparency logSecurity for muscles-otel 2.0.0
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
Full provenance
All 2 files in this release have been uploaded with provenance metadata.
Attestation for muscles_otel-2.0.0.tar.gz
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Nov 4, 2026.
Transparency logA note on package security
PyPI is a repository for distributing packages, not a service for auditing them. While third-party security researchers and our staff do their best to detect and remove malicious packages, PyPI cannot guarantee the quality, security or suitability of any given package.
To learn more about protecting yourself from malicious actors, visit our package security documentation.