/ SPEAKER
Robert Lynch
Murex
Robert Lynch is the Splunk global manager at Murex (Murex is a world leader in trading platforms). He introduced Splunk to Murex 9 years ago and due to his drive, Murex is now selling his Splunk code to some of the biggest banks in the world. He is responsible for the Test/Development and Architecture of Spunk at Murex.Robert won the 2017 “Splunk Ninja” revolution award https://www.splunk.com/blog/2017/09/25/congratulations-to-the-2017-splunk-revolution-award-winners.html and 2nd place in the Splunk Commander award 2019.Robert holds a “Computer Science” degree and a master's from Trinity College in “High Performance Computing”. The links illustrate some of the good work done.https://youtu.be/nEO_yqOSNKw?feature=shared [Using OpenTelemetry,Splunk, and CI(Jenkins) to deliver Financial Software 4 Minutes]https://www.youtube.com/watch?v=pJsTp7XlGGA [Dashboard for Developers + Testers 5 min]
Using OpenTelemetry, Splunk, and CI(Jenkins) to deliver a Monitoring Solution for Financial Software (Murex)
Conference (INTERMEDIATE level)
Financial software is massively complex and challenging. This is the story of how Murex started to use OTel, Splunk, and CI(Jenkins) to help monitor their application.
The talk goes into detail about the three main components 1st OpenTelemetry 2nd Splunk 3rd CI(Jenkins)
Murex had to ask ourselves a hard question. Is the data our platform producing good enough for the future, if not what can we do?
We felt the need to move to another data framework. We felt that OpenTelemetry was perfect for us. Murex decided to build an APM (Application performance monitoring) that would monitor our extremely complex financial software. However, getting the right data is only half the battle, what would we use to visualize it(Splunk), and how would we test the solution(CI).
Below are the major components of this talk.
OpenTelemetry: Pulling the data from our systems via Python probes. How we onboard Python developers who were creating the OTel Data to use Splunk to help them visualize the data. How and why we are now changing to GO to push the data from systems.
Splunk: How we built an APM to view this data in Splunk. The performance choices we made for metrics and logs as the business wanted a 10-second dashboard refresh rate.
CI (Jenkins): After Merging the Spunk code into the Murex code we needed a way to test it. We have created a Test inside a CI (Using Jenkins deployed on our Kubernetes) that can take any version of Splunk + Murex and compare the Splunk outputs using Curl.
More The talk goes into detail about the three main components 1st OpenTelemetry 2nd Splunk 3rd CI(Jenkins)
Murex had to ask ourselves a hard question. Is the data our platform producing good enough for the future, if not what can we do?
We felt the need to move to another data framework. We felt that OpenTelemetry was perfect for us. Murex decided to build an APM (Application performance monitoring) that would monitor our extremely complex financial software. However, getting the right data is only half the battle, what would we use to visualize it(Splunk), and how would we test the solution(CI).
Below are the major components of this talk.
OpenTelemetry: Pulling the data from our systems via Python probes. How we onboard Python developers who were creating the OTel Data to use Splunk to help them visualize the data. How and why we are now changing to GO to push the data from systems.
Splunk: How we built an APM to view this data in Splunk. The performance choices we made for metrics and logs as the business wanted a 10-second dashboard refresh rate.
CI (Jenkins): After Merging the Spunk code into the Murex code we needed a way to test it. We have created a Test inside a CI (Using Jenkins deployed on our Kubernetes) that can take any version of Splunk + Murex and compare the Splunk outputs using Curl.
English 
Français