Verify Ability to Upload to Pepperdata Dashboard (RPM/DEB)

If the Pepperdata dashboard does not show current data, it’s likely that pepcollectd—the Pepperdata Collector that uploads data from cluster hosts to the Pepperdata dashboard—cannot upload its data because it has been explicitly excluded from Pepperdata data collection or due to connection errors.

Task 1: Confirm that the Host is Configured for Pepperdata Data Collection

If the Pepperdata dashboard shows data for some hosts but not other hosts, a likely cause of “missing host data” is that the affected hosts have been disabled from Pepperdata data collection.


  • On an affected host, examine its /etc/pepperdata/ file to see what the value is for the PD_COLLECT_AND_UPLOAD environment variable.

    • If the value is 0, enable Pepperdata data collection for the host, as described in Disable/Enable Pepperdata Data Collection for a Host.

    • If the value is 1, Pepperdata should already be collecting data from this host, so continue troubleshooting by proceeding to the next step.

Task 2: Confirm Connectivity

After ensuring that the hosts is configured for Pepperdata data collection, confirm that the hosts can connect to the Pepperdata dashboard. Try to connect from a host to the Pepperdata dashboard using cURL with verbosity.


  • If there is direct access (no proxy server):

    curl --tlsv1.2 -v

  • If you are using a proxy server that you configured for Pepperdata (Set Up a Pepperdata Proxy):

    source /etc/pepperdata/
    curl --tlsv1.2 -v

If you can connect, you’ve confirmed that there is no connectivity problem, and you should contact Pepperdata Support for assistance.

Otherwise, debug the connection failure.

Task 3: Debug Connection Failures

A typical approach for debugging connection failures is to try using cURL to connect to the Pepperdata dashboard from a non-cluster host that is known to have internet access, whether directly or via a proxy that you set up during installation or according to the Set Up a Pepperdata Proxy procedure.

Use the same cURL command—based on your installation environment/cluster manager and the presence or not of a proxy server—that you used in Task 2: Confirm Connectivity.

Example: successful connection

curl --tlsv1.2 -v
* Rebuilt URL to:
*   Trying
* Connected to ( port 443 (#0)
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* successfully set certificate verify locations:
*   CAfile: /opt/local/share/curl/curl-ca-bundle.crt
  CApath: none
* TLSv1.2 (OUT), TLS header, Certificate Status (22):
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* NPN, negotiated HTTP1.1
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Client hello (1):
* TLSv1.2 (OUT), TLS handshake, Unknown (67):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS change cipher, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
* ALPN, server did not agree to a protocol
* Server certificate:
*      subject: OU=GT86417191; OU=See (c)15; OU=Domain Control Validated - RapidSSL(R); CN=*
*      start date: Sep 21 05:54:34 2015 GMT
*      expire date: Oct 22 04:31:09 2017 GMT
*      subjectAltName: matched
*      issuer: C=US; O=GeoTrust Inc.; CN=RapidSSL SHA256 CA - G3
*      SSL certificate verify ok.
> GET / HTTP/1.1
> Host:
> User-Agent: curl/7.45.0
> Accept: */*
< HTTP/1.1 200 OK
< Server: nginx/1.10.1
< Date: Mon, 24 Jul 2017 15:29:45 GMT
< Content-Type: text/html
< Content-Length: 4
< Last-Modified: Fri, 26 Aug 2016 23:29:38 GMT
< Connection: keep-alive
< ETag: "57c0d0e2-4"
< Accept-Ranges: bytes