Sauron Architecture

This page shows how Sauron endpoints, routing, metrics, logs, and alerts fit together. For a specific task, start with its task guide.

Component	Role in the architecture
Sauron instance	The isolated set of Sauron deployments, services, storage, and ingress for one service team environment.
Ingress, load balancer, and DNS	Route customer traffic to the correct Sauron endpoint.
Grafana	Displays dashboards and panels backed by Sauron metrics data.
Prometheus and Thanos	Scrape, store, evaluate, and query metrics.
Alertmanager	Routes metric alerts to configured receivers.
OpenSearch and OpenSearch Dashboards	Store, search, and inspect logs.
API Server and Console	Provide supported configuration/status APIs and browser-based Sauron status views.
Sauron Operator	Reconciles the Kubernetes resources that make up a Sauron instance.

Customer Endpoint Flow

For each Sauron instance, Sauron creates its own deployments, services, storage, and ingress. Traffic from a browser or client reaches an endpoint through the load balancer, DNS, ingress, and then the backend pod for that component.

At a high level:

1. An OCI load balancer fronts the ingress controller.
2. DNS records route Sauron endpoint hostnames to that load balancer.
3. The ingress for a Sauron instance defines the enabled frontend endpoints, certificates, and authentication behavior.
4. Requests pass through the load balancer and ingress controller.
5. The ingress routes requests through Kubernetes services to the backend pods.

This is the routing pattern, not a promise that every instance has the same load balancer or authentication settings. Use Console Endpoints for this instance's enabled URLs.

Network Architecture

For a network review, trace the browser or client to its Sauron hostname, then through the load balancer and ingress to the enabled component. Ask the Sauron team for the current region, source and destination ranges, and tenancy boundary for your instance. Older static network diagrams can use component names or addresses that no longer match a deployed Sauron.

Metrics And Alert Flow

Sauron uses Prometheus for metrics collection, querying, and alert rule evaluation. Prometheus works with exporters, Alertmanager, Thanos, and Grafana.

Prometheus at a high level does the following:

• Scrapes metrics data from exporters and configured targets.
• Stores metrics data in its time-series database.
• Evaluates alert rules and sends firing alerts to Alertmanager.
• Returns metrics for clients such as Grafana and Thanos.

When alert conditions are satisfied, Prometheus sends alert notifications to Alertmanager. Alertmanager then routes those alerts to the configured receivers. Grafana and Thanos query metrics data for dashboards and analysis.

Operator View

These diagrams illustrate the operator design. Ask the Sauron team to confirm current platform dependencies; labels such as DNS or certificate providers may reflect an older deployment.

The Sauron Operator manages the Kubernetes resources for Sauron instances. It watches the Kubernetes API for Sauron resources and reconciles the deployments, services, persistent volume claims, and ingress needed for each instance.

When the Sauron Operator runs in Hyper Operator Mode, it launches a Sub-Operator for each Sauron instance. Each Sub-Operator is a regular Sauron Operator running in Standard Mode, scoped to one Sauron instance.

Operator Ecosystem

The Sauron Operator works with other platform components that support Sauron instances:

• Operator-side admin console: used by cluster administrators to create and manage Sauron instances.
• Mandos Storage Manager: manages backup, restore, and data storage-related operations for Sauron instances.
• Cert Manager: handles automatic certificate generation.
• External DNS Manager: registers DNS entries.
• External Site Monitor: handles external site monitor registration.