What does this skill do, and when should you use it?
This skill is for Python developers building a custom OpenTelemetry pipeline. It explains how to use Azure Monitor OpenTelemetry Exporter to send traces, metrics, and logs to Application Insights. The guidance covers Microsoft Entra authentication, sampling, offline retry storage, sovereign clouds, and explicit provider shutdown. For quick setup with auto-instrumentation, the source recommends the azure-monitor-opentelemetry distro instead.
It instructs users to install the azure-monitor-opentelemetry-exporter Python package, read APPLICATIONINSIGHTS_CONNECTION_STRING to identify the Application Insights resource, and authenticate ingestion with DefaultAzureCredential or another Azure credential. It configures AzureMonitorTraceExporter, AzureMonitorMetricExporter, and AzureMonitorLogExporter for traces/spans, metrics, and logs. It also demonstrates BatchSpanProcessor, PeriodicExportingMetricReader, BatchLogRecordProcessor, ApplicationInsightsSampler, offline storage, retry behavior, and sovereign-cloud endpoints.
- A Python team needs separate control over trace, metric, and log exporters in a custom OpenTelemetry pipeline.
- A service must authenticate telemetry ingestion with Microsoft Entra ID instead of relying on instrumentation keys.
- A production workload needs batching, consistent sampling, and offline retry storage for transient failures.
- A developer is targeting Azure Government or another sovereign-cloud endpoint with a custom authority.
- A project already uses the OpenTelemetry SDK but does not need the full auto-instrumentation distro.
How do you install this skill?
- Telemetry may contain application logs, exceptions, attributes, and request data; verify redaction, sampling, retention, RBAC, and regional or cross-border data-transfer requirements before deployment.
- Examples do not consistently show provider.shutdown()/force_flush(), and the install command does not explicitly list azure-identity and OpenTelemetry dependencies or compatible versions; validate in the target environment.
- Triggering is narrow, and the skill does not fully define boundaries against the azure-monitor-opentelemetry distro, sync/async usage, or mainland-China networking and sovereign-cloud constraints.
- Shell / CLI
- Network access
- Local filesystem
Pythonazure-monitor-opentelemetry-exporterazure-identityOpenTelemetry Python SDK
Install the collection with npx skills add microsoft/skills, then select this skill in the wizard; it is installed into the chosen Agent directory, such as .github/skills/ for GitHub Copilot. In the Python project, run: pip install azure-monitor-opentelemetry-exporter. The source does not document exact installation paths for other Agents.
tmp="$(mktemp -d)"
git clone --depth 1 https://github.com/microsoft/skills.git "$tmp"
mkdir -p ~/.claude/skills
cp -R "$tmp/.github/plugins/azure-sdk-python/skills/azure-monitor-opentelemetry-exporter-py" ~/.claude/skills/
rm -rf "$tmp"Generated from the source repository and skill path; it copies only this skill's folder. If the author's install steps above differ, follow those first. To scope it to one project, replace ~/.claude/skills with that project's .claude/skills.
How do you use this skill?
Use a trigger such as "azure-monitor-opentelemetry-exporter", "AzureMonitorTraceExporter", "AzureMonitorMetricExporter", or "AzureMonitorLogExporter". Set APPLICATIONINSIGHTS_CONNECTION_STRING; when using DefaultAzureCredential in production, also set AZURE_TOKEN_CREDENTIALS=prod or a specific credential. Configure the required exporter and call provider.shutdown() or force_flush() when the process exits.
What are this skill's strengths and limitations?
- Covers traces, metrics, and logs.
- Supports DefaultAzureCredential, specific Azure credentials, sampling, offline storage, and sovereign clouds.
- Includes copyable Python examples and production-oriented guidance.
- The repository is MIT-licensed and described as actively maintained.
- It is a low-level custom-exporter skill rather than a quick auto-instrumentation solution.
- Applications must explicitly manage provider flushing and shutdown.
- The source does not document independent test coverage or a version compatibility matrix for this individual skill.
- Offline storage requires local filesystem configuration and writes.
How does this skill compare with similar options?
Side by side with related skills; every score comes from the same FSRS standard.
| Skill | FS score | Stars | Last updated | License |
|---|---|---|---|---|
| Azure Monitor OpenTelemetry Exporter this page ✓ Microsoft · Official | 49 · Use with care | ★ 2.7k | 3mo ago | MIT |
| Azure Monitor OpenTelemetry for Python ✓ Microsoft · Official | 45 · Not recommended | ★ 2.7k | 3mo ago | MIT |
| Azure Monitor Telemetry for Java ✓ Microsoft · Official | 44 · Not recommended | ★ 2.7k | 3mo ago | MIT |
| Azure Monitor OpenTelemetry for TypeScript ✓ Microsoft · Official | 43 · Not recommended | ★ 2.7k | 3mo ago | MIT |
| Application Insights Web Monitoring ✓ Microsoft · Official | 54 · Use with care | ★ 2.7k | 3mo ago | MIT |
Compared with the azure-monitor-opentelemetry distro, this skill is intended for custom pipelines and fine-grained control; the distro is intended for quick setup and auto-instrumentation.
How did FollowSkills review this skill?
The documentation recommends DefaultAzureCredential, constraining production credential chains, avoiding instrumentation keys, and states that telemetry is sent to Application Insights. However, it does not explain possible sensitive-data capture, retention or redaction, least-privilege RBAC, user confirmation, external network effects, or recovery boundaries, so points are deducted. No malware, credential theft, covert exfiltration, destructive default, or other red-line behavior is evident.
Installation, authentication, the three exporter types, offline storage, and shutdown guidance provide a plausible happy path, with some retry configuration. However, there are no skill-specific tests, compatibility matrix, abnormal-input handling, or diagnostic failure messages. The skill requires flush/shutdown at exit but most examples do not demonstrate it, so points are deducted. Static calibration caps this score at 10.
The name, trigger phrases, Python audience, and low-level exporter positioning are clear, and the skill distinguishes the distro from custom pipelines. It does not clearly define non-fit cases, input/output contracts, semantic trigger boundaries, Chinese-language usage, or mainland-China network, regional, and proxy considerations, so points are deducted.
Front matter supplies the MIT license, author, and version 1.0.0; the documentation separates the main guide from reference scenarios, while the README, license, CI, and security-reporting material provide some governance signals. Changelog, pinned dependency guidance, explicit maintenance/update ownership, troubleshooting, and complete limitation notes are missing, and some reference content is duplicated, so points are deducted.
Examples cover traces, metrics, logs, Entra authentication, sampling, offline storage, and sovereign clouds, making the core export workflows directly useful. Complete dependency installation, sensitive-telemetry governance, a consistent shutdown example, and verified representative outputs are absent, so users still need review and completion; the score stays below the static ceiling of 7.
The skill includes concrete APIs, environment variables, and configuration examples, and the repository provides general CI, evaluation workflows, and test infrastructure. The supplied material contains no skill-specific test suite, execution results, pinned versions, or independent corroboration, so the assessment relies mainly on author documentation. Static calibration caps this score at 5.
Open a dimension to read why it scored that way
Evidence confidence：Low — Mostly static review, author material or a limited demo; useful for discovery, not high-risk decisions.
See the full review method →