Otlp support

[Vibaswan]

This PR is currently work in progress for the OTLP support in openapiart

Fixes #434 Fixes #435

First Step taken is to implement telemetry in go-snappi

Things done till now

• Added Infrastructure for users to provide collector endpoint, exporter transport etc.
• Added infrastructure by which users can create custom span, with attributes , set span status , set root context etc.
• The generated SDK (Go/Python) automatically generates child spans for GRPC/HTTP communication internally provided the user has provided endpoint.
• HTTP as well GRPC transport instrumentation.
• Support for both HTTP and GRPC transport communication with the collector.
• Added support so that users can provide their own custom span Processors for formatting spans. (Would be need by Controller as well)

Things to be done

• Finalize the versions of python to support OTLP
• Finalize whether to drop go 1.17 support
• Explore if the context mapping of the controller can be shift to go-snappi itself

Sample Scripts.

Note: FYI the sample scripts were run from openapiart to otg-hw just to showcase the use-cases, as openapiart has its own sample model the set config error out

No custom Span provided by the user

func TestTelemetry(t *testing.T) {
    api := gosnappi.NewApi()
    api.NewGrpcTransport().SetLocation("10.66.47.117:5001")

        // start basically creates the trace provider which is a pipe keeping hold of the telemetry data
        tel, err := api.Telemetry().WithExporterEndPoint("10.66.47.117:4318").Start()
    if err != nil {
        t.Log(err)
    }
        // this is a mandatory step in the script if using telemetry, as it will stop the tracing and shut down the tracer
        // cannot be called automatically from the SDK as we don't know the when the user wants to stop it 
    defer tel.Stop()
    // NewFullyPopulatedPrefixConfig is just a dummy func here , actual config will be built here
        config := NewFullyPopulatedPrefixConfig(api)
    resp, err := api.SetConfig(config)
}

Python Sample script:

import snappi

api = snappi.api(location="10.66.47.117:5001", transport="grpc", verify=False,
                 telemetry_collector_endpoint="http://10.66.47.117:4318/v1/traces")

with api.tracer().start_as_current_span("test-telemetry"):
    # perform api calls for rest of the script

# scope of span ends
print("test passed")

Note: nomenclature for the functions are not finalized

Jaeger visualization

When custom Span is added by the user

func TestTelemetry(t *testing.T) {
    api := gosnappi.NewApi()
    api.NewGrpcTransport().SetLocation("10.66.47.117:5001")
    tel, err := api.Telemetry().WithExporterEndPoint("10.66.47.117:4318").StartTracing()
    if err != nil {
        t.Log(err)
    }
    defer tel.StopTracing()

        // adding custom span from the script
    ctx, span := tel.NewSpan(context.Background(), "test-telemetry")
    // generally if we are adding a span we want the SDK to generate child spans for this custom span.
    // so that its easier to visualize.
    // That's why we need to set the root context so that the SDK can treat it as parent and generate the rest of the child spans 
        tel.WithRootContext(ctx)
    defer tel.CloseSpan(span)

        // NewFullyPopulatedPrefixConfig is just a dummy func here , actual config will be built here
    config := NewFullyPopulatedPrefixConfig(api)
    resp, err := api.SetConfig(config)
}

Jaeger visualization

Current Challenges

• the latest go.opentelemetry.io/otel packages v1.51.1 supports only go 1.19 and 1.20, as openapiart supports 1.17-1.20 its difficult to find a version which satisfies all the go distributions, the best I could find out is v1.40.0 which supports go 1.18-1.120 we need to decide if we need to support go 1.1.7 still ? https://github.com/open-telemetry/opentelemetry-go/releases/tag/v1.14.0
• Have not started working with python but I guess that we will be facing uses for 2.7 and lower than 3.6 https://pypi.org/project/opentelemetry-api/ states here Requires: Python >=3.7

[rudranil-das]

Adding some ToDos (all of which might not be entirely doable through snappi, but keeping a note as end goal)

1. Need to find a way to propagate test-case PASS/FAIL info as part of span, preferably not requiring to update individual TCs. (this is a priority for controller CI TCs)
2. Ability to add some common attributes in all spans from an application.
3. Ability to dump all spans from an application in a local file (this ability could be optional and application may want to trigger it through a flag/option)