Pingdom
Pingdom is a website monitoring solution that gives users real-time, quality insights into the uptime and performance of their websites. After adding Pingdom as a data source in Nobl9, users can configure SLOs to check the overall performance status of their sites. Leveraging Pingdom, users can build SLOs on top of their existing metrics data.
Pingdom parameters and supported features in Nobl9
- General support:
- Release channel: Stable, Beta
- Connection method: Agent, Direct
- Replay and SLI Analyzer: Not supported
- Event logs: Supported
- Query checker: Not supported
- Query parameters retrieval: Supported
- Timestamp cache persistence: Supported
- Query parameters:
- Query interval: 1 min
- Query delay: 1 min
- Jitter: 15 sec
- Timeout: 30 sec
- Agent details and minimum required versions for supported features:
- Environment variable:
PINGDOM_QUERY_DELAY
- Plugin name:
n9pingdom
- Query parameters retrieval:
0.73.2
- Timestamp cache persistence:
0.65.0
- Additional notes:
- Support for the uptime and transaction checks
- Learn more
Authentication
Pingdom’s API uses basic authentication and a bearer token. Users can retrieve the token from the Pingdom UI (My Pingdom) and pass it to Nobl9.
To create a Pingdom API token if you don’t already have one, follow these steps:
-
Navigate to My Pingdom.
-
Log in to your customer account.
-
Go to Settings > Synthetic & RUM Settings > Pingdom API:
-
Click Add API token, then Generate token (read access is enough for this integration):
Adding Pingdom as a data source
You can add the Pingdom data source using the direct or agent connection methods.
Direct connection method
A direct connection to Pingdom requires users to enter their credentials, which Nobl9 stores safely.
Nobl9 Web
Follow these steps to set up this type of connection:
- Navigate to Integrations > Sources.
- Click .
- Click the required Source button.
- Choose Direct.
-
Select one of the following Release Channels:
- The
stable
channel is fully tested by the Nobl9 team. It represents the final product; however, this channel does not contain all the new features of abeta
release. Use it to avoid crashes and other limitations. - The
beta
channel is under active development. Here, you can check out new features and improvements without the risk of affecting any viable SLOs. Remember that features in this channel can change.
- The
-
Enter your API Token (mandatory).
You can find this in My Pingdom, under Synthetic & RUM Settings > Pingdom API. Details on creating a Pingdom API token were provided in the Authentication section above.
- Select a Project.
Specifying a project is helpful when multiple users are spread across multiple teams or projects. When the Project field is left blank, Nobl9 uses thedefault
project. - Enter a Display Name.
You can enter a user-friendly name with spaces in this field. - Enter a Name.
The name is mandatory and can only contain lowercase, alphanumeric characters, and dashes (for example,my-project-1
). Nobl9 duplicates the display name here, transforming it into the supported format, but you can edit the result. - Enter a Description.
Here you can add details such as who is responsible for the integration (team/owner) and the purpose of creating it. - Specify the Query delay to set a customized delay for queries when pulling the data from the data source.
- The default value in Pingdom integration for Query delay is
1 minute
.
infoChanging the Query delay may affect your SLI data. For more details, check the Query delay documentation. - The default value in Pingdom integration for Query delay is
- Click Add Data Source
sloctl
The YAML for setting up a direct connection to Pingdom looks like this:
apiVersion: n9/v1alpha
kind: Direct
metadata:
displayName: Pingdom Direct
name: pingdom-direct
project: pingdom-direct
spec:
description: Direct integration with Pingdom
sourceOf:
- Metrics
releaseChannel: stable
queryDelay:
unit: Minute
value: 720
logCollectionEnabled: false # boolean, defaults to 'false'. Set to true if you'd like your source to collect logs. Available for data sources connected using the direct method only. Reach out to support@nobl9.com to activate it.
pingdom:
apiToken: ""
Field | Type | Description |
---|---|---|
queryDelay.unit mandatory | enum | Specifies the unit for the query delay. Possible values: Second | Minute . • Check query delay documentation for default unit of query delay for each source. |
queryDelay.value mandatory | numeric | Specifies the value for the query delay. • Must be a number less than 1440 minutes (24 hours). • Check query delay documentation for default unit of query delay for each source. |
logCollectionEnabled optional | boolean | Optional. Defaults to false . Set to true if you'd like your direct to collect event logs. Contact us to activate it. |
releaseChannel mandatory | enum | Specifies the release channel. Accepted values: beta | stable . |
Source-specific fields | ||
pingdom.apiToken mandatory | string, secret | Pingdom’s API uses basic authentication and a bearer token. You can retrieve the token from the Pingdom UI (My Pingdom) and pass it to Nobl9. See authentication section above for more details. |
Agent connection method
Nobl9 Web
Follow the instructions below to set up an agent configuration.
- Navigate to Integrations > Sources.
- Click .
- Click the required Source button.
- Choose Agent.
-
Select one of the following Release Channels:
- The
stable
channel is fully tested by the Nobl9 team. It represents the final product; however, this channel does not contain all the new features of abeta
release. Use it to avoid crashes and other limitations. - The
beta
channel is under active development. Here, you can check out new features and improvements without the risk of affecting any viable SLOs. Remember that features in this channel can change.
- The
- Select a Project.
Specifying a project is helpful when multiple users are spread across multiple teams or projects. When the Project field is left blank, Nobl9 uses thedefault
project. - Enter a Display Name.
You can enter a user-friendly name with spaces in this field. - Enter a Name.
The name is mandatory and can only contain lowercase, alphanumeric characters, and dashes (for example,my-project-1
). Nobl9 duplicates the display name here, transforming it into the supported format, but you can edit the result. - Enter a Description.
Here you can add details such as who is responsible for the integration (team/owner) and the purpose of creating it. - Specify the Query delay to set a customized delay for queries when pulling the data from the data source.
- The default value in Pingdom integration for Query delay is
1 minute
.
infoChanging the Query delay may affect your SLI data. For more details, check the Query delay documentation. - The default value in Pingdom integration for Query delay is
- Click Add Data Source
sloctl
The YAML for setting up an agent connection to Pingdom looks like this:
apiVersion: n9/v1alpha
kind: Agent
metadata:
name: my-pingdom-agent
displayName: My Pingdom agent
project: my-project
spec:
sourceOf:
- Metrics
- Services
releaseChannel: stable
queryDelay:
unit: Minute
value: 720
pingdom: {}
Field | Type | Description |
---|---|---|
queryDelay.unit mandatory | enum | Specifies the unit for the query delay. Possible values: Second | Minute . • Check query delay documentation for default unit of query delay for each source. |
queryDelay.value mandatory | numeric | Specifies the value for the query delay. • Must be a number less than 1440 minutes (24 hours). • Check query delay documentation for default unit of query delay for each source. |
releaseChannel mandatory | enum | Specifies the release channel. Accepted values: beta | stable . |
You can deploy only one agent in one YAML file by using the sloctl apply
command.
Agent deployment
When you add the data source, Nobl9 automatically generates a Kubernetes configuration and a Docker command line for you to use to deploy the agent. Both of these are available in the Web UI, under the Agent Configuration section. Be sure to swap in your credentials (e.g., replace <PINGDOM_API_TOKEN>
with your organization API Token).
- Kubernetes
- Docker
If you use Kubernetes, you can apply the supplied YAML config file to a Kubernetes cluster to deploy the agent. It will look something like this:
# DISCLAIMER: This deployment description contains only the fields necessary for the purpose of this demo.
# It is not a ready-to-apply k8s deployment description, and the client_id and client_secret are only exemplary values.
kind: Secret
metadata:
name: nobl9-agent-nobl9-dev-prometheus-week-promtom
namespace: default
type: Opaque
stringData:
pingdom_api_token: "<PINGDOM_API_TOKEN>"
client_id: "unique_client_id"
client_secret: "unnique_client_secret"
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: nobl9-agent-nobl9-dev-pingdom-pingdom-test
namespace: default
spec:
replicas: 1
selector:
matchLabels:
nobl9-agent-name: "pingdom-test"
nobl9-agent-project: "pingdom"
nobl9-agent-organization: "nobl9-dev"
template:
metadata:
labels:
nobl9-agent-name: "pingdom-test"
nobl9-agent-project: "pingdom"
nobl9-agent-organization: "nobl9-dev"
spec:
containers:
- name: agent-container
image: nobl9/agent:0.82.2
resources:
requests:
memory: "350Mi"
cpu: "0.1"
env:
- name: N9_CLIENT_ID
valueFrom:
secretKeyRef:
key: client_id
name: nobl9-agent-nobl9-dev-pingdom-pingdom-test
- name: N9_CLIENT_SECRET
valueFrom:
secretKeyRef:
key: client_secret
name: nobl9-agent-nobl9-dev-pingdom-pingdom-test
- name: PINGDOM_API_TOKEN
valueFrom:
secretKeyRef:
key: pingdom_api_token
name: nobl9-agent-nobl9-dev-pingdom-pingdom-test
# The N9_METRICS_PORT is a variable specifying the port to which the /metrics and /health endpoints are exposed.
# The 9090 is the default value and can be changed.
# If you don’t want the metrics to be exposed, comment out or delete the N9_METRICS_PORT variable.
- name: N9_METRICS_PORT
value: "9090"
If you use Docker, you can run the supplied Docker command to deploy the agent. It will look something like this:
# DISCLAIMER: This Docker command contains only the fields necessary for the purpose of this demo.
# It is not a ready-to-apply command, and you will need to replace the placeholder values with your own values.
docker run -d --restart on-failure \
--name nobl9-agent-nobl9-dev-pingdom-project \
-e N9_CLIENT_ID="unique_client_id" \
-e N9_CLIENT_SECRET="unique_client_secret" \
# The N9_METRICS_PORT is a variable specifying the port to which the /metrics and /health endpoints are exposed.
# The 9090 is the default value and can be changed.
# If you don’t want the metrics to be exposed, comment out or delete the N9_METRICS_PORT variable.
-e N9_METRICS_PORT=9090 \
-e PINGDOM_API_TOKEN="<PINGDOM_API_TOKEN>" \
nobl9/agent:0.82.2
Creating SLOs with Pingdom
Nobl9 Web
- Threshold
- Ratio
Follow the instructions below to create an SLO based on a Threshold metric:
- Navigate to Service Level Objectives in the Nobl9 UI.
- Click .
- In step 1 of the SLO wizard, select the service the SLO will be associated with.
- In step 2, select Pingdom as the data source for your SLO, then specify the Metric.
- Select Threshold metric. This evaluates a single time series against a threshold.
- Enter the Uptime Check ID.
- In the Pingdom UI, navigate to Synthetics > Uptime, click the site name, and copy the ID at the end of the URL displayed in your browser's address bar. For more information, see How to set up an uptime (HTTP) check? | Pingdom Documentation.
- Select a Status.
- This field is optional; you can narrow it down by choosing one or more of the following values:
up
,down
,unconfirmed
,unknown
. - In step 3, define a Time Window for the SLO.
- In step 4, specify the Error Budget Calculation Method and your Objective(s) .
- In step 5, add a Name, Description, and other details about your SLO. You can also select Alert policies and Labels on this screen.
- When you’ve finished, click Create SLO.
For threshold metric, Nobl9 supports only Uptime check.
There is no default value in the Status field. If the Status check is not passed, it is omitted.
Follow the instructions below to create an SLO based on a Ratio metric:
- Navigate to Service Level Objectives in the Nobl9 UI.
- Click .
- In step 1 of the SLO wizard, select the Service the SLO will be associated with.
- In step 2, select Pingdom as the Data Source for your SLO, then specify the Metric.
- Select Ratio Metric. This allows you to enter two time series to compare (for example, a count of good requests and total requests).
- Choose the Data Count Method:
- Non-incremental: counts incoming metric values one-by-one. So the resulting SLO graph is pike-shaped.
- Incremental: counts the incoming metric values incrementally, adding every next value to previous values. It results in a constantly increasing SLO graph.
- Define parameters separately for the Good metric and Total metric:
- Select the proper Check type from the dropdown list: Uptime or Transaction.
- Enter the Transaction or Uptime Check ID. This must be the same for both the good and total metrics.
- Select a Status. This field is mandatory and visible for the Uptime check metric type only: The default value for the good metric is
up
.
The default value for the total metric is all the supported values:up
,down
,unconfirmed
,unknown
- In step 3, define a Time Window for the SLO.
- In step 4, specify the Error Budget Calculation Method and your Objective(s) .
- In step 5, add a Name, Description, and other details about your SLO. You can also select Alert policies and Labels on this screen.
- When you’ve finished, click Create SLO.
Use a Transaction check to test simple or complex transactions, such as new user registrations, user login, search, shopping cart checkout, URL hijacking, etc
For more information, refer to the Synthetic Monitoring | Pingdom Documentation.
countMetrics
), keep in mind that the values resulting from that query for both good and total:- Must be positive.
- While we recommend using integers, fractions are also acceptable.
- If using fractions, we recommend them to be larger than
1e-4
=0.0001
. - Shouldn't be larger than
1e+20
.
sloctl
- rawMetric
- countMetric
- countMetric - uptime
Here’s an example of a Pingdom SLO using rawMetric
(threshold metric) with checkType=uptime
:
apiVersion: n9/v1alpha
kind: SLO
metadata:
name: pingdom-uptime
project: pingdom-direct
spec:
alertPolicies: []
budgetingMethod: Occurrences
description: ""
indicator:
metricSource:
kind: Direct
name: pingdom-direct-source
project: pingdom-direct
objectives:
- displayName: good
op: lt
rawMetric:
query:
pingdom:
checkId: "1234567"
checkType: "uptime"
status: "up"
target: 0.99
value: 1200
- displayName: bad
op: lt
rawMetric:
query:
pingdom:
checkId: "1234567"
checkType: "uptime"
status: "up"
target: 0.99
value: 1000
service: pingdom-direct-service
timeWindows:
- count: 1
Here’s an example of a Pingdom SLO using countMetrics
(ratio metric) with checkType=transaction
:
1 apiVersion: n9/v1alpha
2 kind: SLO
3 metadata:
4 name: pingdom-transaction-occurrences-calendar-aligned-1646061551
5 project: pingdom
6 spec:
7 alertPolicies: []
8 budgetingMethod: Occurrences
9 description: ""
10 indicator:
11 metricSource:
12 kind: Agent
13 name: pingdom
14 project: pingdom
15 objectives:
16 - countMetrics:
17 good:
18 pingdom:
19 checkId: "119581"
20 checkType: "transaction"
21 incremental: false
22 total:
23 pingdom:
24 checkId: "119581"
25 checkType: "transaction"
26 displayName: good
27 target: 0.9896
28 value: 1
29 service: pingdom-service
30 timeWindows:
31 - calendar:
32 startTime: "2022-02-27 00:00:00"
33 timeZone: UTC
34 count: 1
35 isRolling: false
36 period:
37 begin: "2022-03-15T00:00:00Z"
38 end: "2022-03-16T00:00:00Z"
39 unit: Day
Here’s an example of a Pingdom SLO using countMetrics
(ratio metric) with checkType=uptime
:
apiVersion: n9/v1alpha
kind: SLO
metadata:
name: my-pingdom-check-count-metrics
project: pingdom-test
spec:
description: Example of Pingdom count metrics query
service: pingdom-service
indicator:
metricSource:
kind: Agent
name: pingdom
project: pingdom-test
timeWindows:
- unit: Day
count: 28
isRolling: true
budgetingMethod: Occurrences
objectives:
- displayName: Good
value: 1
target: 0.99
countMetrics:
incremental: false
good:
pingdom:
checkId: 8745322
status: up
total:
pingdom:
checkId: 8745322
status: up,down
Important notes:
-
rawMetric
gathers only the average response time from a Pingdom uptime check. -
checkID
is the Pingdom uptime or transaction check's ID. -
status
is optional for the Uptime checks. Use it to filter the Pingdom check results by status (CSV format). If astatus
value is not provided, thestatus
field will gather all available results regardless of their statuses. Since only successful responses have a response time value, using other values than up with rawMetrics is not recommended.
Querying the Pingdom server
Nobl9 calls the Results REST API Endpoint | Pingdom documentation to get the Uptime results, meaning the response time and the status of a website. The API calls to Pingdom are made every 60 seconds and retrieve data from the previous 60 seconds.
For Transaction checks, Nobl9 calls the getCheckReportStatus API Endpoint | Pingdom documentation to get a list of status changes for a specified check. The API calls to Pingdom are made every 60 seconds and retrieve data from the previous 60 seconds.
Fetching the results of a transaction check is delayed up to the time value the user has defined in the interval in the Pingdom UI (My Pingdom). Nobl9 can only get the results for checks that have already been performed. For example, if the interval is set to 5 minutes, the query delay is 5 minutes. The longer the interval is, the greater is the query delay. It is recommended to set the interval to 5 minutes.
Pingdom API rate limits
The Pingdom API has usage limits to avoid individual rampant applications degrading the overall user experience. There are two layers of limitations, short and long period:
- Req-Limit-Short
- Req-Limit-Long
There are two HTTP headers in every response describing your limits status. Here are examples of these values:
- Req-Limit-Short: Remaining: 394 Time until reset: 3589
- Req-Limit-Long: Remaining: 71994 Time until reset: 2591989
In this example, the user has 394 requests left until the short limit is reached; it will be reset in 3589 seconds. Similarly, the long limit has 71994 requests left and will be reset in 2591989 seconds. If limits are exceeded, an HTTP 429 error code with the following message is displayed: "Request limit exceeded, try again later."