Blog Post

Visualizing NOC Operations with GroundWork NOC Boards


September 14, 2020

Single Source of Truth

A monitoring system is a shared tool. It’s useful for teams to operate from the same source of information, since subjective opinions can lead insights astray, especially when troubleshooting systems and network issues. You need a single source of truth. 

A monitoring dashboard with drill-down capability is a basic tool for any NOC staff. Often displayed on kiosks or wall-mounted in the Network Operations Center (NOC), dashboards let you know at a glance whether anything needs attention. 

A generalized and flexible dashboard may not fit the bill, however.

Often there is simply too much information displayed to allow for a specific alert to gain focus and be integrated into the incident response process. Ticketing systems with customized workflows can help, but modern ticketing systems are often complex, and can even slow down response time with cumbersome requirements. In the thick of things, you need to know that you are working on the most important items, and only those items.

Introducing GroundWork NOC Board Dashboards

GroundWork Monitor supports role-based access (RBAC), which serves to make general dashboards far more targeted, and display only the monitored resources accessible to a given user, based on their area of responsibility. This works well, as long as the user is reasonably well versed in manipulating the dashboard to further filter and expose the items of concern. For ad-hoc troubleshooting or investigation, it’s essential. However, it is still not enough to support intuitive adherence to process.

That’s where you need NOC Boards. 

NOC Boards provide views of specific groups in GroundWork Monitor. These are groups of hosts (host groups), groups of specific services on specific hosts (service groups), and custom groups, that is, nested groups of either host groups or service groups.  

Organizing your monitored resources into groups is a good thing. If you organize all the database monitoring, for example, into a single service group, you can expose this to the DBA support staff in the monitoring system. Groups can be dynamic, which with cloud services is an essential feature. With dynamic membership, you don’t necessarily need to maintain the group in detail, only the tags and rules that govern it. Once you have set up this level of organization, you can use NOC Boards to show the users just the problems that exist in that group.

In the image below we show the NOC Board named Global Oracle Status which has been configured to display the service group OracleStatus services, all states for the last 24 hours, both in downtime and not in downtime over the last 2 hour period, both acknowledged and not acknowledged services, and the SLA status based on the contractural percentage.

GroundWork NOC Boards

You could even show, on one display, the acknowledged and unacknowledged issues in separate lists. If it makes sense within your team, you can spilt them off and give one group access, using RBAC, to the unacknowledged issues (dispatch, for example, or triage) and another the acknowledged issues, for longer term tasks like backup/restore or database recovery.

NOC Boards are editable and customizable by users with the Admin role. They are read only for other users, and do allow for anyone to acknowledge issues, drill down to more detailed displays, or leave comments behind for other team members. 

Using the GroundWork Menu Editor feature, you can create specific pages to be displayed as top-level or sub-level menu items, with specific combinations of NOC Boards for particular groups. 

NOC Boards Value

What does all of this provide to you?

  • Clear visualization of incidents in progress
  • Lists of issues that are new vs those that are in the process of being resolved
  • Lists of items in maintenance

All of which allow you to design your response workflow with simple and flexible visualizations, and this is especially important when dealing with large and dynamic infrastructures.

An Example

To continue with the idea of your DBA team, imagine you have set up a servicegroup of Oracle servers with availability and performance checks:

GroundWork NOC Boards

These are then added to a NOC Board and set to show any unacknowledged issues:
 

A second NOC Board is devised to show only acknowledged issues:

GroundWork NOC Boards

Now, a menu item is added that points to the two boards together, restricted to DBA role:

GroundWork NOC Boards

The resulting page is accessible to users with the DBA role. The board with the unacknowledged items can be set to auto-expand, giving an indication of open issues visible from across the room:

GroundWork NOC Boards

Now it’s not hard to see when you need to take action and repair a failure detected by the monitoring system. Nor, is it hard to see what’s being worked on (which is displayed on the second list). 

In Summary

There are many more uses for the NOC Boards, and they can be customized to show only specific columns in a specific order, or to give you a heads up when an SLA you set is not being met. These simple yet powerful presentation techniques make GroundWork Monitor an effective shared tool, and a source of objective truth when troubleshooting.

See our support portal GroundWork Support at www.support8.gwos.com for NOC Board how to’s and use cases.

Thanks for reading our Blog.
GroundWork Open Source

Other Posts...

GroundWork Monitor 8.1.1 released!


GroundWork Open Source Releases Major Update to GroundWork Monitor Enterprise


GroundWork Monitor Enterprise 8.1.1 includes distributed monitoring and enhanced
connection technology for multiple data sources.

Read More

Mitigating Alarm Storms in GroundWork Monitor

Mitigating Alarm Storms using GroundWork MonitorGroundWork Monitor offers Parent Child configurations for distributed monitoring, enabling the monitoring of a subset of an infrastructure where Child servers report the state and performance metrics to a central, or “Parent” GroundWork server.

What this Blog post is focused on is not a Parent Child architecture configuration, but instead the other kind of Parent Child: the relationships and inherent dependencies that can be configured to control the behavior of hosts and services based on the status of one of more other hosts and services.
Read More