Brokers hosted on StreamNative Cloud do not respond to ping
requests. Instead, you can use the methods presented in this guide to test the connectivity to your StreamNative Cloud cluster and its endpoints before whitelisting them.
Run through the following steps to validate StreamNative Cloud connectivity is working as expected.
You can test connectivity to any StreamNative Cloud cluster using openssl
, Netcat
, or Telnet
.
For clusters with public endpoints, you can run connectivity tests from any computer with internet access.
For clusters in private network environments (such as PrivateLink, Private Service Connect, VPC peering, VNet peering, and AWS Transit Gateway), run tests from within your VPC or VNet that is connected to the StreamNative Cloud cluster.
All the services of a StreamNative Cloud cluster share the same DNS name, but use different ports:
443
to test the connection to the Pulsar HTTP service, Websocket service, REST messaging service, and the Kafka schema registry service.6651
to test the connection to the Pulsar Broker service.9093
to test the connection to the Kafka Broker service.8883
to test the connection to the MQTT service.To test the connection to the Kafka Broker and MQTT service, ensure that both Kafka and MQTT protocols are enabled on your cluster. These protocols are enabled by default on new clusters. However, for older clusters, you may need to enable them manually.
To only test TCP connectivity, use Telnet
or Netcat
:
Netcat
Telnet
In addition to TCP connectivity, to also test the TLS handshake and the certificate, use openssl
. With openssl
, you can an SNI header:
OpenSSL
For more details, see the OpenSSL documentation for the -connect
option.
It is recommended that you use openssl
to test TCP and TLS because with the TCP testing only, it is difficult to make the distinction among the various cases when a connection fails, such as:
Timeout because of routing problems.
Established connection, but you as the client not initiating the TLS handshake.
Envoy disconnecting your connection because you do not send the SNI header.
For Kafka clients, see the TLS SNI extension requirements for more details.
After connectivity is successfully established, you can use the Pulsar or Kafka clients and/or tools to test producing/consuming messages. Examples are pulsar-client
, kcat
, kafkacat
, kafka-console-consumer
, kafka-console-producer
, native command line tools, or Java and other clients. The following are a few of the test workflows you can use as references:
If connectivity to the cluster endpoint cannot be established, first check your firewall and other security configurations and restrictions that could prevent the connection to the StreamNative Cloud cluster endpoint.
Here are some common issues and their troubleshooting steps:
Issue: You got an error message similar to the following from a Kafka client over a private link, such as produce or consume messages:
Possible causes:
Brokers hosted on StreamNative Cloud do not respond to ping
requests. Instead, you can use the methods presented in this guide to test the connectivity to your StreamNative Cloud cluster and its endpoints before whitelisting them.
Run through the following steps to validate StreamNative Cloud connectivity is working as expected.
You can test connectivity to any StreamNative Cloud cluster using openssl
, Netcat
, or Telnet
.
For clusters with public endpoints, you can run connectivity tests from any computer with internet access.
For clusters in private network environments (such as PrivateLink, Private Service Connect, VPC peering, VNet peering, and AWS Transit Gateway), run tests from within your VPC or VNet that is connected to the StreamNative Cloud cluster.
All the services of a StreamNative Cloud cluster share the same DNS name, but use different ports:
443
to test the connection to the Pulsar HTTP service, Websocket service, REST messaging service, and the Kafka schema registry service.6651
to test the connection to the Pulsar Broker service.9093
to test the connection to the Kafka Broker service.8883
to test the connection to the MQTT service.To test the connection to the Kafka Broker and MQTT service, ensure that both Kafka and MQTT protocols are enabled on your cluster. These protocols are enabled by default on new clusters. However, for older clusters, you may need to enable them manually.
To only test TCP connectivity, use Telnet
or Netcat
:
Netcat
Telnet
In addition to TCP connectivity, to also test the TLS handshake and the certificate, use openssl
. With openssl
, you can an SNI header:
OpenSSL
For more details, see the OpenSSL documentation for the -connect
option.
It is recommended that you use openssl
to test TCP and TLS because with the TCP testing only, it is difficult to make the distinction among the various cases when a connection fails, such as:
Timeout because of routing problems.
Established connection, but you as the client not initiating the TLS handshake.
Envoy disconnecting your connection because you do not send the SNI header.
For Kafka clients, see the TLS SNI extension requirements for more details.
After connectivity is successfully established, you can use the Pulsar or Kafka clients and/or tools to test producing/consuming messages. Examples are pulsar-client
, kcat
, kafkacat
, kafka-console-consumer
, kafka-console-producer
, native command line tools, or Java and other clients. The following are a few of the test workflows you can use as references:
If connectivity to the cluster endpoint cannot be established, first check your firewall and other security configurations and restrictions that could prevent the connection to the StreamNative Cloud cluster endpoint.
Here are some common issues and their troubleshooting steps:
Issue: You got an error message similar to the following from a Kafka client over a private link, such as produce or consume messages:
Possible causes: