Chapter 1. Choose your deployment scenario


Before planning your OpenShift Logging installation, choose which deployment scenario fits your requirements. Your scenario choice determines which components to install and which planning steps are relevant.

1.1. Understanding deployment scenarios

OpenShift Logging supports three deployment scenarios based on which components you install:

  • Scenario 1: Vector only - Forward logs to external systems without local storage
  • Scenario 2: Vector + Loki - Local log storage plus optional external forwarding
  • Scenario 3: Vector + Loki + COO - Full observability stack with console UI

Your scenario choice acts as a gate: some planning topics only apply to scenarios that include Loki or the Cluster Observability Operator (COO). Use this guide to identify which scenario fits your needs, then follow the relevant planning topics.

1.2. Scenario decision matrix

Compare the three OpenShift Logging deployment scenarios across key decision factors to determine which best fits your infrastructure and requirements.

Decision FactorScenario 1: Vector onlyScenario 2: Vector + LokiScenario 3: Vector + Loki + COO

Primary use case

Forward logs to existing external platform

Local troubleshooting + optional external forwarding

Complete observability in OpenShift console

Local log storage

No

Yes (30 days max)

Yes (30 days max)

Query interface

External platform UI (Splunk, CloudWatch, etc.)

Grafana or Loki CLI

OpenShift web console "Logs" tab

Object storage required

No

Yes (S3, GCS, Azure Blob, or compatible)

Yes (S3, GCS, Azure Blob, or compatible)

Resource requirements

Lowest (Vector DaemonSet only)

Medium (Vector + Loki components)

Highest (Vector + Loki + COO + monitoring stacks)

Operators to manage

1 (Red Hat OpenShift Logging Operator)

2 (Logging + Loki)

3 (Logging + Loki + COO)

Planning complexity

Simplest (configure destinations only)

Moderate (sizing, object storage, retention)

Complex (sizing, storage, multi-tenancy, UI plugins)

1.3. Scenario 1: Vector only (forward-only)

Use Scenario 1 if you want to forward logs to an external system without storing them locally in your cluster.

Choose this scenario if:

  • You already have a centralized log management platform (Splunk, ELK, Datadog, etc.)
  • You do not need local log queries in OpenShift
  • You want minimal resource usage in your cluster
  • Setting up object storage in your cluster is not feasible
  • Compliance requires all logs to go to an external system immediately

What you need to plan:

  • External log destination configuration (CloudWatch, Splunk, Kafka endpoints, credentials)
  • Network connectivity from cluster to external systems
  • Log retention policies on the external platform
  • Log filtering and transformation rules (if needed)

What you do NOT need:

  • Object storage setup
  • Loki sizing calculations
  • Query performance tuning
  • Console UI configuration

Resource requirements:

  • CPU: Vector DaemonSet uses ~100m CPU per node (varies with log volume)
  • Memory: Vector DaemonSet uses ~128-256 MiB per node
  • Storage: No persistent storage required (Vector buffers in memory)

Estimated installation time: 15-30 minutes

Go to these planning topics:

  • Plan your logging installation

Skip these planning topics:

  • Choose a LokiStack storage backend (not applicable)
  • Size your LokiStack deployment (not applicable)

1.4. Scenario 2: Vector + Loki

Use Scenario 2 if you need local log storage and querying in addition to optional external forwarding.

Choose this scenario if:

  • You need fast local queries for troubleshooting recent issues
  • 30-day log retention is sufficient for your operational needs
  • You have or can provision S3-compatible object storage
  • You want to use Grafana or LogQL for log analysis
  • You may also forward logs externally for long-term retention

What you need to plan:

  • Object storage backend (Amazon S3, Google Cloud Storage, Azure Blob, OpenShift Data Foundation, or S3-compatible)
  • Object storage capacity (log volume determines storage needs)
  • LokiStack deployment size (1x.demo, 1x.pico, 1x.extra-small, 1x.small, or 1x.medium)
  • Cluster resources (CPU, memory, persistent volumes for Loki components)
  • IAM roles or service accounts for object storage access
  • Log retention period (up to 30 days)
  • External forwarding destinations (if also forwarding logs)

