Audit Compliance GDI specification pre-v1.7.0: Behaviors

[pellared]

Review against https://github.com/signalfx/gdi-specification/blob/ce84954821bfe6ab6f6f1ed6cad5f87489293220/specification/behaviors.md

[pellared]

An instrumentation library that has profiling capabilities MUST be able to sample call stacks at a fixed interval.

✅

When a language runtime supports threading, stacks MUST be sampled across all process threads.

✅ n/a (single threaded)

The samples for all threads SHOULD be taken instantaneously and, in the event that this is not feasible, MUST be taken as close together as possible.

✅ n/a (single threaded)

If the samples are taken consecutively, then the profiler MUST use a consistent ordering strategy (such as thread name or ID) when sampling all threads.

✅ n/a (single threaded)

Various runtimes MAY contain internal and other threads that are undesirable to include for profiling. This could include threads that are internal to runtime behavior or instrumentation library internal workings. The choice of which threads are undesirable is implementation specific and not defined.

✅ n/a (single threaded)

The profiler SHOULD NOT collect call stacks from undesirable threads. If this is not possible, the profiler SHOULD filter these out afterward and omit these call stacks from ingest.

✅ n/a (single threaded)

When a call stack is sampled during the execution of a span scope, the profiler MUST be able to associate the call stack to the span.

✅

This association SHOULD happen as close to the sampling point as feasible, but MAY occur later in a processing pipeline.

✅

Call stacks MUST be ingested as OpenTelemetry Logs.

✅

The logs containing profiling data MUST be sent via OTLP.

✅

Instrumentation libraries SHOULD reuse persistent OTLP connections from other signals (traces, metrics).

✅