Grabs services from PagerDuty, groups them, and then highlights issues. For details on the grouping process, refer to the "Conventions" section below.
Running the gondek/pagerduty-dashboard docker image starts the dashboard with the mock data. For deployment, you will have to copy in your API information. You could use a Dockerfile like this (where config.json contains the API information):
FROM gondek/pagerduty-dashboard
ADD ./config.json /opt/pagerduty-dashboard/
- Install Node.js and Gulp
- Copy
config.sample.jsontoconfig.json, enter your API information, and change "mock" tofalse. - Install dependencies:
npm install - Build the front-end/client:
gulp - Start the back-end/server:
node app.js
You can then access the page at localhost:3000 (or at whatever port was configured).
During development, running gulp dev will restart the server and/or run builds when files change.
To use the sample data, set "mock" to true to config.json.
To configure how the dashboard functions, go to localhost:3000/#/customize and note down the generated URL.
These rules determine how the dashboard processes and displays data.
A service that contains [dashboard-primary] anywhere in its description is a core service. Core services get separated into core groups. The remaining services get put into the "Other" group.
Core groups are generated from the core services. A colon acts as a separator between the group and service within the service name (eg. <group>: <service>). In the interface, these services are labeled as "features". Features with names of <group>: Site or <group>: Server get separated and enlarged.
Core groups can have dependencies, which are specified in their services. To specify a dependency, add [dashboard-depends|Some Service,Dependency.*] to the service's description. Each comma-delimited entry can be a service name (Some Service) or a regular expression (Dependency.*). Dependencies of dependencies do not get added (i.e. dependencies are only followed to a depth of 1). In the interface, these dependencies are labeled as "services".
A core group's status is only determined from its features (main services) and not its dependencies.
If one or more services within the other group are failing, the group gets broken up into two pieces, one holding the offline/failing services and the other holding the online/okay services.
- Play sound on status change (or other event)
- Display assigned users of failing services/features
- Dependencies: Allow dependency chains of more than depth 1. Dependency failures trickle up the chain:
- Immediate (distance 1) dependency failures give the dependent a status of
dependency-down(a status worse than active and better than warning) - Upstream (distance >1) dependency failures give the dependent a status of
dependency-degraded(a status worse than active and better thandependency-down) - The new mapping of status numbers would be: ..., active=2, dependency-degraded=3, dependency-down=4, warning=5, ...
- The two new statuses could have special colors or other ui changes (exclamation or question marks).
- Immediate (distance 1) dependency failures give the dependent a status of
- Spin-off project: False-positive analysis and dampen issues from services that tend to fix themselves