Skip to main content

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 OtelPackage once during bootstrap;
  • other packages call resolve_telemetry(app) from muscles;
  • 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).

  • 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) installs OtelPackage through Muscles core lifecycle;
  • provider registration: enabled tracer is registered as the neutral TelemetryProvider service, so other packages only depend on muscles;
  • OtelStrategyMixin for muscles.strategy.execute;
  • OtelContextMixin for muscles.context.execute;
  • instrument_server_dispatch() for muscles.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:

  • OtelContextMixin for muscles.context.execute;
  • OtelStrategyMixin for muscles.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:

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)

Source distribution for muscles-otel 2.0.0
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)

Table of built distributions (wheels) for muscles-otel 2.0.0
File Interpreter ABI Platform Actions
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 log

Release 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 log

Security 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.

Select from 2 files

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 log

A 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.

Anthropic, PBC Visionary sponsor Bloomberg Visionary sponsor Hudson River Trading Visionary sponsor Meta Visionary sponsor NVIDIA Visionary sponsor Microsoft Sustainability sponsor Depot Continuous Integration AWS Cloud computing and Security Sponsor Datadog Monitoring Fastly CDN Google Download Analytics Sentry Error logging StatusPage Status page