Written by Zig Licis, Master’s Degree Student at Queen’s University
My name is Zig Licis and I’m currently completing my Master of Engineering graduate degree at Queen’s University in Canada. I have keen interests in software development, data science, and machine learning and am passionate about leveraging my skills to tackle any problem I find interesting or valuable to solve, while being in a position to innovate and contribute towards developing solutions to modern problems. This summer, I’ve had the privilege to work with mentors at Zebra under the Open Mainframe Project as a mentee on the Zebra JavaScript Application project. This blog highlights my journey throughout the mentorship experience and the work that I’ve done with an emphasis on changes and improvements to the existing application.
The Zebra JavaScript Application Project
Zowe is an open source framework for z/OS, an operating system for IBM zSystems mainframes. Zebra is a performance monitor which utilizes Prometheus and Grafana to display these mainframe metrics in more readable and understandable forms, helping mainframe users understand how the mainframe is performing. The functionality to create custom Prometheus metrics which can then be visualized in Grafana currently exists. However, the user interface and process is not intuitive and was in my opinion unfinished. Without extensive knowledge on the thousands of metrics and the further tens of thousands of combinations of custom metrics, I had an incredibly difficult time learning, understanding, and navigating the custom Prometheus metrics section of the Zebra application. My goal for the mentorship was to overhaul this section of the application and in return, vastly improve the user experience of managing custom metrics.
Watch my final presentation video:
The Current Custom Prometheus Metric Application
Zebra currently comes built with an API and framework allowing for the creation of real time custom Prometheus RMF III metrics. However, the Add Custom Metrics form is quite unintuitive and without extensive knowledge of the metrics being worked with, users are left confused having to select Identifier Keys and Metric IDs from hundreds of values such as ‘CPCPCAPI’ and ‘DVRPSVCL’. Additionally, the restriction of adding and deleting one metric at a time presents a massive time commitment to creating real-time custom metrics. Finally, after already spending too much time making modifications to their custom metrics file, users must reload the application for these changes to be reflected in the prom-client and Prometheus server to visualize these metrics in Grafana. The current implementation’s intuition, user experience, and time constraints presented me with an opportunity to contribute improvements that will benefit users far into the future.
Notable Work/Changes
The first major change I worked on was dealing with the unreadability of hundreds of unique metric fields and identifier keys. By adding to the current constants.js file, I was able to provide each of these unique IDs their respective descriptions allowing those to be used in metric parameter selection instead. Following this, I overhauled the user interface to be more friendly and intuitive in the way metric descriptions are displayed.
A metrics list with all available metrics based on the LPAR and Report selected now splits the window with the parameters form. This list is dynamic with the ability to filter by metric type. With multiple metric types, I found it important for a user to filter by the type they specifically want to see. For example, a user can select an LPAR and Report, and then filter to only see numeric metrics. Additionally, the list is in the form of a checklist, allowing users to select multiple metrics and add them at once. When discussing with my mentors, this was an important feature as there are groups of metrics that may want to be viewed together and being able to add these jointly saves valuable time.
Changes to the pre-existing parameter form provided further UX and concision improvements. The unique metric ID input was removed as the metric IDs can be used as the unique identifier of the metric name. Once again modifying the constants.js file to provide each report with a resource type, the resource dropdown select was removed, further streamlining the creation process. When dealing with Identifier Key and Value parameters, it was apparent that the same descriptions should be present in the Identifier Key dropdown for user readability. Additionally, the Identifier Value dropdown and its functionality was reworked to allow for multiple values to be selected. Users can now select any number of values, not just one or all, and add multiple metrics at once in conjunction with the multiselect capabilities of the metric checklist. This gives way for a deeper level of customization and time efficiency within the creation process.
The current added metrics table functioned well for its purpose of displaying added metrics, showing their important parameters, and providing a method of deletion. However, if multiple metrics can be added at a time, users should be able to delete them in groups. The new and improved table removes these delete buttons for each added metric and replaces them with a checklist and a singular delete button below. Now, when that button is clicked, all selected metrics will be deleted.
All these UI/UX changes would be for nothing if users still had to reload the application and wait valuable time for those changes to be updated and available in the Prometheus server for Grafana visualization. Changes were made to the Prometheus metric scraping
functionality to scrape and update newly added metrics each time a change is made to metrics.json, as well as every RMF3 interval as before. Now as soon as metrics are added or deleted, users will see them instantly updated in the Prometheus server and can quickly visualize them in Grafana.
Future Work
While I feel my work this summer will provide mainframe users with massive improvements in their work with creating and managing custom metrics, I want to address a potential future addition that would bring Zebra another step above its current capability. As I discussed with my mentors throughout this summer, the function of being able to create and manage multiple metrics.json files would drive even more customization potential and flexibility. This would allow for mainframe users to manage multiple files within the Prometheus server and allow for hot swapping of metric groups without needing to recreate one file each time even further increasing efficiency.
My Experience
Reflecting back on my experience this summer within the mentorship program, I felt as though our group laid the benchmark of a high performing team. Our weekly meetings gave way for collaboration between me and my mentors as well as combining our meetings with Joe Carsile, Krishi Jain and their project. Seeing how people from so many different backgrounds came together, collaborated, and made great improvements to our projects was inspiring and something I’d hope all my team environments going forward in my career consists of. I want to thank my mentors again and the Open Mainframe Project for giving me this opportunity to contribute towards an interesting project and field while improving mainframe users’ experiences with Zebra.
Stay tuned here and the Open Mainframe Project social channels for more mentee blogs and videos.
- Follow us on X at @Openmfproject
- Connect with our LinkedIn page
- Subscribe to our Youtube Channel
- Sign up to get our newsletter
- Learn more about the Open Mainframe Project Mentorship Program
