Define profiling.instrumentation.source Log Message Attribute

[tduncan]

The profiling backend ingestion process needs to be able to distinguish between callstacks collected by the existing continuous "Always On" profiler and those collected by the upcoming trace snapshot profiler. This PR defines an attribute to be included in a log message body that will identify which profiling process was responsible for collecting and reporting the exported callstacks.

[pellared]

Can you please add a changelog entry?

[tduncan]

Can you please add a changelog entry?

Done.

[Kielek]

I am not against change for a short term solution, but we need to start thinking how to handle the OTLP profiling protocol. I hope it will go live this year.

In such cases you will be not able to expect such attributes.
For known, libraries, you can probably utilize

• InstrumentationScope
  For all generic cases:
• SampleType
• PeriodType

[Kielek]

I think that, for backward compatibility, you should mention that it will be treated as continuous.

[seemk]

This, there are too many existing installations, my suggestion is that profiling.instrumentation.source must only be set when anything other than continuous is used (as the backend treats all of the profiles as continuous by default).

[tduncan]

I am not against change for a short term solution, but we need to start thinking how to handle the OTLP profiling protocol. I hope it will go live this year.

In such cases you will be not able to expect such attributes. For known, libraries, you can probably utilize

• InstrumentationScope
  For all generic cases:
• SampleType
• PeriodType

SampleType and PeriodType would seem to be describing the data itself, where as what we need to know is information about the context from which the callstacks were collected as the values for both SampleType and PeriodType would be identical. The shape of the profiling data does not vary between the existing continuous profiling solution and the trace snapshot extension we're porting into the Java agent.

I was hoping to use InstrumentationScope but conversations with individuals more familiar with the GDI process made it clear that, at least for now, the InstrumentationScope information will not be available for us to rely on.

[Kielek]

I am not against change for a short term solution, but we need to start thinking how to handle the OTLP profiling protocol. I hope it will go live this year.
In such cases you will be not able to expect such attributes. For known, libraries, you can probably utilize

• InstrumentationScope
  For all generic cases:
• SampleType
• PeriodType

SampleType and PeriodType would seem to be describing the data itself, where as what we need to know is information about the context from which the callstacks were collected as the values for both SampleType and PeriodType would be identical. The shape of the profiling data does not vary between the existing continuous profiling solution and the trace snapshot extension we're porting into the Java agent.

I was hoping to use InstrumentationScope but conversations with individuals more familiar with the GDI process made it clear that, at least for now, the InstrumentationScope information will not be available for us to rely on.

For our internal internal profiling format, we can put any data we want. The problem will be with the OTLP-profiling of the protocol. From the very beginning we should be ready to understand different sets of data. The most important bringing from OTEL world is ebpf-profiling. What is more, for sure the .NET data will be send in the OTel-compliant way. The data source is working, we need to add only the exporter.

Avoiding any Cisco/Splunk specific attributes should be our goal. If needed, we can start working on semantic-convention for profiling, but need to have good proposal for this.

[tduncan]

I've mangled the commit signing and unable to figure out how to fix it. Instead I've opened #337 with correctly signed commits.