Monitoring Oracle Goldengate Monitoring / Oracle Enterprise Manager & the pluging & JAgent

In complex enterprise environments, the greatest danger lies in the failure.. But! the delay between a failure occurring and its detection is also very important. The longer it takes for detection to occur, the greater the impact of the problem will be. When dealing with an engine (like Oracle GoldenGate) responsible for moving crucial data, this delay translates directly into financial exposure and data divergence. Our recent project focused entirely on eliminating this blind spot, achieving a reliable, centralized view of OGG's operational state.

Monitoring is not a luxury; it is necessary for managing highly available, complex systems. Oracle  Goldengate is such a critical system. It's a bridge, where data passes between systems, and very critical tasks are then performed using that data. By implementing OEM 13.5 GoldenGate Plugin and JAgent, we can properly monitor Oracle Goldengate (OGG) landspace(s) -- even if we are using OGG in the classical mode (non-microservice mode). 

With this approach, we also have the capability of  doing the level 1 administration of our OGG environment (s) through a web-based GUI.

So, as mentioned, the tool we positioned for monitoring OGG was Oracle Enterprise Manager (OEM) Cloud Control 13.5. This is not just a dashboard; it is a central monitoring solution for our databases, middleware, and, the entire OGG environment.

We specifically deployed the OGG-EM-Plugin into OEM for this task. This plugin delivers centralized visibility into all OGG environments.

To achieve the visibility, one must establish a standardized communication path between OGG processes and management console. This path is realized through a layered agent architecture.

The OGG processes periodically generate monitoring points. These are essential data points such as status, lag, and checkpoints.

Then, these monitoring points are sent to the GoldenGate Monitor Agent, named JAgent. This agent is installed on both the source and target database servers and is kept up-to-date with the latest patch bundle(s). The JAgent's role is to collect the data from the local GoldenGate environment.

The JAgent then communicates the collected monitoring data to the standard OEM Agent. And finally, the OEM Server, empowered by the GoldenGate Plugin, receives the data.

Once the architecture is in place, the OEM Server transforms raw data into actionable intelligence. 

The GoldenGate Plugin allows us to populate dashboards with crucial performance indicators (like status, lag, and total operations) and automatically trigger alarms when metrics reach predefined thresholds. OEM also give us the capability of administering the OGG processes (this includes: initiating a stop/start action for any process, and checking alerts and errors on the processes)

We can also make configuration changes to already running parameters.

The resultant dashboards provide status updates. For instance, we can clearly see the Lag for all Extracts and Replicats, allowing quick identification of bottlenecks. By drilling down into a specific Extract, we can see fine-grained metrics, such as Checkpoint Position Delta Operations Per Second, and detailed operational counts (Inserts, Updates, Deletes).

OEM delivers us a web-based central for monitoring and administrating OGG, and it shifts our operation from a reactive to a proactive centralized model. 

We implemented this in one of our data analytics projects, and I can say it performed quite well. 

Things are a little different with the new microservice-based OGG platform. I'll examine that in another article.