Deploy a Ready‑to‑Use ELK Logging & Monitoring Stack for Private Environments

Background

In our projects we already use Elasticsearch for business data storage and have built a fast deployment toolchain with Ansible, Docker, and Jenkins. After configuring SSH connections, Jenkins can deploy Elasticsearch and Kibana with a single click.

Design principles:

Self‑Contained Deployment: all scripts, configs, and Jenkins jobs are packaged in a standard Jenkins Docker image, enabling one‑time tool provisioning on the target environment.

Single Source of Truth: a YAML configuration manager in Jenkins centralizes all deployment variables.

Configuration as Code / Infrastructure as Code: once configurations are defined, the entire process can be fully automated via scripts.

Requirement Analysis

Private deployments need log collection that is quick to deploy, simple and robust, function‑rich, and with modest performance demands. Additional needs include distributed log aggregation, host resource monitoring (CPU, disk, memory), application‑level metrics, and basic alerting.

Solution Analysis

Three options were considered:

ELK (Elasticsearch, Logstash, Kibana) with Beats for collection.

Zabbix or Open‑Falcon for system monitoring.

TICK (Telegraf, InfluxDB, Chronograf, Kapacitor).

ELK was chosen because it best satisfies log collection and visualization requirements while remaining cost‑effective.

ELK‑Based Implementation

Fast deployment: Jenkins provides one‑click installation of Elasticsearch and Kibana.

Simple components: only Elasticsearch and Kibana are deployed on a single machine, avoiding external dependencies.

Functionality over stability: Elasticsearch is upgraded to 7.6.0 for richer logging features, with the option to redeploy if incompatibilities arise.

Low performance demand: single‑node deployment suffices.

Log‑Specific Elasticsearch, Kibana, and Beats

A dedicated Elasticsearch instance (≈3 GB RAM) handles logs to avoid conflicts with business data.

Log collection: Filebeat is installed via Ansible on all hosts; no Logstash is used, and the Filebeat config is bundled into the Jenkins deployment package.

Log viewing: Collected logs are indexed in Elasticsearch and visualized directly in Kibana.

System metrics: Metricbeat, also deployed via Ansible, gathers Docker resource usage, CPU, memory, disk, network, and exposes a StatsD endpoint.

Availability checks: Heartbeat runs on gateway machines to probe databases, HTTP services, etc., sending results to Elasticsearch.

Alerting with Elasticsearch

Since native Elasticsearch alerts are paid, the open‑source ElastAlert (Python‑based) is used for email notifications. It supports frequency, spike, and flatline alert types, each defined by an Elasticsearch query.

Monitoring Dashboards

Kibana visualizations are assembled into dashboards for each business system, providing a clear view of component health and host status.

Kibana Configuration Automation

All Kibana settings are saved as objects (saved searches, visualizations, dashboards, index patterns). In a test environment these objects are exported to a Git repository via CI; deployment scripts then import them automatically, achieving Infrastructure as Code.

Extending Monitoring Scope

To monitor new services, add their URLs to Heartbeat or file paths to Filebeat; metrics can be sent through StatsD to Metricbeat, though current Metricbeat StatsD lacks tag support.

Adding Tracing

Elasticsearch includes an APM service that can be integrated for performance tracing when needed.

Conclusion

In private deployments, out‑of‑the‑box functionality outweighs high performance or scalability. Elasticsearch 7.6.0 and Kibana meet these needs; with standardized deployment scripts and pre‑prepared configurations, a complete monitoring system can be stood up in about half an hour.