This page is a Quick Reference containing a punch list of run anywhere (copy/paste) Splunk searches to help explore the data in the OpenMethods Splunk events. The use of some advanced techniques is intentional and the foundational explanation for the techniques will be covered in other articles.
...
| Table of Contents | ||
|---|---|---|
|
...
Conventions
In order to conserve space on this page with respect to writing queries and query results,
...
| |||||
  |
2.1.a. What are agent states for UCCE and their stats?
...
Currently, the majority of searches are centered around component names, ‘mb.className' and 'mb.functionName’, and string matching.For example, at a quick glance simply of a component, it can be easily determined if an agent is getting screen pops from Harmony or another way. |  |
|
...
Explanation:
a) Why the use of: ‘| search crmgroup="" class=”*”’ clause and all the string matching?
i) As described previously on this page, we are still dependent on string matching and class names. Writing fixed data points or metrics will be a better interface.
ii) The field ‘msgctx’ is present for context and would be used in the case where we are not filtering out ‘mb.className’. You see we are trying to populate ‘mytitle’ and ‘jsonctx’ fields and in the case they are blank might mean there is a message that I am not expecting so the parsing isn’t working on it. Finally, collapsing 2 fields down to 1 is simply for saving space so I can still see the ‘message’ field without scrolling.
b) One of the most important statements in this query is the use of regular expressions (pattern matching):
| rex field=message "^(?<mytitle>[^{\n]*)(?P<myjson>{.*})"
there is a page dedicated to tools for pattern match and JSON manipulation for Splunk, keep checking back for updates.
...
There are workflows authored to act off events and "event detected" messages, which can have a corresponding action to fetch a workflow as "getting popflow for eventId" messages, followed by a "got popflow" message which loads workflow and starts to run activities of different types and tracks "starting activity" and "activity complete" messages.
...
3.2. What Popflow Events are Being Triggered and are the Most Frequent?
...
| |||||
 | |||||
From Fields Panel, click on ‘custom.displayName’ for Top 10 Values   |
3.4. Start Normalizing the Data, Put Events, Popflow Scripts, and Activities All Together in Context
| |||||
What did we add over the previous queries? a) 2 or 3 ‘rex’ commands were all handled now in one ‘rex’ command. b) we extracted ‘eventId’ by string parsing of the ‘message’ field and extracted ‘typeid’ (activity type id) from JSON and then used a lookup table to translate them to friendly names. c) multiple ‘eval' commands got moved to a single pipe as there is overhead for each pipe d) there is no single normalized field which is common to all event types (which makes it difficult to manipulate and combine the data later) so we added ‘msgtype’ e) the search patterns on the ‘message’ field in the very first segment of the search, when Splunk finds a match in a pipe it stops processing the rest so I made search patterns more explicit and ordered them by frequency of occurrences so there is a higher chance Splunk will find a match and do less processing. note: the technique for finding frequency of occurrences of the ‘message’ field was the same as we’ve used on this page, which goes something like … '<your search> | stats count(msghdr) as cntmsghdr by msghdr' | sort cntmsghdr DESC |
4. Omis Events
4.1. How to identify customer/agent using HIS/Harmony stack and how are they using it, aka Omis Overview?
| |||||
 |
...
4.2. What are all the possible Omis message types and how do I work with them?
4.3. How do I check if there are any Omis message types I don't know about?
Previously on this page, it was stated that if there is a long evaluation or conditional command (for example string match), Splunk would grab the first match and stop processing. Thus, it would reduce processing and improve performance in theory if the search matches are ordered in the frequency of occurrence.
While leveraging that concept, there wasn’t an immediate obvious performance impact but the side effect was a search command which verifies that your query is structured so that it processes every message type and if one is not known certain fields would be null. You could use a similar concept to uniquely identify every Omis ERROR across every CTI platform and customer, well possibly.
| |||||