What you do NOT need:

  • Console UI configuration (query using Grafana or Loki CLI)
  • Multi-tenant monitoring setup
  • Signal correlation configuration

Resource requirements:

  • Vector: Same as Scenario 1 (~100m CPU, 128-256 MiB memory per node)
  • Loki: Depends on deployment size:

    • 1x.extra-small: 5 vCPUs, 7.5 GiB memory, 150 GiB PV storage
    • 1x.small: 11 vCPUs, 18 GiB memory, 300 GiB PV storage
    • 1x.medium: 38 vCPUs, 72 GiB memory, 450 GiB PV storage
  • Object storage: Cannot be predicted before installation; start with 1 TB and monitor actual usage

Estimated installation time: 1-2 hours (includes object storage setup)

Go to these planning topics:

  • Plan your logging installation
  • Choose a LokiStack storage backend
  • Size your LokiStack deployment
Note

Both storage backend selection and LokiStack sizing are required for Scenario 2.

Skip these planning topics:

  • Console UI plugin configuration (not using COO)
  • Multi-tenant monitoring setup (not using COO)

1.5. Scenario 3: Vector + Loki + COO (full stack)

Use Scenario 3 if you want a full observability stack with log querying directly in the OpenShift web console.

Choose this scenario if:

  • You want to query logs directly in the OpenShift web console
  • You need to correlate logs with metrics and distributed traces
  • You manage a multi-tenant cluster with namespace-scoped observability needs
  • You prefer browser-based visualization over external dashboards
  • You want incident detection with automatic alert grouping

What you need to plan:

  • Everything from Scenario 2 (object storage, Loki sizing, cluster resources)
  • Console UI plugin resources (additional CPU and memory for plugin pods)
  • Multi-tenant monitoring stacks (if providing per-namespace observability)
  • Korrel8r configuration for signal correlation
  • Network policies for UI plugin access
  • User permissions for namespace-scoped log queries

Resource requirements:

  • Vector + Loki: Same as Scenario 2
  • COO UI plugins: Additional ~500m CPU, ~512 MiB memory for console plugins
  • Korrel8r: ~200m CPU, ~256 MiB memory
  • Per-namespace monitoring stacks (optional): ~1 vCPU, ~2 GiB memory per stack

Total for medium deployment: ~40 vCPUs, ~75 GiB memory (before multi-tenant stacks)

Estimated installation time: 2-4 hours (includes all three operators and UI setup)

Go to these planning topics:

  • Plan your logging installation
  • Choose a LokiStack storage backend
  • Size your LokiStack deployment
Note

Both storage backend selection and LokiStack sizing are required for Scenario 3.

1.6. Can you change scenarios later?

Yes, you can transition between scenarios:

Scenario 1 Scenario 2:

  • Install Loki Operator
  • Create object storage backend
  • Create LokiStack custom resource
  • Logs start storing locally in addition to external forwarding

Scenario 2 Scenario 3:

  • Install Cluster Observability Operator
  • Create UIPlugin custom resource
  • "Logs" tab appears in OpenShift console

Scenario 3 Scenario 2:

  • Delete UIPlugin custom resource
  • Uninstall Cluster Observability Operator
  • Local log storage continues; console UI removed

Scenario 2 or 3 Scenario 1:

  • Delete LokiStack custom resource
  • Uninstall Loki Operator (and COO if present)
  • Continue forwarding logs externally via Vector

Transitioning is possible, but requires operator installation/removal and custom resource changes. Planning your scenario correctly from the start avoids this work.

Red Hat logoGithubRedditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat Documentation

Legal Notice

Theme

© 2026 Red Hat
Back to top