Skip to main content
System monitoring helps ensure that your environment remains stable and available. This section describes the supported methods for monitoring at the server level. Administrators can use the following approaches to monitor the health of the system.
  • Monitoring the healthcheck endpoint
  • Reviewing server logs

​
Monitoring CData Sync with the Healthcheck Endpoint

exposes a healthcheck endpoint (http://YourHostName:8181/pub/ping.rst) that you can use to monitor your server and ensure that it is running. In this endpoint:
  • YourHostName is the host name or IP address of your server.
  • Port 8181 is the default web-server port. If you use a custom port, update the URL accordingly.
You can test the endpoint with a command similar to this cURL command: curl YourHostName:8181/pub/ping.rst
While this example uses the cURL command-line tool, you can use other tools (for example, the Wget command-line tool or your monitoring system) to test the endpoint.

​
Readiness Check

Unlike a simple ping, this endpoint performs a full readiness check. By default, once every 60 seconds it verifies the following information:
  • The application data directory is readable and writable.
  • The application database can be queried.
  • The user directory can be loaded.

​
Response Codes

The outcome of these checks is reflected by the response code that is returned:
  • 200 OK: The server is running and all readiness checks succeeded.
  • Response body: OK
  • 500 Internal Server Error: The server process is running, but one or more readiness checks failed (for example, issues with the file system, database, or user manager).
  • No response / connection error: The server is stopped or unreachable.
Examples: If all readiness checks succeed, the request returns the message OK. Successful healthcheck response If the server is stopped or unreachable, your monitoring tool might show a connection error similar to this message: Connection error response

​
Monitoring CData Sync with Logs

writes server activity logs to this directory: ApplicationDirectory/logs/httpserver.
The ApplicationDirectory location varies by operating system and deployment. For more details, see Configuring the Application Directory.
You can open these logs directly for troubleshooting or configure a log forwarder to integrate with external monitoring tools. For example, you might integrate these logs with a third-party monitoring platform such as Datadog. (You can use other third-party monitoring tools besides Datadog, as well.) With Datadog, you can use the Datadog Agent to collect and forward logs for centralized monitoring. The basic process is as follows:
  • Collect logs from the httpserver directory.
  • Use the Datadog Agent to ship the logs to Datadog.
  • Configure dashboards and alerts in Datadog to track errors or downtime.
For a detailed explanation of these steps, see Seamless Monitoring Between CData and Datadog.