Where milliseconds translate directly into financial outcomes
This global investment giant operates at the intersection of capital markets and technology. The company acquires assets, facilitates mergers, and executes trades based on real-time financial data sourced directly from Bloomberg terminals and other market feeds. In this ecosystem, a second delay could mean the difference between a profitable trade and a costly loss.
With over 3,500 employees worldwide, a significant portion of the workforce is dedicated to IT infrastructure. The company's internal IT team—spread across three major data centers in North America and in the UK, as well as 50+ global offices—is responsible for keeping mission-critical trading and portfolio management systems operational 24x7.
The firm's IT infrastructure team was recently reorganized, splitting the former network team into a dedicated platform engineering division. Today, the production support team operates Applications Manager 24×7, monitoring the full server and application environment, while OpManager covers network infrastructure including routers, access points, and WAN links across all office locations.
Approximately 300+ new sites were added to the monitored estate, due to a recent company acquisition, underscoring the firm's ongoing need for scalable, centralized visibility across a rapidly growing hybrid ecosystem.
A hybrid, high-stakes environment spanning three continents
The investment firm's infrastructure is a hybrid mix of on-premises Windows servers, Azure cloud VMs, and VMware virtualization. An active cloud migration program is underway, moving vendor-managed applications, away from on-premises hosting. This entire estate is monitored through ManageEngine.
~346 Active Devices (OpManager)
2,000 App Monitor Licenses
Critical application portfolio
The firm's revenue-generating operations depend on three core application systems, all interconnected and latency-sensitive:
Application
| Function
| Hosting Model
| Criticality
|
|---|
Order Management System (OMS)
| Manages and executes trade orders in real time
| On-premises (data center)
| Mission-critical — directly tied to transaction execution
|
IVP Suite
| Investment data processing pipeline; data flows between each component
| On-premises + cloud (multi-region)
| Mission-critical — pipeline failure cascades across all components
|
Proprietary Trading Engine
| Market prediction and revenue generation platform
| SaaS — transitioning to cloud
| Mission-critical — linked to investment decision-making
|
These applications ingest real-time market data from Bloomberg terminals and other marketing feeds. Any latency greater than two to three seconds in the IVP pipeline chain has a direct and measurable financial impact on trading outcomes.
Blind spots in a zero-tolerance environment
Before the current monitoring setup was fine-tuned, the production support team faced a cluster of interconnected operational challenges. In an ecosystem where one minute of downtime costs the equivalent of the company’s entire annual Applications Manager license fee, these were not acceptable risks.
Alert noise at scale
| The environment was generating thousands of alerts per shift. Without careful threshold tuning, the signal-to-noise ratio made it nearly impossible to distinguish genuine critical events from routine fluctuations, leading to alert fatigue and delayed responses.
|
Slow root cause identification
| Without centralized monitoring, pinpointing the root cause required manually logging into individual servers, checking application health, ruling out network issues, and working backwards through the stack ; a process taking 20 to 30 minutes per incident on critical systems.
|
No proactive visibility
| The team had no mechanism to detect resource degradation — rising CPU usage, disk utilization creeping toward thresholds — before it crossed into a service-impacting event. Incidents were reactive rather than preventive.
|
Hybrid infrastructure complexity
| The environment spans on-premises Windows servers, Azure VMs, VMware virtualization , and SaaS applications across multiple geographic regions. Maintaining coherent visibility required a platform that could handle heterogeneous environments from a single console.
|
Parallel tooling fragmentation
| A separate database monitoring tool was operated by a different team, covering only the database layer of the same servers that Applications Manager monitored at the OS and application level. This split ownership created cross-layer correlation gaps.
|
Network latency between regions
| The firm's applications are hosted across multiple cloud regions for high availability. London-based users were at times routed to New York application instances, causing transaction delays . This problem was only diagnose diagnosed with combined application and network-layer visibility.
|
Layered monitoring designed for a zero-tolerance financial environment
The firm uses ManageEngine Applications Manager and OpManager together to provide unified visibility across their entire hybrid estate. The monitoring architecture is deliberately layered: Every server type carries multiple monitors to ensure failures are caught at the most specific, actionable layer possible.
Monitor architecture by server type
Server Type
| Primary Monitor
| Secondary Monitor
| Alert Purpose
|
|---|
Application servers
| IIS monitor (application pools)
| Windows monitor (services, availability)
| OS failures trigger Windows; app-pool failures trigger IIS
|
Database servers (MS SQL)
| MS SQL monitor (jobs, DB services)
| Windows monitor (OS-level services)
| DB job failures trigger MS SQL; Windows service failures trigger Windows
|
Azure cloud VMs
| Azure VM monitor
| Windows monitor
| Cloud resource metrics alongside OS-level health
|
Network devices (offices, data, centers)
| OpManager (SNMP/ICMP)
| —
| Packet loss, link down, device unreachable
|
Alerting and on-call integration
Applications Manager and OpManager are both integrated with PagerDuty, enabling real-time escalation the moment a threshold is breached. Alert routing is shift-aware—the on-call engineer receives a direct phone call, not just an email. Key configuration parameters:
- Poll interval: 5 minutes
- CPU utilization threshold: 75% on high-resource servers (OMS)
- Disk utilization action threshold: 25% on database servers
- Suppression mechanism used during planned maintenance across 60+ office estate
From thousands of alerts to under 90 per day
Through systematic threshold tuning, monitor configuration refinement, and baseline establishment, alert volume has been reduced from thousands per shift to approximately 90 actionable alerts per day. A reduction of well over 90%. This has eliminated alert fatigue and ensured every alert drives action.
Before we used to get around thousands and thousands of alarms, and now we are getting around 50 to 90 alarms per shift. That is a huge improvement for us.
- Senior Infrastructure Engineer, Production Support
A CPU spike, a transaction delay, and a five-minute resolution
Approximately one month before this case study was conducted, the production support team responded to one of the most illustrative incidents in their recent history—a CPU utilization spike on the OMS server directly causing transaction delays for the trading team.
Incident timeline
Detection
| Applications Manager detected CPU utilization on the OMS server crossing the 75% threshold. A PagerDuty alert fired immediately, reaching the on-call engineer via direct phone call.
|
Correlation
| Simultaneously, the trading operations team escalated that they were experiencing delays in transaction processing. The infrastructure team and the trading team converged on the same issue within minutes.
|
Root Cause
| Applications Manager had already surfaced the CPU spike as the triggering event. Root cause identification required no manual investigation. The alert named both the server and the resource metric responsible.
|
Resolution
| The issue was remediated within five to 10 minutes of initial detection. Transaction processing returned to normal. Without Applications Manager, the same investigation would have taken 20 to 30 minutes.
|
Before vs. after: Resolution comparison
WITHOUT APPLICATIONS MANAGER
| WITH APPLICATIONS MANAGER
|
|---|
Manual login to OMS server required
| PagerDuty phone call fired within five 5 minutes of breach
|
Manual review of task manager, event logs, service state
| Alert identified server, monitor type, and metrics automatically
|
Network layer ruled out separately
| Root cause confirmed without manual investigation
|
Application vs. server cause by elimination
| The T t eam converged on fix immediately.
|
Estimated resolution time: 20—30 minutes
| Actual resolution time: five 5 —10 minutes
|
Financial exposure: m M ultiples of annual license cost
| Financial exposure: E liminated before material impact
|
In one minute of downtime, we are making a loss that is equal to the entire yearly cost of the ManageEngine license we are paying. That is why keeping this infrastructure up is absolutely essential.
- Senior Infrastructure Engineer, Production Support
Active capabilities and the roadmap ahead
The team actively uses a focused set of Applications Manager and OpManager capabilities tuned to their operational requirements. Several advanced features represent a near-term expansion opportunity.
Feature
| Status
| Purpose & Configuration
|
|---|
Windows monitoring
| Active — all servers
| Service availability, OS-level health, triggered via PagerDuty on all server types
|
IIS / application pool monitoring
| Active — a pp servers
| Application pool state for OMS, IVP, and Proprietary Trading Engines ; alerts on pool failures independent of Windows layer
|
MS SQL monitoring
| Active — DB servers
| Job execution status, database service health, alerts on failed or delayed jobs
|
URL monitoring
| Active — all critical apps
| Five -minute poll interval; immediate PagerDuty escalation on availability failure
|
Azure VM monitoring
| Active — cloud estate
| Cloud VMs monitored alongside on-prem ises in the same Applications Manager instance
|
PagerDuty integration
| Active — full estate
| Shift-aware routing; voice calls to on-call engineer; covers both Applications Manager and OpManager
|
Capacity planning reports
| Active — regular cadence
| CPU, memory, and disk trend reports used for resource decisions and infra investment planning
|
Threshold alerting
| Active — per server class
| CPU: 75% on high-resource servers; Disk: 25% action threshold on DB servers
|
Anomaly detection
| Partial — selected servers
| Configured on certain servers; identified as an area for broader rollout
|
Digital Experience Monitoring
| Available — not yet in use
| Real user monitoring and synthetic transaction monitoring are licensed but not yet deployed
|
Root cause analysis
| Available — not yet in routine use
| Identified as a capability the team wants to explore further in a dedicated product session.
|
