This discussion has been locked. The information referenced herein may be inaccurate due to age, software updates, or external references.
You can no longer post new replies to this discussion. If you have a similar question you can start a new discussion in this forum.

WHAT IS THE ENTERPRISE OPERATIONS CONSOLE (EOC) & HOW DOES IT WORK? 2.0!!

For those of you familiar with the Enterprise Operations Console, you may be familiar bshopp previously written, similarly titled article emoticons_wink.png, which explains the function and purpose of EOC.  That article was a big hit among users so I have decided to write up something similar for our latest release of EOC 2.0.

When discussing the Orion Suite of products with customers, we often get the question, “how does Orion scale?”  Customers these days may have very different reasons for asking this question or different ideas of what scale means to them.

The answer is that SolarWinds provides multiple methods available for customers to choose from:

  1. Scaling horizontally or scaling up - If customers are scaling the number of elements within a single instance of Orion, SolarWinds provides the use of Additional Polling Engines to quickly expand the overall capacity.
  2. Scaling out - Whether it is the way in which the client runs their business such as a MSP, a customer has acquired additional instances of SolarWinds due to mergers or acquisitions, or any other number of reasons, customers may have what we refer to as a distributed model of deployment.  This means the clients environments consist of multiple separate Orion Instances running throughout their infrastructure.  The Enterprise Operations Console is the perfect tool to roll up data from each distributed instance.

In this post, we are going to discuss the Enterprise Operations Console 2.0 or EOC for short.  Take the below first graphic, you have a worldwide network with teams responsible for managing their respective region, so an Orion installation resides in each; North America, EMEA and APAC. 

pastedImage_4.png

EOC’s main functionality is to aggregate data from multiple Orion server installations and display that data in a similar fashion as the Orion Web Console. As an example, the global NOC/ Management Team may require a comprehensive view of all entities into a single dashboard for a representation of status, current alerts, and need the ability to run reports across the worldwide environment.  The Enterprise Operations Console provides this visibility for you. Administrators even have the ability to create customized accounts and restrict what 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.

Now, the EOC 2.0 web console has changed slightly from the prior version as you can see in the screenshots below.  The previous version of EOC is on the left, and the latest version of EOC is depicted below on the right. 

EOC.jpgpastedImage_138.png

Below is a quick touch on some of the new features and improvements.  Stay tuned for more posts with additional details around these features. 

  • Improved Data Collection: Live on-demand polling and immediate display of data from distributed Orion Instances. (Discussed more below)
  • Improved & Updated UI:  EOC 2.0 is now built on the same framework as other members of the Orion product suite.  This provides:
    • An improved UI, with familiar navigation, icons, and controls.
    • Access to Orion features such as High Availability including multi-subnet deployments (WAN/DR), and the ability to implement Additional Web Servers with EOC.
  • New Status Rollup: View status of any Orion entity from distributed Orion sites with the unique Enterprise Summary Tiles.
  • Improved Search Functions: Utilize Search integrated into the Navigation or utilize the Asset Explorer for pre-filtered searches within Enterprise Summary Tiles.
  • New Alert Options: Input notes and acknowledge alerts from EOC.
  • Global Reporting: Create and customize global reports with easy selection of desired sites.
  • New Map Options: Import Maps from Orion Instances to display status in EOC NOC view.  Use the WorldMap resource to display consolidated view across the distributed environment.
  • PerfStackTm in EOC: Perform advanced analysis of issues by pulling entity data from multiple sites into a single PerfStackTm!  

Note:  There is no upgrade path from EOC 1.6.x to EOC 2.0.  You may run both these versions in tandem if desired, however EOC 2.0 will require a fresh install on a new server and a new database.

These changes were done based on feedback from you, our users, who were looking for an update to the UI, more flexibility with the tool, and something up to the standards the rest of the Orion Platform has executed upon with recent enhancements. 

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 such as current status, alerts, events, and more.  Investigating further or drilling into elements within the EOC web console would then seamlessly redirect users behind the scenes to the local Orion instance that entity is actually being monitored from. 

Let's walk through an example.  Below you can see that I have a number of issues in my lab environment, and I will select a node entity that is in warning.  This will populate the asset explorer with a pre-filtered list, and drilling into the device will actually take me to the device details page on the local instance where that node is being monitored from:

EOC PopOver (2).gif

I can now continue further investigation or go right back to my EOC global view.

Now that we have gone through a high-level of what EOC is, let's dig deeper into how it works.  In versions of the Enterprise Operations Console prior to 2.0, EOC contacted remote Orion instances at regular polling intervals in which it collected all current statistics based on the most recent polls.  So by default, every 5 minutes, large subsets of data were retrieved from the remote sites and stored into the EOC database.  The overview of the previous version can be reviewed here:  What is the Enterprise Operations Console (EOC) & how does it work?

The problem was that even with decreasing the polling intervals, we were never able to achieve real-time polling or real-time display of that data within EOC.  Very often, the data presented was well behind what was actually being detected at the local instance/site.

Delays in status and alert notification presented a serious problem for EOC users, therefore resolving this issue was extremely critical.  EOC 2.0 now leverages a function called SWIS federation which executes only the queries necessary determined by the content of the page being viewed.  In essence, Federated SWIS allows us to pull only the data we need, when we need it. 

Depicted below is a more technical breakout of this first image.  Each instance may contain different products, may be different sizes, and may be geographically dispersed. 

pastedImage_159.png

