← All case studiesEnergy · Elastic consulting

Case study

Observability Unified for Two Divisions of a Global Energy Technology Company

How SquareShift designed, secured and scaled observability across two engineering divisions of a global energy technology company, covering about 10,000 remote endpoints, with service levels tied to real user workflows.

Book a session →
~10,000remote endpoints covered by one reusable agent policy
Zeroplatform endpoints left open to the public internet
180days of searchable history kept, with storage cost controlled

Client

A global energy technology company with two engineering divisions, each running its own observability deployment in the cloud.

Industry

Energy

Services

ObObservability & ReliabilitySeSecurity & Compliance

Stack

Elasticsearch · Kibana · Elastic Cloud · Fleet · Elastic Agent · Index Lifecycle Management (ILM) · Snapshot Lifecycle Management (SLM) · Searchable Snapshots · Watcher · Cross-Cluster Replication · Elastic Common Schema (ECS) · OpenID Connect · Network Packet Capture · Grafana · Prometheus · RabbitMQ

How SquareShift delivered it.

01

The challenge

The client has two engineering divisions, and each ran its own observability deployment in the cloud. Both collected logs and metrics from remote engineering desktops, central applications and cloud platform services. Daily ingest grew from about 1 TB to nearly 3 TB during the engagement, on hardware, shard counts and lifecycle settings chosen for a much smaller estate.

An earlier proof of concept had lost metrics and tracing data. Service-level indicators were computed in real time but not kept, so periodic service reporting was not possible. Location lookup by IP address failed, because every remote desktop sat behind private addressing. Each tenant's data had to stay separate without a sprawl of indices, and key infrastructure views still lived in Grafana.

02

What we delivered

SquareShift ran the two divisions as parallel workstreams on one shared architecture, security model and lifecycle standard. The team designed a two-zone cluster with a third-zone tiebreaker that prevents split brain, and documented and validated two disaster recovery patterns. Every platform endpoint was limited to private network connectivity, with OpenID Connect single sign-on and role-based access down to document level.

Sizing models were re-run as ingest grew, and the production cluster moved to a CPU-optimised hardware profile. Data streams were sorted into three volume tiers, each with its own shard and lifecycle policy, ending in a frozen tier that keeps 180 days of searchable history. One reusable agent policy with twelve integrations, rolled out through the Fleet API, covered the whole endpoint estate.

Service-level objectives were defined against real user workflows in the divisions' engineering applications, with burn-rate alerts. Scheduled watchers kept the indicator history in a dedicated index. Network packet capture gave visibility from desktops behind private addressing. Grafana and Prometheus views were mapped field by field to Elastic Common Schema and moved into Kibana, and each division received production alert rules and custom dashboards. For observability across divisions and teams, see our Elastic search and observability services.

03

The outcome

Both divisions now work to one observability standard, sharing architecture, security and data lifecycle while keeping tuning specific to each. Service levels are measured against the workflows users actually use, and the kept history supports monthly, quarterly, half-yearly and annual reporting. A capacity plan runs to more than 10 TB a day, about five times current ingest, so scaling is planned and budgeted.

No platform endpoint is open to the public internet. The telemetry gaps from the proof of concept are closed. A full production health review found every tier healthy, with heap and disk inside recommended limits and no thread pool rejections. Engineering and operations teams share one set of Kibana dashboards, and the client's own operations team now runs both deployments day to day.

“
Service levels only support reporting when their history is kept. The platform computes the indicators live but does not store them, so we built that store.

Observability & Reliability Practice Lead, SquareShift

Related work