Configuring Stores
A store is Korrel8r’s client connection to a back end that holds observability data. Korrel8r needs at least one store per domain it should search. If a domain has no store, korrel8r still knows its rules, but cannot retrieve any of its data.
The built-in configurations assume every store is installed in its default OpenShift location. Pointing korrel8r at a store somewhere else is the most common configuration change, and is what this page covers. For the full config file syntax, see the Configuration reference.
Stores in the built-in configuration
Korrel8r ships with two configurations that differ only in how they reach the same set of stores:
- openshift-svc.yaml
- For korrel8r running in the cluster. Uses in-cluster service URLs. This is the default for the deployed service.
- openshift-route.yaml
- For korrel8r running outside the cluster. Looks up each store’s host from its OpenShift Route.
Both configure these stores:
| Domain | Back-end | Store field | Default location |
|---|---|---|---|
k8s |
Kubernetes API server | (none) | Your current kubectl/oc login |
log |
LokiStack | lokiStack |
logging-loki-gateway-http in openshift-logging |
metric |
Thanos / Prometheus | metric |
thanos-querier in openshift-monitoring |
alert |
Thanos + Alertmanager + Loki ruler | metrics, alertmanager, lokiRuler |
openshift-monitoring, plus openshift-logging for the ruler |
netflow |
LokiStack (NetObserv) | lokiStack |
loki-gateway-http in netobserv |
trace |
TempoStack | tempoStack |
tempo-platform-gateway in openshift-tracing |
incident |
Thanos / Prometheus | metrics |
thanos-querier in openshift-monitoring |
Check which stores are working
Before changing anything, find out what korrel8r currently sees:
korrel8r domains # Domains and stores in the local configuration file
korrel8rcli -u $KORREL8R_URL domains # Domains and stores used by a remote serverA store that failed to connect is reported with an error field, which is usually enough to tell
whether the URL is wrong, the store is not installed, or the connection was refused.
Replace default stores
To point a domain at a different back end, write your own configuration file with a stores entry
for that domain, and include the any built-in YAML rules that are defined.
Note: most built-in rules are compiled in to korrel8r don’t have separate YAML file.
# my-korrel8r.yaml
stores:
- domain: k8s
- domain: metric
metric: https://my-prometheus.example:9090
include:
- /etc/korrel8r/rules/all.yamlRun with it:
korrel8r web --config my-korrel8r.yamlOnly the domains you list get stores. The example above configures k8s and metric only, so
searches in every other domain return nothing. To change one store but keep the rest, include a
built-in store configuration — see Add a store to the defaults.
Add a store to the defaults
A domain can have more than one store. Korrel8r queries all stores for a domain and combines the results, so adding an entry supplements the default rather than replacing it.
Include a built-in configuration, then list the extra store.
# my-korrel8r.yaml
include:
- /etc/korrel8r/openshift-svc.yaml # All the default stores and rules
stores:
- domain: metric
metric: https://my-other-prometheus.example:9090Searches in the metric domain now query both the cluster Thanos and your own Prometheus.
Connect over TLS
Stores served with a private CA need a certificateAuthority field giving the path to a CA
certificate file. In-cluster, this is the service CA bundle mounted into every pod:
stores:
- domain: metric
metric: https://thanos-querier.openshift-monitoring.svc:9091
certificateAuthority: /var/run/secrets/kubernetes.io/serviceaccount/service-ca.crtLook up a store URL dynamically
Store fields are Go templates, so a URL can be
computed from the cluster instead of hard-coded. This is how openshift-route.yaml finds stores
when korrel8r runs outside the cluster:
stores:
- domain: log
lokiStack: 'https://{{k8sRouteHost "openshift-logging" "logging-loki"}}'k8sRouteHost returns the host of the named Route. See the
template functions reference for the functions available.
Apply a custom configuration in the cluster
For the deployed service, put your configuration in a ConfigMap:
apiVersion: v1
kind: ConfigMap
metadata:
name: korrel8r-custom-config
data:
korrel8r.yaml: |
include:
- /etc/korrel8r/openshift-svc.yaml
stores:
- domain: metric
metric: https://my-prometheus.example:9090Mount it in the deployment and point --config at it.
Mount at a sub-directory such as /etc/korrel8r/custom/, not at /etc/korrel8r itself: mounting
over that directory would hide the built-in configurations and rules that your include needs.
volumes:
- name: custom-config
configMap:
name: korrel8r-custom-config
containers:
- name: korrel8r
command: ["korrel8r", "web", "--config=/etc/korrel8r/custom/korrel8r.yaml"]
volumeMounts:
- name: custom-config
mountPath: /etc/korrel8r/custom
readOnly: trueNext steps
- Domain reference — every store field accepted by each domain.
- Configuration reference — the complete config file format.