With EOC 2.0, remote Orion SWIS services register themselves with EOC's federated SWIS service, thereby exposing their data through a single SWIS interface.  When a user/client accesses the website and performs a function, a SWQL query is sent to SWIS on EOC.  Here it is analyzed to determine what servers can satisfy the query.  SWIS will then exclude any servers that are not necessary, forward the query to the appropriate Orion SWIS instances, combine the results from each, and send the aggregated results back to the client. 

This process is completely transparent to the user and is able to run much more efficiently over constantly pulling copies of data, from each instance, into a database, and then running additional queries to provide the results.  Federated SWIS performs all the heavy lifting, aggregating the data, and allows us to display that data exponentially faster than we were able to before. 

EOC 2.0 will be able to highlight Alerts, Events, and Status from any of the following entities:

  • Applications
  • Components
  • Groups
  • Interfaces
  • IP SLA Operations
  • LUNs
  • NAS Volumes
  • Nodes
  • WPM Player locations
  • Pools
  • Ports
  • Providers
  • Storage Arrays
  • Transactions
  • Virtual Clusters
  • Virtual Datacenters
  • Virtual Hosts
  • Virtual Machines
  • VCenter Servers
  • Volumes
  • And more...

Here are a few posts that can likely add additional insight into the flexibility of EOC 2.0

Understanding Changes In EOC 2.0 - The Enterprise Summary View

Understanding Changes In EOC 2.0 - The Enterprise Maps View

Understanding Changes in EOC 2.0 - Creating Global Top XX Resources

NEW

Enterprise Operations Console 2.1 Now Available!

Parents
  • Great Questions ecmel - hopefully my answers help here inline:

    I see that Environment Summary Tiles are updated in real time; when a node status changes, information on the related tile changes in seconds (really impressive). Does "Active Alerts" widget have the same behavior? I see that "Active Time" column for alerts are updated every five minutes (page refresh time frequency).

    A:  Active Alerts resource on the Enterprise Summary Dashboard does not function in the same manner as the tiles.  You are correct that this is updated every 5 minutes.

    I could not see recommended number of end users for the EOC web console. As Environment Summary view is updated in real time for each user, I think there should be a limit for the number of users to prevent performance issues on SolarWinds sites. Could you give some details about the effect of a new user logon on EOC?

    A:  As EOC is now built on the standard Core Platform, in general around 15-20 concurrent users could access EOC.  When additional users are accessing EOC, a single SWIS connection is still used, and therefore the impact is not based upon additional connections, but the amount of data which is pulled back via the queries.  Very complex queries or a query looking for a lot of historical information could extend the amount of time to return the data, but the tiles are focused on returning current status information which should not present a problem.  EOC has also been designed to be smart enough to make automatic adjustments to the frequency in which it queries specific data to ensure it does not overwhelm a remote instance.   

    For the alert acknowledgement, I see that site integration user is displayed as the acknowledged user. Is there a way to change this as the logon user in a scenario that users are authenticated by AD groups?

    A:  EOC can be set to leverage the AD accounts or Orion accounts in the same manner as a standard Orion Instance.  So as long as you leverage the group account or individual AD account as the integration used from EOC, drilling into more detail to a remote site, or acknowledging an alert should be represented by the same account.

    For the map integration, does it work as a one time import utility or is there a way to update an imported map on EOC automatically when the original map changes on SolarWinds site?

    A:  When you import a map, this is a one-time utility.  If a change is made to that map at the remote instance level, a user would simply need to import the new version which will update the map in EOC.

Reply
  • Great Questions ecmel - hopefully my answers help here inline:

    I see that Environment Summary Tiles are updated in real time; when a node status changes, information on the related tile changes in seconds (really impressive). Does "Active Alerts" widget have the same behavior? I see that "Active Time" column for alerts are updated every five minutes (page refresh time frequency).

    A:  Active Alerts resource on the Enterprise Summary Dashboard does not function in the same manner as the tiles.  You are correct that this is updated every 5 minutes.

    I could not see recommended number of end users for the EOC web console. As Environment Summary view is updated in real time for each user, I think there should be a limit for the number of users to prevent performance issues on SolarWinds sites. Could you give some details about the effect of a new user logon on EOC?

    A:  As EOC is now built on the standard Core Platform, in general around 15-20 concurrent users could access EOC.  When additional users are accessing EOC, a single SWIS connection is still used, and therefore the impact is not based upon additional connections, but the amount of data which is pulled back via the queries.  Very complex queries or a query looking for a lot of historical information could extend the amount of time to return the data, but the tiles are focused on returning current status information which should not present a problem.  EOC has also been designed to be smart enough to make automatic adjustments to the frequency in which it queries specific data to ensure it does not overwhelm a remote instance.   

    For the alert acknowledgement, I see that site integration user is displayed as the acknowledged user. Is there a way to change this as the logon user in a scenario that users are authenticated by AD groups?

    A:  EOC can be set to leverage the AD accounts or Orion accounts in the same manner as a standard Orion Instance.  So as long as you leverage the group account or individual AD account as the integration used from EOC, drilling into more detail to a remote site, or acknowledging an alert should be represented by the same account.

    For the map integration, does it work as a one time import utility or is there a way to update an imported map on EOC automatically when the original map changes on SolarWinds site?

    A:  When you import a map, this is a one-time utility.  If a change is made to that map at the remote instance level, a user would simply need to import the new version which will update the map in EOC.

Children
No Data