lmolkova

• Champion Scenarios in Container Registry 1.1.0 SDKs
  • Java
    • Create blob client
    • Upload an OCI Image sync
    • Upload blob from file async
    • Download an OCI Image sync
    • Download blob async
• Upload an OCI Image with custom manifest type

lmolkova

Settlement in messaging systems

Proposal

Attributes:

• is there a need in generic?
• messaging.settlement.settled: boolean

System-specific:

• messaging.kafka.committed.offset
• messaging.rabbitmq.ack.type, messaging.rabbitmq.ack.delivery_tag

lmolkova

Azure SDK for Java: tracing changes

Motivation

• Improve API usability for SB/EH
• Allow explicit configuration
• GA tracing plugin

Usage scenarios

End-users

lmolkova

Based on:

• AMQP
  • General
  • Azure ServiceBus AMQP extensions
  • Azure EventHubs AMQP extensions
• JMS
• Kafka
• RabbitMQ

lmolkova

OpenTelemetry Metrics Semantic Conventions for Azure Messaging Libraries

Context: https://gist.github.com/lmolkova/b9004307a09be788af04f05ebe22ad3c

Follows general OTel Metrics conventions and depends on OTel Messaging conventions changes

AMQP-level metric instruments

Name	Description	Units	Instrument Type (*)	Value Type	Attribute Key(s)	Attribute Values

lmolkova

Kafka

• Host: net.peer.name:net.peer.port (actual host contacted)
  • always present
• Topic name: messaging.destination.name
  • maybe present per message, not per publish call - https://stackoverflow.com/questions/39093488/can-single-kafka-producer-produce-messages-to-multiple-topics-and-how

no url notion

JMS

lmolkova

Metrics in Azure SDK for Java

The immediate goal is to report metrics from Azure messaging SDKs (EventHubs and ServiceBus) to help customers detect and investigate configuration issues, performance bottlenecks, application and SDK bugs.

It can be broken down into smaller goals:

• define metrics essential for messaging scenarios
• define Metrics API in azure-core
• metrics plugin implementations

lmolkova

Quarkus configuration

Quarkus configuration is very similar to Spring:

• supports application.properties and application.yaml
• conventions on property names are the same: '.' as separator, kebab-case.
• supports property sources, iterating over them and getting value by name programmatically or with annotation

What's different:

• Quarkus uses smallrye-config which is implementation of microprofile-config. Annotation and feature-wise, it's similar to spring, but more explicit (reflection is discouraged)
• Property metadata can be extended with microprofile language-server extension (example)

lmolkova

Note: New APIs are still work in progress and need polishing

Please build azure-core and azure-data-appconfiguration from https://github.com/lmolkova/azure-sdk-for-java/tree/configuration-sdk/ branch

PR: Azure/azure-sdk-for-java#26420

Usage

// 1. Implement a ConfigurationSource
// 2. Build client-specific Configuration

lmolkova

• SDKs expose IAzureClientBuilder<EventHubProducerClient, EventHubProducerClientOptions> AddEventHubProducerClient<TBuilder, TConfiguration>(this TBuilder builder, TConfiguration configuration) where TBuilder : IAzureClientFactoryBuilderWithConfiguration<TConfiguration>

  • Configuration format and binding to options are not defined in Azure SDKs

• Implementation lives in Microsoft.Extensions.Azure

  • binding to options is done by microsoft.extensions.configuration through IConfiguration.Bind() and relies on *Options following microsoft.extensions.configuration conventions (i.e. properties)
  • options sources are whatever microsoft.extensions.configuration supports:
    • appsettings.json
    • env var config (flat) is supported through ASP.NET Core conventions

• Config