Imagine having to haul water bucket by bucket into your home from the river, for utilitarian purposes. You get up in the morning, pick the bucket, walk all the way half asleep to the river, fill up your bucket, feel happy at the sound of water, and happily bring it back home. Then that bucket of water is over within 10 minutes when you take a shower. Now you need water to drink. So, you pick up that bucket again and do the same thing over again. This time you feel happy to get the exercise but wish there was a time saving way. Maybe you could hire someone to do the same monotonous picking-the-bucket and bringing-the-filled-one-back job over and over throughout the day, at your beck and call if you hired them for 24×7. Maybe you could build a pipeline but that would take hours of your off-work time, for a year almost. You are weary at the prospect of loss of family time. And you don’t want the neighbors to benefit from the pipeline because they will likely not put in the work with you.
Now imagine a similar scenario at work, seeing error logs from your application servers – all kinds of errors, in your production servers that serve thousands of customers. You have production support team set up to observe these logs and pick out the ones that are precious for your business – the ones that need to be acted upon. There are a lot of them because your customers are diverse, and they seem to love to expose the bugs in your application (inadvertently!). Some of the logs are just asking for maintenance such as a file system having filled up in memory and needing to be cleaned up. If the production support personnel thinks deep enough, they will create a ticket (in Jira or ServiceNow or whatever your means of communication with your L2 support or development team) and say that the application needs to develop some smarts and clean up unnecessary files from memory when it fills up to these many GBs. Some logs plain expose your customers’ human errors such as – they deleted a file by mistake in the installation folders and your application expects it; or a certain format of data is expected in a file in the installation and your customer’s team messed it up while editing it manually; or maybe your customer entered a bad password the legendary 3 times and are now locked out of the application. Some logs may indicate errors by your customer support personnel during a customer support call, such as asking them to modify a file in the installation folders and that update did not work well with your application. And then there’s the sea of logs that mean well – they say your application is running well; they just outline the various steps your development team wants to know about in the dreaded circumstance of an error happening for an end customer.
Mind you, the logs are helpful – not necessarily troublesome. They help the business react to current and changing needs of your customers. So you decide to implement an event management application such as BMC Event Manager (BEM) or BMC Helix Operations Management (BHOM) or Microsoft Systems Center Operations Manager (SCOM) so that you can direct all logs to events that are easy to view, filter and act upon. You can filter events by type, by time window and more. This way you can make more sense of them. If an event, like a file not existing, has occurred 10 times for different customers in a few hours, maybe there is a bug that the application development team needs to figure and fix. If a certain event such as incorrect database query has fired for only one customer 10 times in a few hours, the customer might need to call your L1 support and get their query corrected or troubleshoot what is wrong. If there are a number of heartbeat OK events, that means application servers are responding to customers fine. If out of 10 servers, 8 are sending heartbeat OK and 2 are sending connection failed, you need to either look at those 2 on-prem servers, or figure why your autoscaling in your cloud did not replace these servers automatically. There are a variety of actions you may want to take based on what your logs are saying, at a different depth of analysis of the events, possibly in different contexts held by different stakeholders. Maybe these events will be of different value to different teams such as your CTO, DevOps team, application development team, product managers, project managers, etc.
On another side of things, your application development and devOps teams have been getting swayed by random ad hoc requests coming from various stakeholders. Your L1 production support teams ask your development team to fix a recurring bug with multiple customers. Your CTO asks your application development team to create a graphical metric of how many unique customers were served in the past few months. Your product owner asks the devOps team to spin up 2 additional servers to serve more customers as customers have been experiencing latency in your application; business is growing. All these additional wants arise based on the events in your Event Management system. So, your architectural leadership decides to add an additional piece in your ecosystem – an incident management system such as ServiceNow. This way your L1 support team, your CTO, your product owner and others create incidents for your application development team and your devOps teams to pick up and implement according to a certain decided priority associated with the incident. This surely increases the efficiency of your on-ground teams.
But now, your stakeholders have to parse the events to create incidents in your Incident Management system and they also have to ensure that duplicate incidents are not created. This can be accomplished by an integration that can automate incident creation for at least most of the logs or events. Keyva team presents to you, an Event Integration product. Event Integration product is ready to use and customize for your particular use case. If you were to build a middleware that would do this, it would take you a year or more, employing a bunch of developers, product owner, project manager and testers. If you want to deploy a solution in under an hour, Keyva’s Event Integration can help.
Event Integration automates creation of meaningful incidents from your Event Management system. You can customize filters that club events together (such as heartbeat OK) to be logged into an existing incident so that it does not create a clutter of useless tickets. You can also customize it to ignore events that are not useful to the business.
Event Integration can enable 2-way communication between your Event Manager and Incident Manager. When an incident is closed at the Incident Manager end, that can be notified to the Event Manager to close all the relevant events as well. You can deploy a MID (Management, Instrumentation, and Discovery) server of ServiceNow to ensure security and encryption of all communication to and from ServiceNow (Incident Management system).
No additional hardware or software training is required to use Event Integration product. We work closely with you to get your Event Integration running and functional within an hour. Keyva’s software support team is available over email, phone and live sessions to fix issues you may face in the future or answer any questions you may have. Licensing of the product is easy to procure for temporary usage or long-term permanent usage.
Configuration of mapping between particular fields of TSOM (BMC TrueSight Operations Manager) or any other source event manager and ServiceNow or any other target incident manager is possible. New incident table fields can be created and associated with fields related to events. That way, incidents created by the Integration make most sense to the team at the receiving end. Event fields can be transformed to certain values in the incident, using transform mapping functions. For example, CRITICAL status of event can be mapped to let’s say number 1 in incident status. Multiple functions such as $SUBSTRING and $LOOKUP are available for accurate customizations, exactly how your business needs it. Here’s how the BEM and bem2snow Event Integration log look:
Installation is easy and available for Windows and Linux operating systems. It uses JDK (Java Development Kit). An incident can be created manually through the Event Management console for testing purposes. Multiple versions of BMC Remedy/BEM/TSOM/BHOM, ServiceNow, Microsoft SCOM/SCCM, MicroFocus MFSM/NNMi/ArcSight ESM products are already supported. Event Integration runs as a service or daemon and is easy to troubleshoot from it’s logs. Individual events can be traced to the corresponding incidents using a correlation id or system id.
Numerous high-profile clients across the globe are already benefitting from the seamless automation achieved by Event Integration. No major bug fixes have been asked for since the past over 20 years that it has been serving customers. It is a very stable product. We welcome enhancement requests.
Recall the water hauling bucket by bucket analogy I gave earlier. You can now cut the manual monotonous labor in your IT operations effectively.
If you have an Event Management system and an Incident Management system that you would like to integrate or if you have unwieldy application logs that you want to automate deciphering to act upon, let’s connect. Contact us today.
 | Shubhangi Wakodikar, Senior Product Developer Shubhangi is a skilled software engineer specializing in using Core Java, Gradle, and a diverse technology stack to maintain and enhance products for large-scale clients. Passionate about leveraging technology to simplify human life and promote environmentally friendly operations, she brings expertise across various programming languages, frameworks, and tools. Like what you read? Follow Shubhangi on LinkedIn |