What is the Enterprise Operations Console (EOC) & how does it work?

When I talk with a customer and get the question, “how does Orion scale?” My answer is the customer can choose one of two ways to scale.

  1. By adding Orion Additional Pollers to scale horizontally
  2. By deploying multiple Orion instances and rolling up into the Enterprise Operations Console

In this post, we are going to discuss the Enterprise Operations Console or EOC for short.  EOC’s main functionality is to aggregate data from multiple Orion server installations and to display it in a similar fashion as the Orion Web Console.

Take the below first graphic, you have a worldwide network with teams responsible for managing their respective geographies, so an Orion installation resides in each North America, EMEA and APAC.  The global NOC and Management Team requires a single rollup of all servers into a single installation for status, alerting, reporting etc.

Orion EOC aggregates the current status of your Orion NPM servers and presents this data in the Orion EOC Web Console. Administrators can restrict what Orion NPM data each Orion EOC user is permitted to see. These restrictions can be set on an individual basis by customizing user settings and on a group basis by defining roles.

image_thumb_3D4D97E4.png

In the EOC web console, here is what you would see as illustrated in the second screenshot below.  One of the common misconceptions about EOC is that it pulls all the data from each of your Orion servers into the EOC database.  In actuality, EOC pulls high level information like current status, alerts, events, syslog and traps.  Any data beyond that, when you click on that item in the web console, you are seamless redirected behind the scenes to the Orion server that item resides on.  Let’s walk through an example.

  1. Looking at my EOC dashboard I see that under the “Global Nodes with Problems” resource, that Switch sales is down.
  2. I click on switch sales and am automatically redirected to the node details page for device Switch sales and logged into the Orion server Orion America as that is where that node resides for monitoring

I can now perform my investigation and go right back to my global EOC dashboard.

EOC.jpg

Now that we have gone through a high level of what EOC is an example use case, let’s get in deeper on how it works.  I have taken my first image from above, but broken it down to a “how it works” level.  EOC is comprised of 4 main components:

  1. Orion Poller
  2. Information Service
  3. Website
  4. Database.

image_thumb_7447761D.png

EOC pulls the following type of data through the Orion Information Service:

  • Alerts, Events, Syslog, Traps (last 24 hours worth of data)
  • Node, Volume, and Interface data (no historical data)
  • APM data (no historical data)
  • NetFlow (no historical data)
  • IPSLA Manager (no historical data)
  • Wireless (no historical data)
  • NCM (no historical data)
  • UDT (no historical data)
  • IPAM (no historical data)
  • Support for displaying Orion Groups

The Information Service (IS) module will exist in both EOC and Orion products. The service will provide a single point of communication and a simple and efficient mechanism to query the servers.  All communication with the IS module is encrypted using SSL and is on port 17777.

The Communication module uses Windows Communication Foundation (WCF) as the basis of its communication mechanism which allows other applications, websites, scripts, and application modules to seamlessly communicate with it. WCF also provides secure, reliable, and several transport and encoding options. It will allow us to easily build several types of messaging protocols such as REST, SOAP, etc.

The IS module provides a simple query interface that allows the client to execute a read-only query written in SolarWinds Query Language (SWQL). SWQL is very similar to the commonly used SQL language with a few deviations.

When typically asked how does EOC scale or how many Orion server can EOC handle, as a typical rule of thumb I say a customer roll up 20-25 SLX’s into a single EOC instance.  With this being said, if they want to roll up more smaller installations, they can, as long as the total number of elements feeding into the EOC is not more than about 600k.

We also get frequently asked some rough ideas on how much traffic to anticipate between the Orion servers and EOC.  While this is very variable, the below chart can start to give you an idea of what to expect.

Nodes

Interfaces

Volumes

Events

VoIP

APM

NetFlow

Wireless

Bytes

10

10

13

782

0

0

0

0

625 KB

20

20

13

782

0

0

0

0

700 KB

50

50

13

782

0

0

0

0

822 KB

100

100

13

0

0

0

0

0

479 KB

100

100

13

782

0

0

0

0

1.183 MB

137

460

13

782

2

3 Apps, 37 Components

1 Source

2

1.277 MB

There you have it.  From high level what is is, down to how it works, hopefully this helps shed some light in one of the many different ways you can deploy the Orion family.

Parents
  • FormerMember
    FormerMember

    Can the EOC be used for monitoring several separate networks that do not relate to each other; with the potential for subnet range conflicts etc being very high? And with the networks sitting behind different VPNs?

Comment
  • FormerMember
    FormerMember

    Can the EOC be used for monitoring several separate networks that do not relate to each other; with the potential for subnet range conflicts etc being very high? And with the networks sitting behind different VPNs?

Children
No Data
Thwack - Symbolize TM, R, and C