RiverMuse PRO includes a Reusable Business Logic (RBL) engine to streamline the creation of all configuration components in a single reusable package.
The configuration is loaded through a text file; it is then parsed and converted by a back-end engine that updates the configuration of multiple components within the RiverMuse product. This is a vast change from traditional Manager of Managers (MoM) solutions as configurations from multiple components are incorporated in a single configuration.
The RBL engine serves to:
- Map organizational processes into the product through one configuration channel
– Fuel the creation of a community driven repository (aka App Store). Configuration packages can be shared or bought. (i.e. a configuration package for grouping events by event type, and performing isolated problem correlation; a configuration package for interpreting Cisco alarms and integrating with Cisco inventory tools to populate RiverMuse dynamic variables).
RiverMuse PRO also incorporates a presence management engine that can discover entities on demand.
This is most useful when new alarms are reported for devices/entities not yet present in a CMDB or inventory management system. A RiverMuse Business Logic Package can first lookup Configuration Item information from the CMDB, and if nothing is found, attempt to perform a discovery using the RiverMuse Presence Management System. This will provide many additional variables that can be leveraged through correlations, automations, and escalations.
RiverMuse PRO includes a centralized rules management wizard.
Whether there are 1 or 50 remotely deployed collectors, rules are configured in a central location through a GUI. Within a traditional Manager of Managers (MoM) solution, the process of obtaining events, performing correlation, and providing business context are usually separate and distinct. Legacy MoM architectures typically require business logic rules to be updated at various levels and multiple components within their system and frequently using different, proprietary scripting languages. This creates a management challenge – and makes it hard for operations teams to keep up with infrastructure shifts.
RiverMuse PRO provides the facility to consolidate your Data Center Operations in a single pane of glass, and achieve Operational Excellence by automating tasks and streamlining processes.
RiverMuse Core, the first enterprise-class open source Real-time Consolidated Operations Console system ideally collects information via SNMP traps and Syslog messages out-of-the-box. Additionally it supports 8 standards-based APIs to obtain data from virtually any source (gSOAP, Perl, Java, C++, XML, PHP, Python, and Ruby on Rails). RiverMuse PRO builds on top of RiverMuse Core and provides a presence management discovery engine, a powerful enterprise desktop console, dynamic alert enrichment from external systems, enhanced scalability, and additional functionalities to streamline organizational processes and dramatically simplify system maintenance.
Perhaps the most compelling reason for pursuing a Consolidated Operations Console solution is being buried in a myriad of tools. And more importantly having little or no business context mapped to the results. The need for a so-called Manager-of-Managers MOM solution becomes more evident the more complex and dynamic an infrastructure becomes – thus requiring various tools to manage and monitor the environment. While multiple monitoring tools are great for specific tasks such as application monitoring, transaction monitoring, or communication device monitoring, problems that affect more than one silo take longer to identify and isolate.
RiverMuse PRO solves this problem by centralizing data across all the different tools, and retrieving events directly from devices when needed. To perform this, RiverMuse PRO includes passive as well as active collectors such as the RiverMuse VMWare agent. This active collector natively interprets CIM (Common Information Model) formatted data streams. Events from different environments are consolidated in one repository, where cross-domain correlation can occur. This allows operations personnel to quickly identify the problem and associated symptoms.
RiverMuse PRO incorporates the event processing scalability of leading commercial Manager-of-Manager solutions without sacrificing granularily.
In other words, all events related to a specific alert are kept in our system and made available on demand including through a launch in context tool. Additionally, correlation can occur against events and alerts. Other leading Manager of Managers tools are also resource intensive and require several install instances to provide value. In contrast, RiverMuse PRO was incorporates a small footprint to curb the overhead and maintenance requirements of legacy MOM solutions without sacrificing elegance and functionality.
A common feature of current generation IT Event and Fault management systems is that you have to encode into the configuration of the system, a knowledge or representation of the logic that you use to manage the network, or device, or application. For example, a typical system management scenario is where you have a series of servers, routers and applications that you poll for specific data, which you then place conditions on to test for exceptions. Each exception can generate an alert that triggers actions.
All pre-existing approaches in legacy IT event and fault management systems prior to RiverMuse, encode the logic in a heavily scripted way, or, require detailed understanding of the topology or configuration of the managed system integrated in with the rules you write.
For example, in a typical probe rules file, to add an entry you need to include specific information, i.e. an IP address, for every device you want to ping. In others, you can consume an entire topology and output a code book that pattern matches the alert streams looking for particular root causes.
From a RiverMuse perspective, either of these approaches results in it being difficult to alter the configuration when the underlying network changes. In addition, if you want to collect all the intellectual property that has gone into building the business logic, and take it to a completely different network that is configured in a different way, i.e. different hostnames and IP addresses – this can also be complicated.
Hence, the work of configuring a IT event and fault management system becomes a consultancy driven exercise. You have teams of skilled people, with a deep understanding of the management system being used, and the systems or networks being managed, who execute something akin to a software development exercise.
The result is often a single purpose, environment specific configuration or a particular system or network. If you want to replicate the functionality, or solution elsewhere, you have to start over. If the network changes, you have to repeat large parts of the original exercise. All of these issues RiverMuse terms static and non transportable business logic.
(This is a Guest contribution on the RiverMuse Blog).
We loved your post and thanks for reading the Telesperience blog Microsperience!
We believe that even though we’re now officially post-crunch in telecoms, many CSPs have taken a good, long and hard look at how they buy and consume software. Interest in open source software by CSPs of all sizes is definitely on the increase. As you know, one of the “dirty little secrets” of the telecoms industry has been that open source tech can be found in virtually all CSPs’ IT stacks at some level – in fact many ISVs have been using it to lower their own costs for years while still publicly keeping on-message that it’s not really suitable for mission-critical BSS-OSS.
Our research has shown, however, that this situation is changing fast. Partly this is because a new generation of open source solutions like yours (not just technology or tools), are coming to market, and partly because CSPs in many markets are faced with having to do more with less. So to fund innovation they need to look hard at their cost base and reduce waste in the BSSOSS, using these savings to finance new projects.
We’ve also found that interest in open source tech is higher in the telecoms vertical than in other highly transactive industries. We recently asked a range of different types of large companies from telecoms, banking, automotive, computing/IT and government sectors whether they’d consider using open source technology. Eighteen per cent told us they were already using it, 9% are actively investigating using it, 55% said they would not rule out the possibility and 18% said they had no plans to use it. In a separate study we asked just telecoms SPs the same question and this found that, like the previous study, 18% were already using it. However, in contrast 27% were actively investigating using it, 46% would not rule out using it and only 9% said they had no plans to use it. This shows that telcos are more advanced in utilizing or evaluating open source solutions than the average enterprise.
Not only is interest in open source solutions high in the telecoms vertical but we discovered interesting trends amongst those adopting it. The (uninformed) consensus is that CSP adopt open source to lower costs. In fact, although this was certainly why many were attracted to open source initially, it’s not why they stayed. Far more attractive to them than just lower costs was the fact that many open source solutions are built using the most up-to-date technology available, and that they were capability-rich due to the sheer speed of innovation.
My advice to CSPs is therefore to not get hung up on what is essentially an alternative business model, but instead to evaluate open source solutions on exactly the same basis as any other software. One of the big hang ups in the telecoms software market has been that many CSPs are wary of being held hostage by a single vendor, and also that they realize that differentiation is increasingly going to come from software not networks. Open source seems to have a strong message for this fear – take control of your own destiny and don’t just accept a generic one-size fits all offering. There’s some really good software out there in the market today. Some of it is from ISVs and some from open source vendors. There’s no single ‘best’ solution for everyone – you have to evaluate the stand-out offerings against your own individual needs. What I’m saying is that dismissing a solution just because its open source is dumb and, if you take a look at the stats above, it’s certainly not what your rivals are doing.
Teresa Cottam
Research Director, Telesperience
In our new White Paper we discuss the IT Operations Management challenges for mid-size Enterprises and MSP’s. In many ways their environment is starting to look like that of the larger enterprise – only scaled down in size. They have also moved to any-to-any IP networks, VoiP phone systems, Virtualized datacenters and SOA based application architectures just like their larger counterparts. In fact the gap in requirements for operations management tools required by mid-size businesses and larger ones is rapidly closing.
User driven UI design is a hot topic at the moment, but is it really the future of user experience? Should technology driven design be completely abandoned?
In answering this question it is important to be aware that these questions are part of a bigger issue. The more general question is whether design should take into account the practical aspects of its application. By looking at this broader question UI design can benefit from the experience of other disciplines.
One argument for design unconstrained by practicalities is that developers suffer from “when you have a hammer every problem looks like a nail”, that is they tend to simply adapt implementations which have been previously used rather than considering usability. The result is often a quick implementation, but poor user experience. There is no need to look to other disciplines for examples of this, simply browsing the internet gives plenty of fodder for this argument.
But if practical aspects are not given due care the resulting design may be difficult to implement, or not withstand the extremes of usage. It could be even worse if implementation is undertaken by those lacking in experience and the design flaw may not be realized until too late. In this case, the experience of other disciplines gives weight to the pracalities aware design proponents. Within IT such designs could lead to abandonment of projects or failures at testing, but visiblilty of this is only at the level of the company in question. In other disciplines the effect is more apparent to the independent observer. For example, many buildings and bridges have collapsed because their design overlooked the physical aspect of potential stresses, be it the action of the wind on the narrow Galloping Gertie or the collapse of buildings when earthquakes strike.
Clearly, designs that do not consider the practical limitations, from what is physically possible, and the effect of edge usage must be avoided. Yet poor usability it not acceptable. Both the user experience and the realities of application within the discipline must be considered during design. In UI design terms both user driven and technology driven design have merit, but they lie at opposite extremes. The compromise is to be aware of limitations of what is possible technologically, while applying usability principles, without forgoing an awareness of the extremes of usage.
We’re running a competition at the moment to come up with the most novel use of RiverMuse, see here . This got me thinking back to some of the early uses of the web, such as ensuring a good supply of coffee. I was wondering what I could come up with, on these lines, to demonstrate the flexibility of the system. So here goes…
In my hypothetical system, a web cam watches a hypothetical bird-feeding table in my garden. Whenever the web cam detects motion, it records this as an AVI file, and posts this in a directory on my home PC (web webcam only works with Windows). The network access by the webcam is recorded, in the windows event logs, and this comes into RiverMuse Core as an event. Omosd processes this event and de-duplicates it, which is important, as the next step in my process can only handle one event at once.
If the webcam alert has a count of 1, then yarpd executes an external command to process the AVI file into a low bandwidth format and upload it to a website. When this is done the conversion program sends a syslog message back to RiverMuse. This causes a number of events to happen:
- The webcam alert is closed.
- I run a shell command to tweet about it so all the fans of my bird table will know there is a new video to watch.
- I fire an alert back into RiverMuse which contains the date in it and omosd de-duplicates this so I can have a filtered view of alerts that show me how many videos got uploaded in a day.
If the count of the webcam alert is more than 1 then yarpd executes an external script to delete the extra video clips, as my conversion process can’t handle more than one at a time.
As a phase 2 I’m going to processes the web log’s so I can see which video’s are the most watched.