How Hardware Sentry KM Became an Otel Agent
A long road to embrace OpenTelemetry
Nassim Boutekedjiret, Software Architect at Sentry Software, walks us through how Sentry Software's flagship product, Hardware Sentry KM, became an Otel Agent. With over 10 years of experience in software design and development, Nassim, assisted by a multidisciplinary team, led and successfully achieved the project.
What was the initial motivation for adapting Hardware Sentry KM to the OpenTelemetry ecosystem?
Well, we had two goals in mind. First, make a product designed to operate in a BMC TrueSight/Helix environment self-sufficient. Then, make our observability metrics 100% consumable by other platforms, such as Prometheus, Datadog, etc.
That's probably easier said than done! How did you proceed?
We knew we had to entirely rewrite Hardware Sentry KM in Java and review its architecture tailored to the BMC environment. So, we started by designing a Prometheus exporter; Prometheus was the next best thing at the time and it was supported by numerous platforms. We needed to dissect Hardware Sentry KM and its HDF connector-based architecture. We had to understand the code of the KM and how to configure input and output content.
Then came the time to elaborate a new architecture. That phase implied translating HDF connectors in Java and creating a parser that would turn the collected data into an OpenTelemetry-friendly format.
Finally, we developed an SNMP simulator to perform integration tests internally and implemented a code coverage policy that reached 75%, which guarantees the solution's reliability and robustness.
Of course, I did not do this alone; a whole team worked with me on this project. One of my responsibilities was coordinating all the teams and phases (development, integration, QA, documentation, etc.) to ensure we released a new version of Hardware Sentry on time and by the quality standards we had fixed.
How long did the project take?
I'm proud to say that within 6 months, we had the first OpenTelemetry-compatible version of the product. This is big, considering the workload and the effort required to completely transform the initial product that matured and evolved for more than 14 years.
What was the biggest challenge to overcome?
Oh! There was more than one. I believe translating connectors into Java was the hardest. We had to write a PSL(1)-to-Java converter and process over 250 hardware connectors to continue offering our users an extensive range of supported platforms.
Also, we wanted our users to be able to choose to run requests in either parallel or serial modes. It proved challenging, but we released this feature with v.3.0.00 of the product.
Our wish list also included an enhanced calculation mode for our estimated sustainability metrics. We finally re-designed both modes (measured and estimated) and delivered on time.
Finally, to become OpenTelemetry contributors, we had to comply with the metric semantic conventions.
(1) PSL is a compiled language developed by BMC for writing complex application discovery procedures, parameters, and commands within the PATROL environment.
To conclude, are you satisfied with Hardware Sentry 3.0.00?
Yes, absolutely. This product is the result of a joint endeavor. We managed to have it support even more platforms than the original version. We made it more robust and safer.
Today, it is mature but not frozen since it is designed to grow and evolved with our user needs. We will publish more articles about the future of Hardware Sentry soon. Stay tuned!