Transaction monitoring with Pandora FMS 7.0 NG
This post is also available in: Spanish
Introduction to transaction monitoring
One of the new functions that Pandora FMS 7 NG includes in this new iteration is business transaction monitoring, a tool for monitoring business processes, based on harvesting data from each point in a transaction process, using flexible and customizable software .
Let’s take a look at a practical case to get a better understanding of how Pandora FMS transaction monitoring works.
Let’s say you want to monitor a business process from start to finish: the process begins when an order is received, whether B2B or B2C. This order then enters the system where it’s processed and then saved on the database. The final step is a confirmation email sent to the logistics department.
Pandora FMS monitors the entire process, each distinct phase, and collects the feedback for posterior analysis (later we’ll look at how this data is treated and presented).
To correctly configure a transaction process, some preliminaries are necessary:
- A prior analysis of the process you wish to monitor:
- From which elements and components you’re going to collect the data.
- Deployment of transaction agents on the necessary hardware to control the flow of information:
- Development and deployment of control scripts on any necessary transaction agents.
- Create the transaction by introducing the data in the corresponding web forms, via the Pandora FMS console
The first thing to monitor is the web portal, where the order is received. The next step is to monitor the EMI01 machine that receives the order and initiates a process to identify that order and establish the corresponding actions. The third step is to check that the order has been successfully saved in the database, by monitoring the ORAMON machine’s status, where the Oracle database is located. The final step is to find out if the logistics department’s inbox has received an email with details of the order, by checking the mail server.
The transaction monitoring system allows you to control the whole order process, and detect if there are any problems during any of the phases.
For optimal performance, establish a framework with dependent elements, meaning that no intermediate phase can be analyzed until the previous phase has successfully completed, allowing the user to time each phase and the whole transaction.
By installing transaction agents the user can control each element or component in the transaction process individually, as well as each distinct phase, all directed by the transaction server, which tasks each agent with carrying out its checks only once the previous step has been completed, based on the dependent relations mentioned above.
The prior analysis has been carried out, you know which elements and components you’re going to use to collect data from, as well as the route each order must follow. Now it’s time to execute the critical script known as the transaction trigger.
There are four phases in the example, and each phase requires a script:
- Transaction trigger: leaves a fictitious order on the web portal in order to provide an example to track throughout the process.
- Control script: searches for a chain in a log file.
- Control script: queries the database
- Control script: confirms whether there is mail in the logistics inbox.
Once the scripts are prepared, install a transaction agent on each machine (or on remote machines able to intervene at the control points). When the agents and scripts are ready, create the transaction from the Pandora FMS console so the server can begin to work. Go to the corresponding service, the new Transactional map.
When the agents and scripts are ready, create the transaction from the Pandora FMS console so the server can begin to work. Go to the corresponding service, the new Transactional map.
Create the new transaction by filling out the form.
Each step in the transaction is known as a phase. Once the transaction has been created, you can proceed to define each phase in order to create a tree chart. Indicate here which agent is tasked with executing the control script, as well as the route the script must take within the agent. Also define the dependency relationships.
Once the transaction has been defined you only have to launch the execution from the Pandora FMS console and observe its progress:
As you can see in the screenshot, relations can be defined as one-to-many, not only one-to-one:
Apart from the transaction graphs, all the data is collected in the form of modules, which are saved on a specific agent (configured when the transaction is created).
– Create alerts for business processes and/or each phase of the same.
– Present graphs with historic data (times, values, etc.).
– Generate reports with statuses retrieved from the modules.
– Generate comparative and individual graphic reports of every kind.
– Generate SLA reports, to measure service quality and availability.