Centralized Log Management Architecture via Elastic Stack Deployment on CentOS 7

The Elastic Stack, historically and commonly referred to as the ELK Stack, represents a sophisticated ecosystem of open-source software engineered by Elastic to facilitate the ingestion, storage, analysis, and visualization of logs generated from disparate sources in any format. This architectural approach, known as centralized logging, transforms the traditionally fragmented process of log management—where administrators must manually access individual servers to inspect flat files—into a streamlined, unified operation. By consolidating logs into a single, searchable repository, the Elastic Stack enables the rapid identification of systemic failures, the correlation of events across multiple servers within a specific temporal window, and the proactive monitoring of application health. In a modern enterprise environment, where microservices and distributed architectures are the norm, the ability to correlate logs from multiple nodes is not merely a convenience but a technical necessity for maintaining uptime and operational integrity.

The deployment of this stack on CentOS 7 provides a stable, enterprise-grade foundation. CentOS 7, being a community-driven rebuild of Red Hat Enterprise Linux (RHEL), offers the binary compatibility and stability required for the resource-intensive nature of Elasticsearch and Logstash. The synergy between these components allows an organization to move from a reactive posture—responding to failures after they are reported—to a proactive posture, where anomalies are detected in real-time via Kibana dashboards. This guide provides an exhaustive technical exploration of installing and configuring these components, ensuring that version parity is maintained across the stack to prevent compatibility regressions.

Component Architecture and Functional Analysis

The Elastic Stack is not a single application but a coordinated suite of tools, each serving a distinct role in the data pipeline. Understanding the theoretical role of each component is critical for successful deployment.

  • Elasticsearch: This serves as the heart of the stack. It is a distributed, RESTful search and analytics engine that stores all the ingested logs. Its primary function is to index data, allowing for near real-time search capabilities. Because it is designed for horizontal scalability, it can handle massive volumes of log data by distributing the load across a cluster of nodes.
  • Logstash: This is the server-side data processing engine. Logstash acts as the intermediary that receives logs, transforms them, and pipes them into Elasticsearch. It possesses a powerful set of filters that can parse unstructured log data into structured formats, making the data searchable and meaningful.
  • Kibana: This is the visualization layer. Kibana provides a web-based interface that allows users to query the data stored in Elasticsearch. Through the creation of histograms, heat maps, and time-series graphs, Kibana converts raw log data into actionable business intelligence.
  • Filebeat: This is a lightweight log shipper. Unlike Logstash, which is resource-heavy, Filebeat is designed to be installed on every client server (the sources of the logs). It monitors log files and forwards them to Logstash using the lumberjack networking protocol, ensuring efficient data transport without consuming excessive CPU or RAM on the production client servers.

Technical Prerequisites and Infrastructure Requirements

Before initiating the installation process on CentOS 7, specific hardware and software requirements must be met to ensure the stability of the Elastic Stack.

Hardware Specifications

The resource consumption of an ELK server is directly proportional to the volume of logs being processed and the frequency of queries performed. For a baseline environment, the following specifications are recommended:

Resource Minimum Requirement Context/Impact
CPU 2 Cores Necessary for concurrent processing of Logstash filters and Elasticsearch indexing.
RAM 4GB Required to support the Java Virtual Machine (JVM) heap for Elasticsearch and Logstash.
OS CentOS 7 Provides the necessary kernel stability and package management via YUM.
Storage Variable Depends entirely on the log retention policy and the volume of incoming data.

Software and Environmental Dependencies

The Elastic Stack relies heavily on the Java Runtime Environment (JRE). Specifically, Elasticsearch and Logstash require Java to execute.

  • Java 8: It is explicitly required that Java 8 be installed. Oracle Java 8 is the recommended version for compatibility. It is critical to note that Java 9 is not supported, and attempting to use unsupported versions can lead to catastrophic JVM crashes or failure of the services to start.
  • Root Access: The installation requires root or sudo privileges to manage systemd services, modify /etc/yum.repos.d/ configurations, and install RPM packages.
  • Network Proxy: Since Kibana is typically bound to the localhost by default for security reasons, Nginx must be installed to act as a reverse proxy. This allows the Kibana interface to be accessed securely via a web browser from remote administrative workstations.
  • Security Layer: Because the Elastic Stack exposes sensitive internal server data, the implementation of TLS/SSL certificates is mandatory to encrypt data in transit and prevent unauthorized access to the logging infrastructure.

Step-by-Step Installation Methodology

The installation process must follow a strict sequence to ensure that the storage layer (Elasticsearch) is active before the processing layer (Logstash) or visualization layer (Kibana) attempts to connect to it.

Phase 1: System Preparation and Java Installation

The first step involves updating the system and installing the necessary JRE.

  1. Update the system packages to ensure all security patches are current:
    yum update -y

  2. Install the OpenJDK 8 environment:
    yum install java-openjdk -y

Phase 2: Elasticsearch Deployment

Elasticsearch must be installed first as it is the destination for all data.

  1. Import the GPG key to verify the integrity of the packages:
    rpm --import http://packages.elastic.co/GPG-KEY-elasticsearch

  2. Create the repository configuration file:
    cat <<EOF > /etc/yum.repos.d/elasticsearch.repo
    [elasticsearch-2.x]
    name=Elasticsearch repository for 2.x packages
    baseurl=http://packages.elastic.co/elasticsearch/2.x/centos
    gpgcheck=1
    gpgkey=http://packages.elastic.co/GPG-KEY-elasticsearch
    enabled=1
    EOF

  3. Install and enable the service:
    yum install elasticsearch -y
    systemctl enable elasticsearch
    systemctl start elasticsearch

