Design Discussion: CDS Support for Kafka Reporter and Connection Sharing Strategy

[zJiaJun]

https://github.com/apache/skywalking-go/pull/218
Current Status
I've successfully implemented the Kafka reporter for the SkyWalking Go agent, which can now transmit:
Tracing data
Metrics data
Logging data
Instance management data (properties and ping)
All these functions work correctly, consistent with the existing gRPC reporter implementation.

Problem Statement
The Configuration Discovery Service (CDS) functionality is currently only available in the gRPC reporter, not in the Kafka reporter. This creates a feature gap between the two reporter types. When reporter.type=kafka is selected in the configuration, the agent loses access to dynamic configuration capabilities.

reporter:
  discard: ${SW_AGENT_REPORTER_DISCARD:false}
  # Reporter type: "grpc" or "kafka"
  type: ${SW_AGENT_REPORTER_TYPE:kafka}
  # The interval(s) of checking service and backend service
  check_interval: ${SW_AGENT_REPORTER_CHECK_INTERVAL:20}
grpc:
 # The gRPC server address of the backend service.
    backend_service: ${SW_AGENT_REPORTER_GRPC_BACKEND_SERVICE:127.0.0.1:11800}
    # The maximum count of segment for reporting tracing data.
    max_send_queue: ${SW_AGENT_REPORTER_GRPC_MAX_SEND_QUEUE:5000}
    # The authentication string for communicate with backend.
    authentication: ${SW_AGENT_REPORTER_GRPC_AUTHENTICATION:}
    # The interval(s) of fetching dynamic configuration from backend.
    cds_fetch_interval: ${SW_AGENT_REPORTER_GRPC_CDS_FETCH_INTERVAL:20}
    tls:
      # Whether to enable TLS with backend.
      enable: ${SW_AGENT_REPORTER_GRPC_TLS_ENABLE:false}
      # The file path of ca.crt. The config only works when opening the TLS switch.
      ca_path: ${SW_AGENT_REPORTER_GRPC_TLS_CA_PATH:}
      # The file path of client.pem. The config only works when mTLS.
      client_key_path: ${SW_AGENT_REPORTER_GRPC_TLS_CLIENT_KEY_PATH:}
      # The file path of client.crt. The config only works when mTLS.
      client_cert_chain_path: ${SW_AGENT_REPORTER_GRPC_TLS_CLIENT_CERT_CHAIN_PATH:}
      # Controls whether a client verifies the server's certificate chain and host name.
      insecure_skip_verify: ${SW_AGENT_REPORTER_GRPC_TLS_INSECURE_SKIP_VERIFY:false}
kafka:
 # Kafka broker addresses, comma separated
    brokers: ${SW_AGENT_REPORTER_KAFKA_BROKERS:127.0.0.1:9092}
    # Topic for segments data
    topic_segment: ${SW_AGENT_REPORTER_KAFKA_TOPIC_SEGMENT:skywalking-segments}
    # Topic for meters data
    topic_meter: ${SW_AGENT_REPORTER_KAFKA_TOPIC_METER:skywalking-meters}
    # Topic for logging data
    topic_logging: ${SW_AGENT_REPORTER_KAFKA_TOPIC_LOGGING:skywalking-logging}
    # Topic for management data
    topic_management: ${SW_AGENT_REPORTER_KAFKA_TOPIC_MANAGEMENT:skywalking-managements}
    # Send queue size
    max_send_queue: ${SW_AGENT_REPORTER_KAFKA_MAX_SEND_QUEUE:5000}
    # Batch size
    batch_size: ${SW_AGENT_REPORTER_KAFKA_BATCH_SIZE:1000}
    # Batch bytes
    batch_bytes: ${SW_AGENT_REPORTER_KAFKA_BATCH_BYTES:1048576}
    # Batch timeout millis
    batch_timeout_millis: ${SW_AGENT_REPORTER_KAFKA_BATCH_TIMEOUT_MILLIS:1000}
    # Acknowledge, 0: none, 1: leader, 2: all
    acks: ${SW_AGENT_REPORTER_KAFKA_ACKS:1}
    # Compression, 0: none, 1: gzip, 2: snappy, 3: lz4, 4: zstd
    compression: ${SW_AGENT_REPORTER_KAFKA_COMPRESSION:3}

Proposed Solutions

Option 1:
Enhanced Kafka Reporter with CDS Support: Extend the Kafka reporter to establish a gRPC connection specifically for CDS functionality. This approach would reuse the existing gRPC configuration parameters to maintain consistency across both reporter types. The Kafka reporter would continue to handle all data reporting through Kafka, but would leverage the gRPC connection exclusively for dynamic configuration discovery.

Option 2:
Decoupled CDS Module with Connection Sharing: Extract the CDS functionality into a standalone module that can be used by both reporter types. Implement a connection sharing mechanism to ensure that when the gRPC reporter is active, both the reporter and CDS functionality share a single connection to the backend service. This architecture would prevent redundant connections while maintaining clear separation of concerns between reporting and configuration discovery.

// When reporter.type=grpc, CDS can share the main connection
// When reporter.type=kafka, a separate connection is created for CDS

Questions for Discussion
Which option is suitable, or are there any other better alternatives?
@mrproliu @wu-sheng

[wu-sheng]

CDS should always be available, as well as grpc connection.
Kafka reporter is not going to replace grpc, it just takes over telemetry data reporting.
If I remember correctly in Java, property report, cds and some other data are still being reported via grpc when kafka reporter activated.