lmolkova

---

name: migrate-to-definitions-schema-v2 description: 'Use when writing semantic conventions v2 definition schema (file_format: definition/2*) or migrating v1 schema files to v2 for entities, spans, metrics, events, attribute groups, or signal refinements in any semantic-conventions registry. Enforces minimal attribute groups, internal-by-default visibility, flat structure, and refinement of generic signals over re-declaration.

Migrate semantic conventions from current definition schema to v2

Use this skill when migrating from existing semantic convention (v1, groups) defining attributes, spans, metrics, events, entities, attribute groups, or signal refinement;

lmolkova

attributes:
- key: android.app.state
  type:
    members:
    - id: created
      value: created
      brief: |
        Any time before Activity.onResume() or, if the app has no Activity, Context.startService() has been called in the app for the first time.
      stability: development
    - id: background

lmolkova

attributes:
- key: android.app.state
  type:
    members:
    - id: created
      value: created
      brief: |
        Any time before Activity.onResume() or, if the app has no Activity, Context.startService() has been called in the app for the first time.
      stability: development
    - id: background

lmolkova

Here're some items that we've considered in the past to be useful in azure-core or clientcore related to observability, but never got to it.

• [Azure Core only] Make slf4j dependency optional - backport Slf4JLoggerShim. Related to Azure/azure-sdk-for-java#38421

• [Azure Core only] Merge tracing and metrics plugins into one - Azure/azure-sdk-for-java#41436 or backport plugin-free OTel support from clientcore

• Allow adding arbitrary key-value-pairs on instrumentation context and stamping them on all nested logs and spans (similar to MDC):

lmolkova

TODOs:

• AI weaver - weaver generate should generate new schema behind feature flag - Liudmila will create an issue

Phases:

1. ingest new format
2. resolve new format - need to advertise and socialize
3. modify resolution to be on the new format

| signal/object | identity property in semsonv | in proto |

lmolkova

package live_check_advice

import rego.v1

required_attributes := [
    "http.request.method",
    "server.address",
    "server.port",
    "url.full",
]

lmolkova

from enum import Enum
import json
from typing import Annotated, Any, List, Literal, Optional, Union
from pydantic import BaseModel, Field, RootModel

class TextPart(BaseModel):
    """
    Describes text content sent to or received from the model.
    """
    type: Literal['text']

lmolkova

RequestOptions scenarios

These are the scenarios we support today, not necessarily the ones we have to provide in the final design.

1. Users can provide static (for a group of operations) configuration. E.g.: configure custom logger for all requests peformed in scope of this API call

2. Provide dynamic (per-request) configuration. E.g. set request body or operation-specific context

So RequestOptions is a mix of (usually) per-request and (usually) static config.

lmolkova

Observability in clientcore

• Key changes
• Champion scenarios: user app
  • Default experience
  • Default experience: I want to use custom correlation-id
  • Default experience: add HTTP logs
  • Experience with OTel + logback + HTTP logs
• Champion scenarios: client lib
• Next steps

lmolkova

private string GetFinishReason(ChatFinishReason finishReason) => finishReason switch
{
    ChatFinishReason.Stop => "stop",
    ChatFinishReason.Length => "length",
    ChatFinishReason.ToolCalls => "tool_calls",
    // ...
    _ => finishReason.ToString(),
};

private void LogChoice(ChatCompletion message)