Full-Stack Visibility with Guardrails

How Apto Solutions designed and deployed a unified observability platform for a fintech business — combining real-time metrics and traces with governed log access across a regulated, multi-region Kubernetes environment. 

The Situation 

Our customer is a UK-regulated capital markets platform that gives retail investors fair access to public market transactions. Operating across AWS Elastic Kubernetes Service (EKS) clusters in the UK and France, The platform is built on microservices and depends on a range of third-party SaaS providers — from Cloudflare CDN to MongoDB Atlas and HubSpot. 

As the platform scaled, the engineering and operations teams needed genuine observability: real-time visibility into how their infrastructure was performing, how their applications were behaving, and the ability to investigate incidents without switching between disconnected tools. However this customer was not a standard technology business. As a regulated capital markets platform, it has strict obligations to its clients, issuers, and regulators — including controls to prevent insider trading and market manipulation. That meant any observability solution also had to enforce rigorous data governance, ensuring that market-sensitive production data was only accessible to the people authorised to see it. 

Apto Solutions was engaged to design and implement a solution that could deliver both: full-stack observability and non-negotiable data controls. 

 

The Challenge 

The particular requirements of this project presented a set of technical and governance challenges that had to be solved together rather than independently:  

• Fragmented visibility: metrics, logs, and traces from five Kubernetes clusters and multiple third-party SaaS tools had no unified home. Engineers investigating incidents had to correlate data from separate systems manually. 

• Strict data segregation: production data — including data that may be privileged under market abuse regulations — could not be exposed to staff without a specific, time-bound authorisation. The customer categorised its technical staff as permanent “Insiders”, permanent “Outsiders”, and temporary Insiders, and the platform had to reflect and enforce those categories. 

• Planned development overhead: The Customers initial approach to access control involved building custom API and Terraform automation to manage user permissions programmatically. This would have required significant engineering effort before the platform could go live. 

• Multi-region complexity: clusters across London and Paris needed to be treated as first-class citizens in the architecture, with data correctly routed, indexed, and governed regardless of origin. 

• Third-party data gaps: an early telemetry discovery exercise, mapping every data source across the estate, surfaced SaaS tools playing key roles in the platform — including HubSpot for CRM and GitLab for source control — that sat entirely outside any observability platform. 

 

The Apto Approach 

Apto designed a unified architecture built on two complementary Splunk platforms — Splunk Observability Cloud for real-time metrics and trace data, and Splunk Cloud for log storage and search — connected so that engineers could work across both without leaving a single interface. The result gives the team all three pillars of observability, logs, metrics, and traces, correlated in one place rather than scattered across disconnected tools. 

Dual Observability Platform Design 

At the heart of the solution is an OpenTelemetry (OTel) collector deployed into each of  five Kubernetes clusters. The OTel collector serves as the single collection mechanism for all telemetry data — routing metrics and traces to Splunk Observability Cloud, and logs to Splunk Cloud. Standardising on OTel, rather than platform-specific agents, also means the customer’s instrumentation is decoupled from either Splunk product, preserving the option to route data elsewhere in future without re-instrumenting a single service. 

Integrated Log Access via Log Observer Connect 

The two Splunk platforms are integrated via Log Observer Connect, which allows engineers working within Splunk Observability Cloud to access the corresponding log data stored in Splunk Cloud — directly within the same interface. When an alert fires or a metric threshold is breached, the engineer can pivot immediately to the relevant logs without switching tools or re-authenticating. 

RBAC and SSO Without Custom Development 

Both Splunk platforms are integrated with Azure Active Directory via SAML, with Splunk roles mapped directly to existing Azure AD groups. Since this customer already had processes to move users in and out of AD groups based on their operational schedule — determining who should have production access and when. Rather than building new automation to replicate that logic inside Splunk, Apto’s architecture delegates entirely to the existing AD controls. 

Index Structure and Best Practice Configuration 

Apto designed a structured index scheme aligned to the production and non-production environments: separate indexes for UK and France clusters in both production and non-production, plus dedicated indexes for AWS-sourced data and operations. The scheme reflects a clear view of where each source sits in value and sensitivity terms, the same classification thinking that underpins any well-planned data mapping exercise, and gives fine-grained access control while remaining manageable as the platform grows. 

Configuration is managed via a custom Splunk application (pb_all_indexes), developed by Apto and maintained in source control, with the package and code handed over to at the close of the engagement. This follows Apto’s standard best practice for index management, providing a versioned, auditable mechanism to evolve the index structure over time. 

Custom Dashboards and Third-Party Integrations 

Apto built a custom Splunk PB application as a landing environment for dashboards and reports. Two dashboards were delivered at go-live: one providing an overview of application error rates and warning volumes across environments, and one displaying log ingest consumption broken down by environment and source type, giving the team ongoing visibility into which sources were actually driving cost, not just what was flowing through the pipe. 

Data ingestion from third-party providers was also designed and integrated — with HubSpot and GitLab Technical Add-ons developed by Apto to bring external SaaS data into Splunk Cloud under the same index and access control framework. 

 

Outcomes and Value Delivered 

The completed implementation gave the customers engineering and operations teams the observability platform they needed — without compromising the data governance obligations that their regulated status demands. 

The architecture Apto delivered is not a point-in-time solution. The index management application, SAML integration, and OTel collector configuration are all designed to be extended as the platform grows — adding new clusters, environments, or third-party integrations without requiring a redesign of the underlying data governance controls. It is a deliberately pipeline-first design: because collection, routing, and indexing were built as a coherent layer rather than bolted on around a single platform, the architecture can absorb change without rework.