You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We have 17 PagerDuty services set up, and some of them can trigger hundreds of errors a day (most auto-resolve quickly). Editor's note: I could get into the folly of using PagerDuty as a log stashing replacement, but I digress. The API can only match on incidents that appear on the first page of a list of incidents, and it can only retrieve a maximum of 100 incidents at a time. We have two or three of those services that actually trigger critical errors, and those are the ones we want to monitor and interact with.
I propose adding a new optional constant, HUBOT_PAGERDUTY_SERVICES, that is a comma-delimited string of service IDs to include. If not set, the default behavior of searching all services persists. If it is set, the service ID string is passed on as part of the relevant request parameters for the API endpoint.
The text was updated successfully, but these errors were encountered:
Another idea I might suggest is #9 , which would exclude things not assigned to you. If those other services you mentioned aren't triggering alerts assigned to you, then you wouldn't see them.
Fixeshubot-archive#31
Our PagerDuty instance has numerous services that receive alerts, but we only want our Hubot to query against a subset of those. This adds a `HUBOT_PAGERDUTY_SERVICES` environment variable that accepts a comma separated list of service identifiers. This list is then added as a `service` key on all of the `pagerDutyGet` method calls to apply that filter.
We have 17 PagerDuty services set up, and some of them can trigger hundreds of errors a day (most auto-resolve quickly). Editor's note: I could get into the folly of using PagerDuty as a log stashing replacement, but I digress. The API can only match on incidents that appear on the first page of a list of incidents, and it can only retrieve a maximum of 100 incidents at a time. We have two or three of those services that actually trigger critical errors, and those are the ones we want to monitor and interact with.
I propose adding a new optional constant,
HUBOT_PAGERDUTY_SERVICES
, that is a comma-delimited string of service IDs to include. If not set, the default behavior of searching all services persists. If it is set, the service ID string is passed on as part of the relevant request parameters for the API endpoint.The text was updated successfully, but these errors were encountered: