Skip to main content

Pingdom

Reading time: 0 minute(s) (0 words)

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 Opens in a new tab

Creating SLOs with Pingdom​

Nobl9 Web​

Follow the instructions below to create an SLO based on a Threshold metric:

  1. Navigate to Service Level Objectives in the Nobl9 UI.
  2. Click .
  3. In step 1 of the SLO wizard, select the service the SLO will be associated with.
  4. In step 2, select Pingdom as the data source for your SLO, then specify the Metric.
  5. Select Threshold metric. This evaluates a single time series against a threshold.
  6. Enter the Uptime Check ID.
  7. For threshold metric, Nobl9 supports only Uptime check.

  8. 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.

    There is no default value in the Status field. If the Status check is not passed, it is omitted.

  9. In step 3, define a Time Window for the SLO.
  10. In step 4, specify the Error Budget Calculation Method and your Objective(s) .
  11. In step 5, add a Name, Description, and other details about your SLO. You can also select Alert policies and Labels on this screen.
  12. When you’ve finished, click Create SLO.
SLI values for good and total
When choosing the query for the ratio SLI (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​

Sample Pingdom threshold SLO with checkType: 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

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 a status value is not provided, the status 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."

For a more in-depth look, consult additional resources: