Quick Start

You can suppress alerts that meet a defined query with the Plans API. A time window for when the suppression will start and end can be defined by the addition of a Schedule. This guide will walk through the steps to create a maintenance plan based on an example scenario.

Relevant Permissions

Roles with the following permissions can access the Maintenance Plans section, the Plans V1 API and the Maintenance Plans V2 API:

PermissionDescription
Plans_ReadRead-only - view the Maintenance Plans section, the Plans V1 API and the Maintenance Plans V2 API.
Plans_Full_AccessFull access - view and interact with the Maintenance Plans section and use the Plans V1 API and the Maintenance Plans V2 API to configure maintenance plans. Use the Schedules API to define the specific start and end times of Plans configured with the Plans V1 API.

Use these Read and Full permissions for both the Plans V1 API and the Maintenance Plans V2 API.

To learn more about how BigPanda's permissions work, see the Roles Management guide.

Step 1: Define The Schedule

As an example scenario, suppose that a company's servers and devices under its San Jose host are undergoing upgrades and will yield false alerts from procedural reboots and state changes. The associated monitoring tools will inevitably see these changes as alerts and stream them into BigPanda. To prevent the cluttering of workflow, you would create a plan to capture the relevant devices under the San Jose host and suppress their alerts and a schedule to capture the timeframe of the maintenance period.

Start by creating a schedule to define the specific start and end timeframe:

  1. Send a POST request to /schedules.
  • The start and end parameters follow the Unix epoch format.
  • For more information, see Create a Schedule
curl -iX POST https://api.bigpanda.io/resources/v1.0/schedules \
  -H "Content-Type: application/json; charset=utf-8" \
  -H "Accept: application/json" \
  -H "Authorization: Bearer $(token)" \
  -d '{
    "name": "San Jose Host Maintenance Schedule",
    "starts_on": 1491265491,
    "ends_on": 1491294307,
    "active": true
  }'

❗️

Be sure to replace ${token} with the corresponding value for your organization.

  1. Copy the id value from the response body.
    You will use it as a parameter when creating a plan in the next step.

Step 2: Define The Plan With Schedule

Create a plan to isolate the suppression of alerts to only the devices affected during the maintenance period - the San Jose host. See the Plans Object page for more information on the Plan Objects

❗️

Schedule ID

The schedule ID is needed to add a schedule to a plan or filter.

👍

Filter ID

Plan ID for Alert Filters can be extracted from the URL of the filter in the BigPanda UI.

To define a new plan:

  1. Send a POST request to /plans.
  • Specify the name of the plan.
  • Specify the schedule to associate with the plan. The id value is copied from Step 1.
  • Specify the bpql object to query. In this case, we want to filter "San Jose" hosts to capture the relevant devices.
  • Specify the active parameter to true to enable the plan.
  • For more information, see Create a Plan
curl -iX POST https://api.bigpanda.io/resources/v1.0/plans \
  -H "Content-Type: application/json; charset=utf-8" \
  -H "Accept: application/json" \
  -H "Authorization: Bearer $(token)" \
  -d '{
        "name": "San Jose Maintenance Plan",
        "schedule": "590b72b91f0000130063753c"
        "bpql": {"=": ["host", "prod-san-jose"]},
        "active": true
  }'

❗️

This mapping schema is defined for a hypothetical sample environment. You can adapt the values as necessary to meet your infrastructure conventions and the needs of your teams.

Like in Step 1, be sure to replace ${token} with the corresponding value for your organization.

  1. (Recommended) Send test alerts from the San Jose host and ensure that they are suppressed and the plan works as expected.

🚧

Plan Limit

Each organization can only have 3,500 V1 maintenance plans (also called alert filters).

🚧

Condition Limitations

Maintenance plan conditions cannot be longer than 25,000 characters long.

All alert tags in maintenance plan conditions must be listed in lowercase, regardless of the tag's system case.

The condition body parameter uses special BPQL object formatting. See BPQL Object Syntax for more information.