
Pingdom Integration Manual
How to monitor your backup service status
1. Introduction
This whitepaper explains how to include system health check in external monitoring systems.
BackupAgent has decided to tailor its health check output towards Pingdom. However, the
output can also be loaded in various other monitoring systems (e.g. Foglight).
The health checks have been released as part of BackupAgent server 4.2.1.6588 or newer.
2. Health checks
This chapter explains how the health checks work and how they can be configured. A standard
set of health checks contains these tests:
Availability check of the web services
Database availability check
Check to see if all necessary Windows services are running
Benchmark test on network storage (default is write 500 KB in 100 ms)
2.1 HTTP Requests and responses
Health checks can be configured by sending http requests to the health URL of your
BackupAgent server installation.
Example: https://{yourservice.com}/health/check.ashx?profileid=1.
Normally, all servers in a load-balanced application setup would be able to respond to these
requests as they all resolve to the same licensed DNS. However, BackupAgent also supports
checks to IP addresses of separate machines. In this way the health of a certain server can be
checked.
1

If the health check succeeds, a HTTP response status 200 is sent back:
<pingdom_http_custom_check><status>OK</status><response_time>0.390625</response_time></pin
gdom_http_custom_check>
In case the health check fails, a HTTP response status 503 is sent back. Also, the 503 response
returns HMTL data on which test failed:
<html><body><ol><li><strong><label>StorageLocationsCheck_1013</label>:</strong>
<br/><label>Errors: </label><ol><li>The StorageLocationsCheck_1013 check did not succeed within
the timeout of:
100ms</li></ol></li><li><strong><label>StorageLocationsCheck_1017</label>:</strong>
SUCCESS</li><li><strong><label>DatabaseCheck</label>:</strong>
SUCCESS</li><li><strong><label>WebserviceCheck</label>:</strong>
SUCCESS</li><li><strong><label>WindowsServiceCheck</label>:</strong>
SUCCESS</li></ol></body></html>
2.2 How to configure various checks
Checks are profile-based. Each profile has a unique ID and can contain certain tests. Checks
become available by adding XML data to the web.config in C:\Program Files\BackupAgent
Provider\ManagementConsole\
The web.config must be extended with a new section. Place this as a line amongst other
sections:
<section name="CloudBackupHealthCheckSection"
type="ManagementConsole.Health.Configuration.CloudBackupHealthCheckSection,
ManagementConsole" />
The next step is to create a profile.Make sure the profile has a unique ID:
<CloudBackupHealthCheckSection activated="true">
<profiles>
<clear />
2

<profile id="1" enabled="true">
The name of the test in the report (in case of failure)
The benchmark timeout of the storage test
Checks all available locations or services (only available
for StorageLocation- andWindowsServiceCheck)
Checks only specific storage locations. The values are the IDs of the storage
locations. You can look these up by logging in to the Management Console
as administrator and navigating to Server Settings, tab Storage Locations.
These values are comma-separated lists which cannot contain a separating
space.
Checks only specific Windows Services. The available values are
‘BackupAgentMetadataManagementService,BackupAgentProcessingService,
BackupAgent Management Service, BackupAgentADService’. These values
are comma-separated lists which cannot contain a separating space.
Enables or disables a check
<checks>
<check type="StorageLocationsCheck" uniqueName="StorageLocationsCheck_1002"
checkAll="false" specificLocations="1015" timeOut="100" enabled="true"/>
<check type="DatabaseCheck" uniqueName="DatabaseCheck"/>
<check type="WebserviceCheck" uniqueName="WebserviceCheck"/>
<check type="WindowsServiceCheck" uniqueName="WindowsServiceCheck" checkAll="false"
specificServices="BackupAgentMetadataManagementService,BackupAgentProcessingService,BackupA
gent Management Service" />
</checks>
</profile>
</profiles>
</CloudBackupHealthCheckSection>
The above example is the default profile check, which checks all available tests and a single
storage location with ID 1002. Please note the following properties:
Note: the Clear tag in the xml is required to warrant that no previously configured tests remain
in memory after removal.
3