OTel

md

- Trace - an end-to-end trace of an end-user request inside a distributed application; this trace might include correlating data from
  multiple services and multiple processes. It’s the output of the distributed tracing system.
- Span - a single, atomic unit of work that occurs inside an application. This can be one HTTP request processing method on an MVC
  controller, an Akka.NET actor processing a message, a RabbitMQ client sending a single message over the network, and so forth. Spans
  contain contextual data such as the name of the operation, the server / application it was executed on, the start and stop times, log
  events, and key / value pairs of tags that can be used to make the span searchable. A trace is constructed from the sum of its spans.
- SpanContext - a descriptor that is included inside each span which describes this span’s relationship to its parent span (i.e. the
  previous operation that occurred in processing the request) and to the trace itself. The SpanContext can also include “baggage” - key/value
  pairs of data that are propagated from one operation to the next. How this gets implemented is specific to each tracing implementation.
- Propagation - propagation is the tool used to serialize and deserialize data across service boundaries. Having standardized ways of
  representing trace ID, span IDs, and possibly baggage across service boundaries is one of the key ingredients for correlating data across
  services. In fact, it’s become so important that the W3C is actively working on implementing standardized distributed tracing header formats
  that will eventually make their way into HTTP itself. OpenTracing exposes some standard tools and formats for injecting / extracting trace
  information from requests, including non-HTTP vehicles such as Akka.NET actor messages, gRPC events, and so forth.

OTel is not an observability back-end like Jaeger or Prometheus. Instead, it supports exporting data to a variety of open source and
commercial back-ends.

https://opentelemetry.io/docs/concepts/components/
- API: Defines data types and operations for generating and correlating tracing, metrics, and logging data.
- SDK: Defines requirements for a language-specific implementation of the API. Configuration, data processing, and exporting concepts are
  also defined here.
- Data: Defines the OpenTelemetry Protocol (OTLP) and vendor-agnostic semantic conventions that a telemetry backend can provide support for.

https://opentelemetry.io/docs/concepts/signals/traces/#tracing-in-opentelemetry
Signals: Traces, Metrics, Logs
(Shim https://github.com/open-telemetry/opentelemetry-dotnet/issues/947)


# Traces
  - contructed from the sum of it's spans
  - Traces give us the big picture of what happens when a request is made by user or an application
      - Tracer: factory for Tracer's, is initialized once and its lifecycle matches the application’s lifecycle, includes Resource and
        Exporter initialization
      - Tracer Provider: creates spans containing more information about what is happening for a given operation,
      - Trace Exporter: send traces to a consumer
      - Trace Context: core concept. By combining Context and Propagation, you now can assemble a Trace.
        - With this Spans can be correlated with each other and assembled into a trace
        - Context: is an object that contains the information for the sending and receiving service to correlate one span with another
        - Propagation: is the mechanism that moves Context between services and processes. 
Span - an atomic unit of work inside an application
  - A Span represents a unit of work or operation. Spans are the building blocks of Traces
  - start and stop times
  - log events
  - key/value pairs which can be searched
  - Spans can be nested
  - Span Context: is an immutable object on every span. Is the part of a span that is serialized and propagated alongside Distributed
    Context and Baggage.
  - Attributes: are key-value pairs that contain metadata that you can use to annotate a Span
  - Span Event: can be thought of as a structured log message on a Span
  - Span Link: an associate one span with one or more spans, implying a causal relationship
  - Span Status: Typically when there is a known error
  - Span Kind: Client, Server, Internal, Producer, or Consumer

# Metrics

- a measurement about a service, captured at runtime.
- important indicators of availability and performance.
- intended to provide statistical information in aggregate.
1. counter: a value that is summed over time: odometer
2. measure: a value that is aggregated over time. the trip odometer
3. observer: captures a current set of values at a particular point in time. fuel gauge
- aggregates: sum, count, last value, and histograms
- Meter => Counter, Gauge, Histogram, UpDownCounter
- Azure Functions: https://opentelemetry.io/docs/reference/specification/metrics/semantic_conventions/faas-metrics/#metric-references
- Metric points: https://opentelemetry.io/docs/reference/specification/metrics/data-model/#metric-points
- .Net Metrics https://learn.microsoft.com/en-us/dotnet/core/diagnostics/metrics-instrumentation

https://opentelemetry.io/docs/reference/specification/metrics/api/
    Create a new Counter => Counter (CreateCounter) | ObservableCounter (CreateObservableCounter) 
    Create a new Asynchronous Counter => 
    Create a new Histogram => Histogram (CreateHistogram) 
    Create a new Asynchronous Gauge => ObservableGauge 
    Create a new UpDownCounter => UpDownCounter (CreateUpDownCounter) | ObservableUpDownCounter (CreateObservableUpDownCounter) 
    Create a new Asynchronous UpDownCounter

# Logs

- timestamped text record
- independent data source, they may also be attached to spans
- any data that is not part of a distributed trace or a metric is a log

- an event is anything that happens in your system that is worth tracking.
  -  events should be wide because they can contain many different fields

- Tracing is implemented by the System.Diagnostics
  - repurposing older constructs like ActivitySource and Activity