This is the largest functional delivery of OMEGAMON Data Provider (ODP) to date. It's the third functional APAR and can be found as
OA63141 / UJ08693. It contains several significant enhancements that establish the foundation for a wealth of new creativity for the future. Let’s tackle each one separately.
Instana integration with OMEGAMON
Instana is IBM’s new Application Performance Monitor that greatly improves IBM’s role in Enterprise AIOps and observability. It’s got a wide variety of capabilities as shown by this diagram below. Through IBM’s existing APM for z/OS product, it was able to capture some z/OS mainframe data. But now, with OMEGAMON integration, it has a much wider view of the mainframe within an enterprise and that view will continue to grow over time. The actual product name required for OMEGAMON Integration is: IBM Observability by Instana Application Performance Monitoring on z/OS. You can read more about it
here.
The goal of Instana is to provide insight over a very large breadth of IT infrastructure at a high level. OMEGAMON can play a significant role in providing real time content as to activities on the mainframe. And when a problem on z/OS is identified within Instana, investigation can continue within the OMEGAMON user interface to get to the root cause of the situation. Having an end-to-end context of mainframe, end points and intermediate servers as part of a business workflow should greatly ease the burden on resolution to infrastructure issues.
This first deliverable of Instana integration includes a starter set YAML definition for z/OS, Db2 and CICS content that Instana can provide information about. As Instana rolls out more capability, they will provide updates to these definitions that can be easily integrated into the ODP environment. This same capability can be used to manage other sink definitions as will be evident in the Persona topic below.
MQ, Storage and Network data streaming
With this functional update, all z/OS OMEGAMON agents in the SMSz V2 and IZMS suites (where ODP exclusively ships) will now be able to stream data. The starter dashboards for MQ are also available on GitHub at this time. As with prior agents, starter dashboards for Storage and Network monitoring should be delivered within the next two months. Stay up to date with this blog series and our
GitHub repo to get the latest improvements to the dashboards. As a teaser, here are a couple of early dashboard screen shots to whet your appetite.
Persona management, Outsourcers and very large enterprises
While you might not see it explicitly within the ODP documentation, the addition of several new features makes Persona management possible. Those features include the ability to use “include” statements within YAML definitions and the use of field level filtering via conditions within the YAML statements.
Let’s define what a Persona is first. Different roles have different needs for accessing data.
- An executive might want a very high-level dashboard, perhaps with speedometers, to see at a glance, the state of their operation. No more detail than that. And it is only for production systems.
- A database administrator may only want to capture data around their databases and the transactions accessing those databases. In a DevOps role, they might want Production and Development system knowledge.
- A Systems Programmer might want to see all data for the specific systems they oversee. It could be all systems or a subset of systems.
- A Subject Matter Expert may want to see a subset of overall subsystems within the enterprise.
Now add in the scope of the IT infrastructure: a very large enterprise with multiple IT organizations or an outsourcer providing system access for multiple customers. In those environments, the Persona could be tied to a particular IT team or business customer and they might see a subset of systems housed within the overall enterprise. Outsourcer personnel might want to visit all systems for all customers, both development and test.
Net effect is that each persona might define its own target “sink” or analytics platform. For example, Executives might only use Splunk, DBA’s might want to use Instana. SME’s might prefer Elastic.
Prior to this release, all “sinks” were defined in a single connect.yaml file. We know that mainframe system programmers love change management and will want to apply that discipline to this file as well. If there are many personas within the enterprise, the time to make changes might be elongated. Worse, an error while editing the larger file might effect all personas and have business impact.
The use of “include” files, dedicated to a given persona and field level filtering should greatly simplify the administration of personas. Each sink could be independently updated. Field level filtering can be done such that only certain LPARs or applications or databases might be observed by any persona.
An additional filtering benefit is that conditional thresholds can be set against particular fields. Data might only be shared or visible beyond a certain threshold. This is not the same as OMEGAMON situation management, but it can be complimentary to that functionality and reduce the volume of data being sent to a sink. Refresh of ODP Data Connect will still be required for any sink changes to take effect. The filtering options use the Spring Expression Language (SpEL) which is a feature of the Spring framework upon which the ODP Data Connect server is built. There are some syntax examples in the
ODP documentation. For comprehensive details of SpEL syntax, see the Spring documentation:
Here
Another area valuable to outsourcers and large enterprises is the ability to cluster and run multiple distinct ODP Data Connect servers. Clustering can be used for high availability and resilience. Running different servers can be leveraged for isolation of persona/customer needs, as well as improved performance dedicated to a persona.
ODP field level dictionary
As mentioned in earlier blogs, 95% of existing fields within OMEGAMON attribute tables are ready to go but 5% need some amount of curation. It could be its name conflicts with a field from a different attribute table, there may be missing information, such as LPAR name, subsystem id or SYSPLEX name from a particular table. And these attribute tables are kept in separate documents for each agent across 1000’s of document pages. How’s a dashboard developer to know what fields are available and where to find them?
The answer is a dictionary file is being shipped to be included at the default location: /usr/lpp/omdp/kay-110/dictionary. In that tree, you’ll find sub-directories for each OMEGAMON agent and within each agent a YAML file for each attribute table eligible to be streamed. Those files contain the corrected names and types for every field in the attribute table. The dictionary is shipped as a product file as there can be changes on release or service boundaries, so a centralized web access to such a file may be inaccurate, depending on customer service levels.
The goal of the dictionary is to reduce the time necessary to understand and develop dashboards or sink connections.
What’s coming next?
Easy items to deliver are new starter dashboards for Storage and Networks.
As mentioned earlier, the MQ dashboard is available now. It may be a month or two before the Storage and Networks dashboards are shipped.
And then we tackle new agent functionality. As new OMEGAMON agent updates are delivered, there may be new attribute tables or fields, so access to that information must be included. That’s just the case with the introduction of IBM Z OMEGAMON Monitor for z/OS 5.6, IBM OMEGAMON for Db2 Performance Expert on z/OS 5.5 and IBM Z OMEGAMON for CICS 5.6 which were/was recently introduced. New capabilities for z16 hardware, IBM Db2 13 for z/OS and IBM CICS Transaction Server for z/OS 6.1 will be made available for streaming.
Community and future development
We’ve said from the beginning that our first starter dashboards are truly just the beginning. We’ve got customers customizing the starter sets and creating their own dashboards. We think there is value from sharing these modified/new dashboards with other customers and would like to facilitate that sharing.
The use of analytics is a springboard toward Artificial Intelligence and Machine Learning. To that end, we’ve begun that journey as well. It started with Adaptive Thresholds within OMEGAMON for Db2 (name) and is continuing to other agents. But this cannot be a development lab exercise. We need real customer data from SMF and RMF. Six months or longer would be ideal.
If you would like to participate in either of these community activities: sharing dashboards or sharing data with our development community, please reach out to me at
jporell@rocketsoftware.com and we can discuss how best to go about that.
More info
As stated in our last blog entry, we now have a one stop shop for links to other materials related to ODP. You’ll continue to find that information
here.This blog and a demonstration video of Instana with OMEGAMON have been added to that collection.
#CICS#db2z/os#IBMMQ#IBMZ#IBMZOS#IBMAI#IMS#Instana#jvm#OMEGAMON