Proposal to Add Nacos Client Instrumentation to OpenTelemetry JavaAgent

[wzy531a]

Is your feature request related to a problem? Please describe.

Nacos is an easy-to-use dynamic service discovery, configuration and service management platform for building cloud native applications.

The problem is that currently, when using the Otel JavaAgent for instrumentation, there is no built-in support for collecting spans related to the nacos-client. However, referencing the successful implementation of nacos-client plugin in the Skywalking project, I have developed a comprehensive instrumentation for the nacos-client that is compatible with OpenTelemetry. This new instrumentation aims to bridge the gap and enable OpenTelemetry users to effectively monitor and trace the behavior of the nacos-client, aligning with the capabilities provided by Skywalking.

Describe the solution you'd like

Based on my review of the nacos-client source code, I discovered that it communicates over gRPC and utilizes a modified version of the io.grpc code, located within the com.alibaba.nacos.shaded.io.grpc package. This setup prevents the gRPC-v1.6 instrumentation from detecting it.

Additionally, drawing inspiration from Skywalking's approach to nacos-client instrumentation, which involves generating corresponding spans based on different types of requests, I propose combining these insights.

Specifically, I plan to modify the instrumentation location from io.grpc.* to com.alibaba.nacos.shaded.io.grpc.* based on the TypeInstrumentation implemented in OpenTelemetry's gRPC-v1.6 instrumentation. Additionally, I intend to retrieve the Request within the sendMessage method of TracingClientInterceptor.TracingClientCall and add some tags to the generated Span based on the type of the Request.	Request Child Class	SpanName	Additional Tags
InstanceRequest ServiceQueryRequest SubscribeServiceRequest ServiceListRequest ConfigQueryRequest	Nacos/${InstanceRequest.getType()} Nacos/queryService Nacos/getServiceList Nacos/queryConfig Nacos/queryConfig	nacos.namespace nacos.group nacos.service.name
ConfigPublishRequest ConfigRemoveRequest ConfigChangeNotifyRequest	Nacos/publishConfig Nacos/removeConfig Nacos/notifyConfigChange	nacos.data.id nacos.group nacos.tenant
NotifySubscriberRequest	Nacos/notifySubscribeChange	nacos.group nacos.service.name

This approach aims to process specific requests within the gRPC client interceptor to generate the corresponding spans, enabling comprehensive monitoring and tracing of the nacos-client. This method aligns with the behavior observed in the Skywalking project and provides a more tailored and focused implementation for comprehensive monitoring and tracing of the nacos-client.

Describe alternatives you've considered

No response

Additional context

No response

[AlchemyDing]

currently, it seems that there are no semconv related to service discovery or config in opentelemetry，such as nacos, consul, zookeeper, etc.

[AlchemyDing]

To my knowledge, nacos client-1.x is based on HTTP implementation, not GRPC. Maybe you also need to implement an instrumentation for 1. x

[wzy531a]

To my knowledge, nacos client-1.x is based on HTTP implementation, not GRPC. Maybe you also need to implement an instrumentation for 1. x

The above plan is only applicable to Nacos client 2.0.3+. I have no idea about the support for version 1. x, and Nacos currently does not recommend users to use version 1. x as it is about to stop maintenance

[wzy531a]

currently, it seems that there are no semconv related to service discovery or config in opentelemetry，such as nacos, consul, zookeeper, etc.

currently, it seems that there are no semconv related to service discovery or config in opentelemetry，such as nacos, consul, zookeeper, etc.

The library I want to support is nacos client, which is based on GRPC communication in version 2. x, so the semconv of RPC can be used

[AlchemyDing]

How do you add attributes by using rpc's semconv such as nacos.namespace, nacos.group, nacos.service.name, etc.

[AlchemyDing]

Welcome to contribute.