Skip to main content

Use case walkthrough: Setting up custom event processing in Moogsoft Cloud

This video steps through a use case for using a workflow and tags to customize how events are processed in Moogsoft Cloud.

After watching this video, you will be able to create a workflow to process events. Specifically, you can explain the use of workflows in Moogsoft, and set up an event workflow to normalize event data.

Workflow Engine lets you create and add additional processing to your Moogsoft workflow.


With this interactive flowchart, you can drag and drop actions and build a process sequence.


Let’s use an example and actually build a workflow.  Suppose you are a SAAS company and you are planning to cluster alerts by location and customer. However, your source event data looks like this. The host part of the FQDN has your customer names, and the domain is the location. So, with the first action in this workflow we will split the source field value, and map it to the customer and location fields.


Also, some of your events are from QA servers and we don’t want our users to pay attention to them.  So as the second action in this workflow, we are going to add an environment label so we can exclude those events from the clustering process.


Finally, We have two support levels - silver and gold.  In order to prioritize the gold level support customers, we want to tag the events from them as such.


Let’s build a workflow to take care of all three tasks.


Let’s make sure everyone knows what this workflow is about.


The field we want to examine is the Source field, and the host information needs to go into a customer tag.


The domain information needs to go into location. We’ll put it in the data center location field.


We are all set with task number 1.

Next we’ll extract the suffix from the source name to label the test and production environments. Here’s a regular expression to capture the suffix of the source name.


We’ll store it in an Environment tag.


That task is done.

Finally, we need to label the support level so users can quickly identify which alerts are impacting your gold level customers.


We’ll add a Support tag and set the default support level to silver.


We’ll match these customer names. Then, we’ll update their support level to gold.


Now we use the support level information down the stream.  We can add the support level to the incident description, or send the gold support cases to the premium support team.


We are done setting up all three actions. Now let’s test this. We can test the workflow right from this UI.  We’ll simulate the input here. Let’s say the source fields says this. If our workflow is set up correctly, this input should be parsed and mapped to three different fields for us - customer, location, and environment.


Here are the test results. Looks like the source value got properly parsed and mapped to the customer and the location fields.


We’ve also extracted the environment substring.


Here’s the support level label, and we’ve updated the support level for gold customers.


Everything looks good, so let’s activate it.


Here are the alerts from our monitoring source.


The incoming data is customized the way we want it, and it's ready to produce meaningful incidents.


Thanks for watching!