Known as “status” internally, Opserver provides a fast overall view of all our major systems that also allows drilling in for more detail. For an idea of the UI, you can see some screenshots from our Velocity 2013 talk.

Installation

Installation should be a snap, just build this project as-is and deploy it as an IIS website.
If monitoring windows servers and using integrated auth sections (e.g. live polling, SQL, exception logs) then using a service account with needed permissions is all you need to do on the auth side.
After that, configure Opserver to monitor your systems, keep reading for how.

Security Configuration

/Config/SecuritySettings.config contains the security settings for the Opserver website itself, there are a few built-in providers already:

Active Directory ("ad")

"Everyone's an admin" ("alladmin")

"View All" (the default)

There is a SecuritySettings.config.example as a reference. You can optionally add networks that can see the main dashboard without any authentication when using any provider. This is useful for fully automated screens like a TV in an office or data center.

Monitoring Configuration

The basic configuration implementation is via .json files, for which .json.example files are included in the /config directory of the Opserver project. These .example files are exactly what’s running in the Stack Exchange production environment, minus any passwords or internal-only URLs. You are also welcome to implement your own settings provider that has a completely different source, for example JSON from MongoDB, or SQL, or…whatever you can come up with. Settings changes will be hooked up to events but that isn’t complete just yet, since we build every change and Opserver restarts, this isn’t a priority.

We recommend using a service account with the necessary permissions for monitoring, this elimiates any passwords in your configuration files and makes management easier, that's the practice in place at Stack Exchange.

License

Props

We'd like to thank several people outside Stack Exchange for large contributions to Opserver's development.

Brent Ozar for lots of (continuing) help on the SQL monitoring, with some of the initial queries and help letting us know many use cases to cover. We'll be integrating some of the awesome tooling Brent and his team have to further assist DBAs and developers (like sp_Blitz, sp_BlitzIndex, and some you'll hear about soon).

Adam Machanic for sp_WhoIsActive, which powers the active tab for a SQL Instance. He also assisted with use cases and performance tuning on the use of sp_WhoIsActive.

The SQL Sentry guys, Aaron Bertrand and Kevin Kline for even more SQL use cases, and their help with upcoming integration with SQL Sentry. If you have SQL Sentry, Opserver will be providing historical data and some more dashboards using the data you already have from SQL Sentry, without increasing load to do the same monitoring twice.