CASE STUDY

Unified Observability Across Solaris, WebLogic and Oracle for a Leading Small Finance Bank

Ashnik Team

  • Industry :
    Banking & Financial Services
  • Technology:
    Elastic Observability (Elastic Java APM, Elasticsearch, Kibana), Oracle Solaris 11.4, Oracle WebLogic/SOA, Oracle Database 19c, Oracle HTTP Server, JMX/Jolokia
  • Engagement :
    Proof of Concept, Architecture Validation & Enterprise Observability Assessment
THE CUSTOMER

A leading small finance bank in India with a wide and important banking services footprint. Part of that estate runs on a mature enterprise stack: Oracle Solaris, Oracle WebLogic and SOA workloads, Oracle Database 19c, Oracle HTTP Server and a set of related application components.

THE SOLUTION

A hybrid, low-impact collection pattern. Elastic Java APM on WebLogic, JMX/Jolokia for middleware runtime metrics, Solaris-native telemetry through kstat, normalised log forwarding with multiline logic, and Oracle monitoring through controlled read-only SQL access, all correlated in Elastic.

THE CHALLENGE

The standard Elastic Agent and commonly used Beats collectors weren’t available as a supported pattern on Solaris. The bank needed application-to-database observability without adding unsupported software or introducing operational risk.

THE RESULT

A proof of concept that delivered one common observability layer spanning the Java application, WebLogic middleware, Solaris operating system and Oracle database, plus a repeatable architecture and an evidence-based blueprint for a phased enterprise rollout.

4

Observability domains covered: logs, metrics, APM and database telemetry

~200

Applications assessed across the enterprise landscape (approximate)

~50

Tier-one applications considered for the initial phase (approximate)

~20 TB/day

Projected enterprise ingestion, a sizing estimate

Customer Overview

The customer is a leading small finance bank in India with a wide and important banking services footprint. Part of that estate runs on a mature enterprise stack: Oracle Solaris, Oracle WebLogic and SOA workloads, Oracle Database 19c, Oracle HTTP Server and a set of related application components.

The bank wasn’t just looking to install a monitoring tool. It wanted to know whether Elastic Observability could give it one common operational view across applications, middleware, operating systems and databases, including technology that didn’t have a native Elastic collection agent to begin with.

The Challenge: Observability Without a Native Agent

A leading small finance bank in India wanted one operational view across a business-critical stack built on Oracle Solaris, Oracle WebLogic and Oracle Database. The catch: the standard Elastic Agent and Beats collectors, the usual starting point for Elastic Observability, weren’t available as a supported pattern on Solaris. Ashnik was brought in to work out whether unified observability was even possible here, and if so, how to get there without disturbing a mature, business-critical estate.

What followed was a proof of concept and a broader enterprise assessment that gave the bank a working answer, and a blueprint for scaling it up. Four things stood in the way of a straightforward rollout:

No supported agent model for Solaris

The standard Elastic Agent and commonly used Beats collectors couldn’t simply be deployed on Solaris. Ashnik needed a Solaris-native collection strategy, rather than forcing Linux-oriented collectors onto a business-critical estate.

Visibility needed to go well beyond log search

The bank needed insight into Java transactions, response behaviour, errors and exceptions, JVM performance, WebLogic runtime health, infrastructure utilisation, database health, and middleware and OS logs. No single telemetry mechanism covered all of that on its own.

Security and operational impact were non-negotiable

Oracle monitoring had to run on controlled, read-only access to performance information, and collection on Solaris had to stay lightweight, relying on existing OS capabilities wherever possible.

Enterprise logs needed careful normalisation

WebLogic, SOA and Oracle logs often generate multiline events. The ingestion path had to keep Java stack traces and diagnostic records intact as single logical events, while still handling rotation, offsets and collector restarts cleanly.

Ashnik’s Approach: A Hybrid, Low-Impact Pattern

The underlying design question was simple to state and harder to answer: how do you get application-to-database observability across a specialised Solaris and Oracle stack, without adding unsupported software or introducing operational risk?

Rather than trying to force a standard collection model onto the Solaris estate, Ashnik designed a hybrid approach that met the platform where it was:

01
Separated collection from the central platform
Elastic’s ingestion, search and visualisation components were positioned on supported infrastructure. The Solaris environment only had to export the telemetry needed for central analysis.
02
Instrumented WebLogic with Elastic Java APM
Java processes were instrumented to expose transactions, response behaviour, errors, exceptions and JVM indicators, including memory, garbage collection and runtime activity.
03
Extended middleware visibility through JMX/Jolokia
This complemented APM with WebLogic-specific runtime metrics, opening up thread pools, JDBC resources, connection pools, server health and application runtime behaviour.
04
Used Solaris-native telemetry mechanisms
kstat and lightweight collection logic captured CPU, load, memory, filesystem, swap and ZFS ARC visibility, keeping the on-host footprint low.
05
Normalised and forwarded application and system logs
WebLogic, SOA, Oracle HTTP Server, database and Solaris logs were transported through existing or lightweight forwarding mechanisms, with multiline logic preserving complete events, stack traces included.
06
Monitored Oracle through controlled SQL access
A dedicated read-only model exposed selected performance, system, tablespace, memory and system-statistics views, without handing out broad database privileges.
07
Correlated everything in Elastic
Logs, metrics, APM and database signals came together to support one connected investigation path, from transaction to JVM, to middleware, to host, to database.