Phase 3: Kibana Deployment

Kibana provides the window into the data. It must be version-matched with Elasticsearch.

  1. Create the repository configuration file:
    cat <<EOF > /etc/yum.repos.d/kibana.repo
    [kibana-4.4]
    name=Kibana repository for 4.4.x packages
    baseurl=http://packages.elastic.co/kibana/4.4/centos
    gpgcheck=1
    gpgkey=http://packages.elastic.co/GPG-KEY-elasticsearch
    enabled=1
    EOF

  2. Install and enable the service:
    yum install kibana -y
    systemctl enable kibana
    systemctl start kibana

Phase 3: Logstash Deployment

Logstash handles the ingestion and transformation of the logs.

  1. Create the repository configuration file:
    cat <<EOF > /etc/yum.repos.d/logstash.repo
    [logstash-2.2]
    name=logstash repository for 2.2 packages
    baseurl=http://packages.elasticsearch.org/logstash/2.2/centos
    gpgcheck=1
    gpgkey=http://packages.elasticsearch.org/GPG-KEY-elasticsearch
    enabled=1
    EOF

  2. Install and enable the service:
    yum install logstash -y
    systemctl enable logstash
    systemctl start logstash

Advanced Automation and DevOps Integration

For large-scale environments, manual installation is inefficient. Automation via Ansible allows for the consistent deployment of the Elastic Stack across multiple nodes.

Ansible Implementation Details

The use of Ansible playbooks ensures that the deployment is idempotent and repeatable. The following technical processes are utilized in automated ELK deployments:

  • RPM Management: The get_url module is used to download specific versions of the Kibana RPM from the Elastic artifacts repository to the /tmp directory.
  • Package Deployment: The yum module is then used to install the downloaded RPM, ensuring the state is set to present.
  • Security Token Generation: For secure communication between nodes, an enrollment token is generated using the following command:
    /usr/share/elasticsearch/bin/elasticsearch-create-enrollment-token -s kibana
  • Token Distribution: The generated token is registered as a variable and then distributed to the Kibana servers using the copy module, ensuring that only authorized Kibana nodes can join the Elasticsearch cluster.

Networking and Security Configuration

A critical aspect of the Elastic Stack deployment on CentOS 7 is the networking layer, specifically regarding how Kibana is exposed and how data is transmitted.

Nginx Reverse Proxy Configuration

Because Kibana's default configuration restricts access to the local loopback interface, Nginx is employed as a gateway. Nginx receives the external HTTP request and proxies it to the internal Kibana port. This allows for the implementation of SSL termination at the Nginx level, adding a layer of security to the web interface.

Data Transmission with Filebeat

Filebeat is installed on all client servers. It acts as a "log shipper," meaning it does not process the data but merely forwards it. The communication between Filebeat and Logstash utilizes the lumberjack protocol. This protocol is essential because it provides a way for the shipper and the receiver to acknowledge the receipt of data, ensuring that no logs are lost during network instability.

TLS Support

To secure the communication between the various components of the stack (Filebeat -> Logstash -> Elasticsearch), OpenSSL is used to generate certificates. This ensures that sensitive log data is not transmitted in cleartext across the internal network, mitigating the risk of packet sniffing and man-in-the-middle attacks.

Version Parity and Compatibility Analysis

A recurring requirement across all implementation documentation is the mandate for version parity. The Elastic Stack components are tightly coupled; for instance, using Elasticsearch 6.5.2 with Kibana 4.4 would result in critical API failures and a complete lack of visualization capabilities.

The standard for a successful deployment is to maintain the same version across the entire stack. In the referenced high-stability deployment, the version 6.5.2 is used across all components:
- Elasticsearch 6.5.2
- Kibana 6.5.2
- Logstash 6.5.2
- Filebeat 6.5.2

This consistency ensures that the data schemas produced by Logstash are perfectly understood by the indexing engine of Elasticsearch and can be correctly rendered by the visualization tools in Kibana.

Conclusion: Strategic Analysis of the ELK Deployment

The deployment of the Elastic Stack on CentOS 7 constitutes a comprehensive solution for centralized logging that addresses the primary challenges of distributed system observability. By offloading the heavy lifting of log processing to a dedicated ELK server, the impact on production client servers is minimized, as Filebeat's lightweight nature prevents the "observer effect" where the monitoring tool itself degrades the performance of the application being monitored.

The technical architecture—combining the indexing power of Elasticsearch, the transformation capabilities of Logstash, the visualization of Kibana, and the efficiency of Filebeat—creates a robust pipeline. When integrated with Nginx for secure access and Ansible for automated deployment, the system becomes a scalable piece of infrastructure capable of handling enterprise-grade data volumes. The shift from fragmented log files to a centralized, searchable index allows for a drastic reduction in Mean Time to Resolution (MTTR) during incident response, as administrators can correlate events across the entire infrastructure in seconds rather than hours.

Sources

  1. DigitalOcean
  2. CyberRanges
  3. Spiceworks
  4. Timothy Quinn
  5. LinkedIn - Sirisoft PCL

Related Posts