May 20, 2021

Chris Polston, Director, Support Services

“Why did that issue happen again?! I thought you fixed it.”

“Do you know why the system is slow…again?”

If you’re on the team charged with supporting an ERP system like JD Edwards (JDE) World or EnterpriseOne, you’re very likely to have heard the again questions from frustrated executives, business leaders, and end users. For years, questions like these were key indicators that I was about to have a Bad Day.

I know now that I could have prevented these situations if I had built observability into the system. Let me explain.

What Is Observability?

In technology, observability is defined as your ability to determine the internal state of a system through its external outputs. Observability uses all the outputs you have – logs, traces, data – and so is what gives you the deeper insights needed to answer those tough questions. That’s why it’s not limited to just monitoring.

In every ERP maintenance job I’ve held, there were varying levels of monitoring. I could see if the CPU on a given server was running hot, network activity, and bandwidth utilization. But while monitoring is a requirement for observability, that is only the beginning.

You do need the data from logs, tracing, and metrics. But to answer the again questions on the spot, you also need the ability to troubleshoot your system as it is working. And that’s the great benefit of observability.

JD Edwards and Observability

A JDE system is complex. It takes several servers to operate, and then there are the integrations and customizations. You are also likely to have other applications like your database, and certainly your network backbone, making use of resources. Hopefully, that is all documented. But even that is a static and somewhat abstracted view of the system.

In real life, the system is dynamically changing every hour of the day. This makes it very challenging to see into the system and know what is occurring at any given moment (observability!). With hard work and some luck, you might be able to sift through the logs to determine what happened. That’s assuming the correct logs were saved during an incident.

How We’re Addressing This for Our Customers

At Spinnaker Support, we have chosen a different path, one that leads to an observable system. Using LogicMonitor, we collect and monitor data in real time. LogicMonitor sends alerts to the responsible parties when a metric or event goes out of bounds. It also holds all the data collected for one year, enabling comparisons between events, forecasting future workloads, and trend analysis to prevent issues from ever occurring.

For example, let’s say alerts start coming from the database about connections and memory. This is followed by alerts from the Enterprise server that kernels are losing database connectivity. With these real-time alerts, the Spinnaker Support team and the customer’s DBA can respond proactively to an imminent E1 outage.

We notify the business that they need to wrap up current work and get ready for a restart. The observed alerts inform everyone that the database issues are the underlying cause of the E1 outage. LogicMonitor keeps the real-time metrics for one year of historical baseline and review so that the teams can perform root cause analysis and conduct comparisons if any system changes are made in response to the outage. This combination of monitoring and observability leads to greater uptime and increased confidence and satisfaction for executives, business leaders, and end users.

With a team certified in managing LogicMonitor, we are ready to help your organization get ahead of issues that would impact your business’s use of JD Edwards. If you would like to discuss how we can help, reach out and ask.