A Publication-Safe View of the Architecture

The architecture below has been simplified for external sharing. It preserves the design logic while leaving out internal identities, addresses, credentials and other security-sensitive implementation detail.

case study oracle 1

At a glance, the architecture works like this:

  • Elastic Java APM captures application transactions and JVM behaviour from the WebLogic environment.
  • JMX/Jolokia adds a complementary path for middleware-specific runtime metrics.
  • Solaris-native mechanisms collect host metrics and logs with a lightweight footprint.
  • Oracle Database metrics are collected through controlled, read-only SQL access.
  • Secure forwarding carries telemetry to the supported Elastic ingestion layer.
  • Elasticsearch and Kibana provide the central search, dashboards and cross-layer correlation.
The guiding principle throughout: don’t force the monitoring platform onto the legacy workload. Bring the workload’s telemetry into a supported monitoring platform instead.

Assessment Scope and Sizing

Alongside the PoC, Ashnik ran a broader observability assessment to understand what a full enterprise rollout would look like. These are planning inputs and projected figures from that sizing exercise, not achieved production throughput or a completed rollout.

AREA FIGURE
Enterprise application landscape approximately 200 applications assessed
Initial enterprise phase approximately 50 tier-one applications considered
Projected enterprise ingestion approximately 20 TB/day — a sizing estimate, not achieved throughput
Elastic resource sizing approximately 50 ERUs — an assessment estimate
Platform validated in the PoC Oracle Solaris 11.4, Oracle WebLogic/SOA and Oracle Database 19c
Host telemetry validated CPU, load, memory, filesystem, swap and ZFS ARC
PoC collection interval approximately one minute for host metrics
Observability domains covered logs, metrics, APM and database telemetry
Enterprise planning areas ingestion, retention, dashboards, correlation and resource sizing

What the PoC Demonstrated

Unified application-to-database visibility

Elastic provided one common observability layer spanning the Java application, WebLogic middleware, Solaris operating system and Oracle database.

A practical answer to the Solaris observability gap

Not having a supported native Elastic Agent for Solaris didn’t mean abandoning the platform or re-platforming the application. A lightweight telemetry architecture gave the bank another path.

Deeper troubleshooting than log monitoring alone

Elastic APM added transaction- and JVM-level visibility, helping teams move from “WebLogic reported an error” to understanding which transaction was affected and what was happening inside the JVM.

Database health in the same operational picture

Selected Oracle performance indicators were gathered through controlled read-only access and correlated with infrastructure and application behaviour.

A repeatable architecture for a wider rollout

The PoC established a reusable design pattern and generated evidence for wider application assessment, retention planning and Elastic resource sizing.

Business Impact

In a banking environment, observability creates value by shortening the path from “there is an issue” to “this is where the issue originated.” This engagement laid the foundation for a connected troubleshooting journey across transaction, JVM, middleware, host and database. In practice, that means:

  • A shared telemetry foundation for application, middleware, infrastructure and database teams.
  • Less dependence on isolated tools and disconnected troubleshooting workflows.
  • Faster fault isolation, by connecting service symptoms to the underlying technology layer causing them.
  • Protected investment in the established Solaris and Oracle estate, while still introducing modern observability.
  • An evidence-based blueprint for a phased enterprise rollout and sizing exercise.
The bank didn’t have to choose between keeping a proven Solaris/Oracle estate and adopting modern observability. With the right architecture, the two coexist.

Conclusion

Observability is fairly straightforward when every workload sits on a modern, natively supported platform. It gets harder when a business-critical application runs on Solaris, WebLogic and Oracle Database, and the standard collection agent simply isn’t available for the operating system.

Ashnik addressed that by redesigning the collection architecture around the workload, not the other way round. Elastic APM, Java instrumentation, Solaris-native telemetry, controlled database monitoring and centralised log analytics came together into one coherent observability model. The PoC showed that organisations can modernise how they monitor and troubleshoot established enterprise applications, without re-platforming those applications first.

Legacy infrastructure doesn’t have to mean legacy visibility. A carefully designed observability layer can connect modern monitoring capabilities with specialised or mature technology estates.

Ready to bring unified observability to your Solaris, WebLogic or Oracle estate? Let’s talk.