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 Copy linkLink copied to clipboard!
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 Copy linkLink copied to clipboard!
Compare the three OpenShift Logging deployment scenarios across key decision factors to determine which best fits your infrastructure and requirements.
| Decision Factor | Scenario 1: Vector only | Scenario 2: Vector + Loki | Scenario 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) Copy linkLink copied to clipboard!
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 Copy linkLink copied to clipboard!
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
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) Copy linkLink copied to clipboard!
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
Both storage backend selection and LokiStack sizing are required for Scenario 3.
1.6. Can you change scenarios later? Copy linkLink copied to clipboard!
Yes, you can transition between scenarios:
Scenario 1
- Install Loki Operator
- Create object storage backend
- Create LokiStack custom resource
- Logs start storing locally in addition to external forwarding
Scenario 2
- Install Cluster Observability Operator
- Create UIPlugin custom resource
- "Logs" tab appears in OpenShift console
Scenario 3
- Delete UIPlugin custom resource
- Uninstall Cluster Observability Operator
- Local log storage continues; console UI removed
Scenario 2 or 3
- 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.