This repo contains the image definitions for the components of the logging stack as well as tools for building and deploying them. The logging subsystem consists of multiple components abbreviated as the "EFK" stack: Elasticsearch, Fluentd, Kibana.
The primary features this integration provides:
- Multitenant support to isolate logs from various project namespaces
- Openshift OAuth2 integration
- Historical log discovery and visualization
- Log aggregation of pod and node logs
Information to build the images from github source using an OpenShift Origin deployment is found here. To deploy the components from built or supplied images, see the openshift_logging role in the OpenShift Ansible project. You will need to be familiar with Ansible principles and create an inventory file to modify the default variables for your OpenShift logging cluster. For the impatient, see the quickstart guide.
NOTE: If you are running OpenShift Origin using the
All-In-One docker container
method, you MUST add -v /var/log:/var/log to the docker command line.
OpenShift must have access to the container logs in order for Fluentd to read
and process them.
The logging subsystem consists of multiple components commonly abbreviated as the "ELK" stack (though modified here to be the "EFK" stack).
Elasticsearch is a Lucene-based indexing object store into which logs are fed. Logs for node services and all containers in the cluster are fed into one deployed cluster. The Elasticsearch cluster should be deployed with redundancy and persistent storage for scale and high availability.
Fluentd is responsible for gathering log entries from nodes, enriching them with metadata, and feeding them into Elasticsearch.
Kibana presents a web UI for browsing and visualizing logs in Elasticsearch.
In order to authenticate the Kibana user against OpenShift's Oauth2, a proxy is required that runs in front of Kibana.
Curator allows the admin to remove old indices from Elasticsearch on a per-project basis.
The openshift-ansible openshift_logging role orchestrates the deployment
of the logging stack including: resource definitions, key/cert generation, component
start and stop order.
Determining the health of an EFK deployment and if it is running can be assessed
by running the check-EFK-running.sh and check-logs.sh e2e tests.
Additionally, see Checking EFK Health
Any issues against the origin stack can be filed at https://github.com/openshift/origin-aggregated-logging/issues. Please include as many details as possible in order to assist us in resolving the issue.