Validate network connectivity

Prerequisites

Verify that every application, Collector, and administrative network in the migration wave can reach the required Splunk Observability Cloud endpoints. Complete these checks before creating access tokens or sending test data.

Confirm that:

• The applications, Collectors, proxies, gateways, and network zones in the migration wave are identified.
• Network and security contacts are available.
• Identify the owner and process for requesting firewall or proxy changes.
• You have permission to run connectivity tests from the applicable hosts.

Identify the required network paths

Use View your realm, API endpoints, and organization to obtain the endpoints for your organization.

Identify the required path for each source:

These connections generally use outbound TCP port 443. Review Allow Splunk Observability Cloud services in your network for the current domains and service URLs that your network must allow.

For each source network zone, identify which Splunk Observability Cloud services it must access. Using the current Splunk network allowlist, ask your network or security team to permit outbound connections only to the destinations required for that source. For example:

Request required firewall changes

For each required network path that you cannot use, work with your network or security team to allow the connection.

Include the following information in each firewall or proxy change request:

• Source host, subnet, or network zone
• Destination endpoint or approved domain
• Outbound TCP port 443
• Protocol, such as HTTPS or OTLP over gRPC
• Business purpose
• Migration wave
• Change owner and approver
• Required completion date

Use the network-path inventory to determine which destinations each source requires:

Request only the paths required by the approved deployment topology. If you use OTLP over gRPC, confirm that firewalls, proxies, and inspection devices permit HTTP/2 and gRPC traffic.

Splunk Observability Cloud telemetry connections are initiated outbound. This procedure does not require opening an inbound connection from Splunk Observability Cloud to the application network.

See Allow Splunk Observability Cloud services in your network for the current domains and service URLs.

Test endpoint connectivity

Run the tests from every network zone that sends telemetry or makes API requests. Replace <REALM> with your organization’s realm. Use the endpoint shown for your organization.

Test the current ingest endpoint:

curl -v --connect-timeout 10 \
  https://ingest.<REALM>.observability.splunkcloud.com/v2/datapoint

Environments configured according to the migration playbook can use the legacy ingest endpoint:

curl -v --connect-timeout 10 \
  https://ingest.<REALM>.signalfx.com/v2/datapoint

Both endpoints are supported. For new configurations, use the observability.splunkcloud.com endpoint. For existing environments that follow the migration playbook, the signalfx.com endpoint remains supported.

Test the API endpoint:

curl -v --connect-timeout 10 \
  https://api.<REALM>.observability.splunkcloud.com/v2/

An HTTP response, such as 401 Unauthorized, confirms that the request reached the service. It does not validate an access token. Token validation occurs when you send a test metric later in this phase.

Verify TLS

Verify that the host can establish a TLS connection to the ingest endpoint:

openssl s_client \
  -connect ingest.<realm>.observability.splunkcloud.com:443 \
  -servername ingest.<realm>.observability.splunkcloud.com

Confirm that:

• The TLS handshake completes.
• The certificate chain is valid and trusted.
• The server name matches the certificate.
• Any approved TLS inspection device presents a certificate trusted by the host.

If your telemetry path uses OTLP over gRPC, also confirm that proxies, gateways, and security devices support HTTP/2 and gRPC traffic. A successful HTTPS request alone does not verify the complete gRPC path.

Resolve connectivity failures

Use the test result to identify the likely issue:

Work with your network or security team to resolve failures. Repeat the test from every affected network zone after applying a change.

Record the results

For each tested network path, record:

• Source host or network zone
• Destination endpoint
• Port and protocol
• Proxy or gateway, if used
• Test date and test owner
• Result
• Required firewall or proxy change
• Unresolved issue and assigned owner

Confirm readiness

Confirm that:

• [ ] You obtained required endpoints from the destination organization or current Splunk documentation.
• [ ] You tested connectivity from every network zone in the migration wave.
• [ ] DNS resolution and TLS validation succeeded.
• [ ] Required proxy, gateway, and firewall rules are in place.
• [ ] You confirmed HTTP/2 and gRPC support where you use OTLP over gRPC.
• [ ] You documented test results and approved network changes.
• [ ] You assigned owners to unresolved connectivity issues.
• [ ] No blocking connectivity issue remains.

After completing these checks, continue to Create Access Tokens.