The Basics

• Service team responsible for the client library: Azure Monitor / Application Insights (Board Review: Introduction to Application Insights #1621)
• Link to documentation describing the service: Board Review: Introduction to Application Insights #1621
• Contact email (if service team, provide PM and Dev Lead): @ramthi @reyang

About this client library

• Name of the client library: Microsoft.OpenTelemetry.Exporter.AzureMonitor
• Languages for this review: C#, Java, JavaScript and Python
• Link to the service REST APIs: https://github.com/Azure/azure-rest-api-specs/blob/master/specification/applicationinsights/data-plane/Monitor.Exporters/preview/2020-09-15_Preview/swagger.json
• This library takes a dependency on OpenTelemetry library in all languages.
• OpenTelemetry specification

Namespace and package names

Python:
microsoft-opentelemetry-exporter-azuremonitor

JS:
@microsoft/opentelemetry-exporter-azure-monitor

C#:
Microsoft.OpenTelemetry.Exporter.AzureMonitor

Java:
Group ID - com.microsoft
Artifact name - microsoft-opentelemetry-exporter-azuremonitor

Artifacts required (per language)

We use an API review tool (apiview) to support .NET and Java API reviews. For Python and TypeScript, use the API extractor tool, then submit the output as a Draft PR to the relevant repository (azure-sdk-for-python or azure-sdk-for-js).

.NET

• apiview
• Link to samples for champion scenarios:
  https://github.com/Azure/azure-sdk-for-net/blob/master/sdk/monitor/Azure.Monitor.OpenTelemetry.Exporter/tests/Azure.Monitor.OpenTelemetry.Exporter.Demo.Tracing/DemoTrace.cs#L16-L25

Java

• apiview
• Link to samples for champion scenarios: https://github.com/Azure/azure-sdk-for-java/tree/master/sdk/monitor/azure-monitor-opentelemetry-exporter/src/samples/java/com/azure/monitor/opentelemetry/exporter

Python

• apiview
• Link to samples for champion scenarios: https://github.com/Azure/azure-sdk-for-python/tree/master/sdk/monitor/azure-monitor-opentelemetry-exporter/samples/traces

TypeScript

• apiview
• Link to samples for champion scenarios: Samples

Champion Scenarios

A champion scenario is a use case that the consumer of the client library is commonly expected to perform. Champion scenarios are used to ensure the developer experience is exemplary for the common cases. You need to show the entire code sample (including error handling, as an example) for the champion scenarios.

• Champion Scenario:
  • Send tracing data to Azure Monitor for troubleshooting and business analytics.

  • 50% of the user would enable this feature.

An online retail business has an Order Management Service which interacts with multiple services like payments, logistics, inventory, address book etc and each of these services can further make calls to other services or to application databases. In order to troubleshoot issues with an order, the company wants to enable distributed tracing to track each request originating from the order management service.

This service is using Azure Core OpenTelemetry tracing library for capturing trace data and wants to export this to Azure Monitor to view the trace information on Application Insights portal. The library we are discussing in today's arch board does the exporting part. Note that there are other exporters and visualizing tools available like Jaeger, Zipkin etc that also follow the OpenTelemetry specifications and the service should be able to use any of these exporters.

Instrumenting application code for distributed tracing

https://opentelemetry.io/docs/concepts/instrumenting/

Agenda for the review

The Part 1 intro meeting was in August: #1621

The Agenda is to review the package name, Microsoft.

A board review is generally split into two parts, with additional meetings as required

Part 1 - Introducing the board to the service:

• Review of the service (no more than 10 minutes).
• Review of the champion scenarios.
• Get feedback on the API patterns used in the champion scenarios.

After part 1, you may schedule additional meetings with architects to refine the API and work on implementation.

Part 2 - the "GA" meeting

• Scheduled at least one week after the APIs have been uploaded for review.
• Will go over controversial feedback from the line-by-line API review.
• Exit meeting with concrete changes necessary to meet quality bar.

Thank you for your submission