Does Opentelemetry Metric Retriever focus on prometheus metrics

[kellis5137]

First, I have worked for Dynatrace and AppDynamics in a Sales Engineering role and have seen my share of open source APMs and I put Skywalking on the top. In addition to my sales engineering roles, I have been a software/cloud engineer for over 20 years, predominantly using Java. I've been diving into the code specific to ingesting Otel metrics, trying to figure out why certain things are failing to get ingested, and I think I found something. I'm hoping someone here can confirm my conclusion.

It appears looking at the code for the OpenTelemetryMetricRequestProcessor.java, in particular this bit of code:
private static final Map<String, String> LABEL_MAPPINGS = ImmutableMap .<String, String>builder() .put("net.host.name", "node_identifier_host_name") .put("host.name", "node_identifier_host_name") .put("job", "job_name") .put("service.name", "job_name") .build();

Here, it appears to me, that the Skywalking service name mapping is being linked to the Otel resource attribute "job_name" which is only put there if prometheus is being used for a otel collector receiver. Otel, specifically, has a service.name that can already be used. I thought maybe that it was just a default that will be replaced based on the incoming attributes of the Otel message, but looking at this:

final Map<String, String> nodeLabels = request .getResource() .getAttributesList() .stream() .collect(toMap( it -> LABEL_MAPPINGS .getOrDefault(it.getKey(), it.getKey()) .replaceAll("\\.", "_"), it -> anyValueToString(it.getValue()), (v1, v2) -> v1 ));
... it doesn't appear that it's overriding any attributes. So I'm wondering, am I wrong? If I'm right, is there a reason this was done? Also, if I'm right and there is no one actively working on this, I would love to pick up. Thanks!

[wu-sheng]

Here, it appears to me, that the Skywalking service name mapping is being linked to the Otel resource attribute "job_name" which is only put there if prometheus is being used for a otel collector receiver.

No, it doesn't have to be Prometheus. We need it to distinct the sources as all jobs are sharing the same port.

You could see this kind of filter of every otel-rules/** MAL files.

filter: "{ tags -> tags.job_name == 'activemq-monitoring' }" # The OpenTelemetry job name

We are not focusing on Prometheus.

it doesn't appear that it's overriding any attributes

What do you mean by this? We rename those not for every special reason, just the one wrote this doesn't like the old one when he integrated with Prometheus(there was a Prometheus fetcher), and being inherited to receiver to keep codes unbreak.

__

But besides the above, I am not sure what is the core issue?

[kellis5137]

Thank you @wu-sheng , thank you for your quick response. I think I understand now how the service is being label; I didn't know what this does, but now I do:

expSuffix: tag({tags -> tags.cluster = 'k8s-cluster::' + tags.cluster}).service(['cluster'], Layer.K8S)

I apologize for assuming something was broken.

Another question, if I may? The existing implementation of ingesting OTEL Trace information is to take the OTEL, send to Zipkin, store in Skywalking. However, it appears there is no direct method to view the data via Skywalking except going through LensUI. Is there any intent to ingest OTEL tracing data into the native Skywalking model? If not, is there any reason it might not work?

[wu-sheng]

Because SkyWalking native trace has more context information than otel(zipkin style) data.
SkyWalking traces are analysis oriented, they are APM style trace.

Read https://skywalking.apache.org/docs/main/latest/en/papers/stam/, it explains why SkyWalking traces are different.