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:
- Plugin name: n9pingdom
- Query delay environment variable: PINGDOM_QUERY_DELAY
- Query parameters retrieval: 0.73.2
- Timestamp cache persistence: 0.65.0
- Additional notes:
- Support for the uptime and transaction checks
- Learn more
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β
- Threshold (rawMetric)
- Ratio (countMetric) transaction
- Ratio (countMetric) uptime
apiVersion: n9/v1alpha
kind: SLO
metadata:
name: api-server-slo
displayName: API Server SLO
project: default
labels:
area:
- latency
- slow-check
env:
- prod
- dev
region:
- us
- eu
team:
- green
- sales
annotations:
area: latency
env: prod
region: us
team: sales
spec:
description: Example Pingdom SLO
indicator:
metricSource:
name: pingdom
project: default
kind: Agent
budgetingMethod: Occurrences
objectives:
- displayName: Good response (200)
value: 200
name: ok
target: 0.95
rawMetric:
query:
pingdom:
checkId: '1234567'
checkType: uptime
status: up
op: lte
primary: true
service: api-server
timeWindows:
- unit: Month
count: 1
isRolling: false
calendar:
startTime: 2022-12-01T00:00:00.000Z
timeZone: UTC
alertPolicies:
- fast-burn-5x-for-last-10m
attachments:
- url: https://docs.nobl9.com
displayName: Nobl9 Documentation
anomalyConfig:
noData:
alertMethods:
- name: slack-notification
project: default
apiVersion: n9/v1alpha
kind: SLO
metadata:
name: api-server-slo
displayName: API Server SLO
project: default
labels:
area:
- latency
- slow-check
env:
- prod
- dev
region:
- us
- eu
team:
- green
- sales
annotations:
area: latency
env: prod
region: us
team: sales
spec:
description: Example Pingdom SLO
indicator:
metricSource:
name: pingdom
project: default
kind: Agent
budgetingMethod: Occurrences
objectives:
- displayName: Good response (200)
value: 1
name: ok
target: 0.95
countMetrics:
incremental: true
good:
pingdom:
checkId: '1234567'
checkType: transaction
total:
pingdom:
checkId: '1234567'
checkType: transaction
primary: true
service: api-server
timeWindows:
- unit: Month
count: 1
isRolling: false
calendar:
startTime: 2022-12-01T00:00:00.000Z
timeZone: UTC
alertPolicies:
- fast-burn-5x-for-last-10m
attachments:
- url: https://docs.nobl9.com
displayName: Nobl9 Documentation
anomalyConfig:
noData:
alertMethods:
- name: slack-notification
project: default
- apiVersion: n9/v1alpha
kind: SLO
metadata:
name: api-server-slo
displayName: API Server SLO
project: default
labels:
area:
- latency
- slow-check
env:
- prod
- dev
region:
- us
- eu
team:
- green
- sales
annotations:
area: latency
env: prod
region: us
team: sales
spec:
description: Example Pingdom SLO
indicator:
metricSource:
name: pingdom
project: default
kind: Agent
budgetingMethod: Occurrences
objectives:
- displayName: Good response (200)
value: 1.0
name: ok
target: 0.95
countMetrics:
incremental: true
good:
pingdom:
checkId: "1234567"
checkType: uptime
status: up
total:
pingdom:
checkId: "1234567"
checkType: uptime
status: up,down
primary: true
service: api-server
timeWindows:
- unit: Month
count: 1
isRolling: false
calendar:
startTime: 2022-12-01 00:00:00
timeZone: UTC
alertPolicies:
- fast-burn-5x-for-last-10m
attachments:
- url: https://docs.nobl9.com
displayName: Nobl9 Documentation
anomalyConfig:
noData:
alertMethods:
- name: slack-notification
project: default
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."