Managing Logstash Pipelines
1. Understanding Pipeline Configuration
| Property | Description | Values |
|---|---|---|
| input | Defines the source of the log data | file, stdin, tcp, udp, http |
| filter | Processes and transforms log data | grok, mutate, date, json |
| output | Defines where to send the processed logs | elasticsearch, file, stdout, http |
Example: Basic Pipeline Configuration
input {
file {
path => "/var/log/myapp.log"
start_position => "beginning"
}
}
filter {
grok {
match => { "message" => "%{TIMESTAMP_ISO8601:timestamp} %{LOGLEVEL:loglevel} %{MESSAGE:message}" }
}
date {
match => [ "timestamp", "ISO8601" ]
}
}
output {
elasticsearch {
hosts => [ "localhost:9200" ]
index => "myapp-%{+YYYY.MM.dd}"
}
}
2. Creating Pipeline Files
| Property | Description | Example |
|---|---|---|
| input | Defines the source of the data to be processed | {<br> "file": {<br> "path": "/var/log/app.log"<br> }<br>} |
| filter | Transforms and enriches the data | {<br> "grok": {<br> "match": {<br> "message": "%{TIMESTAMP}"<br> }<br> }<br>} |
| output | Defines where to send the processed data | {<br> "elasticsearch": {<br> "hosts": ["localhost:9200"]<br> }<br>} |
Example: Basic Pipeline Configuration
{<br> "pipeline": {<br> "id": "my-pipeline",<br> "config": "input { ... } filter { ... } output { ... }"<br> }<br>}
Note: Pipeline files are written in Ruby-based syntax and must be placed in the
pipelines directory of Logstash.
3. Defining Multiple Pipelines
| Pipeline ID | Configuration File | Description |
|---|---|---|
| main | pipelines.yml |
Primary pipeline for main log processing |
| audit | pipelines.yml |
Dedicated pipeline for audit logs |
| metrics | pipelines.yml |
Pipeline for metrics collection and processing |
Example: pipelines.yml configuration
pipeline.1:
id: "main"
path.config: "/etc/logstash/conf.d/main.conf"
pipeline.2:
id: "audit"
path.config: "/etc/logstash/conf.d/audit.conf"
pipeline.3:
id: "metrics"
path.config: "/etc/logstash/conf.d/metrics.conf"
Note: Each pipeline must have a unique ID and its own configuration file.
Warning: Logstash will not start if any pipeline configuration is invalid.
4. Using Conditional Statements
Logstash supports conditional statements to control the flow of events through a pipeline. These conditions allow you to apply different filters or actions based on specific criteria.
| Condition Type | Syntax | Description | Example |
|---|---|---|---|
| if | if [field] == "value" { ... } |
Applies filter if field matches value | |
| else if | else if [field] == "value" { ... } |
Alternative condition when previous is false | |
| unless | unless [field] == "value" { ... } |
Applies filter if condition is NOT met | |
Example: Complex Conditional Pipeline
# Example pipeline with nested conditions
filter {
if [type] == "nginx" {
grok { match => { "message" => "%{IP:client_ip} %{WORD:method} %{URIPATH:uri} %{NUMBER:status_code}" } }
if [status_code] == "404" {
mutate { add_tag => "not_found_error" }
} else if [status_code] == "500" {
mutate { add_tag => "server_error" }
} else {
mutate { add_tag => "success" }
}
}
}
Note: Conditions in Logstash support a wide range of operators including
==, !=, <, >, =~ (regex match), and !~ (negated regex). Use parentheses to group complex conditions.
Warning: Complex conditional logic can impact pipeline performance. Avoid deeply nested conditions or excessive use of regex matching in high-volume pipelines.
5. Setting Pipeline Workers
| Property | Values | Description |
|---|---|---|
| pipeline.workers | 1 to 32 |
Number of worker threads to use for processing events. Default is 1. |
| pipeline.batch.size | 125 to 2048 |
Number of events to process in a batch. Larger batches can improve throughput but increase latency. |
| pipeline.batch.delay | 5 to 5000 |
Delay in milliseconds before processing a batch. Helps reduce CPU usage by batching events. |
Example: Configuring Pipeline Workers
pipeline.workers: 4
pipeline.batch.size: 512
pipeline.batch.delay: 50
Note: Increasing
pipeline.workers can improve throughput but may increase memory usage and contention. Adjust based on your system's capabilities.
6. Configuring Batch Size
| Property | Values | Description |
|---|---|---|
| pipeline.batch.size | 125 |
Number of events processed in a single batch. Default is 125. |
| pipeline.batch.delay | 50 |
Delay in milliseconds before processing a batch. Default is 50ms. |
Example: Setting Batch Size in Logstash Configuration
{
"pipeline": {
"batch": {
"size": 250,
"delay": 100
}
}
}
Note: Increasing batch size can improve throughput but may increase memory usage and latency.
7. Using Pipeline-to-Pipeline Communication
Logstash supports communication between pipelines using the pipeline output plugin. This allows one pipeline to send events to another pipeline running on the same or different Logstash instance.
| Property | Description | Default |
|---|---|---|
| pipeline | Name of the target pipeline to send events to | none |
| host | Hostname or IP address of the Logstash instance running the target pipeline | localhost |
| port | Port number to connect to on the target Logstash instance | 5044 |
| timeout | Timeout in seconds for connecting to the target pipeline | 30 |
| ssl_enabled | Enable SSL/TLS encryption for communication | false |
| ssl_certificate | Path to the SSL certificate file | null |
| ssl_key | Path to the SSL private key file | null |
Example: Sending Events to Another Pipeline
output {
pipeline {
host => "logstash-2.example.com"
port => 5044
pipeline => "pipeline-2"
}
}
Note: Ensure that the target pipeline is configured to accept incoming events via the
pipeline input plugin.
Warning: When using
pipeline output, make sure that the target Logstash instance is configured to handle incoming events properly to avoid data loss or performance issues.
8. Enabling Dead Letter Queue
Dead Letter Queues (DLQ) in Logstash help manage failed events by routing them to a separate queue for further analysis or retry processing.
| Configuration Option | Description | Default Value | Notes |
|---|---|---|---|
| dead_letter_queue.enabled | Enables or disables the dead letter queue functionality. | false |
Set to true to enable DLQ. |
| dead_letter_queue.path | Path to the directory where dead letter queue files are stored. | /var/lib/logstash/dead_letter_queue |
Must be a writable directory. |
| dead_letter_queue.max_retention_time | Maximum time (in seconds) that events can remain in the DLQ before being purged. | 3600 |
Set to -1 for infinite retention. |
Example: Enabling Dead Letter Queue in Logstash Configuration
input {
beats {
port => 5044
}
}
filter {
grok {
match => { "message" => "%{TIMESTAMP_ISO8601:timestamp} %{LOGLEVEL:loglevel} %{MESSAGE:message}" }
}
date {
match => [ "timestamp", "ISO8601" ]
}
}
output {
elasticsearch {
hosts => [ "localhost:9200" ]
index => "logs-%{+YYYY.MM.dd}"
}
dead_letter_queue {
enabled => true
path => "/var/lib/logstash/dead_letter_queue"
max_retention_time => 3600
}
}
Note: Events in the DLQ are stored as JSON files and can be reprocessed or analyzed separately.
9. Configuring Persistent Queue
| Property | Description | Default Value | Notes |
|---|---|---|---|
| queue.type | Queue type to use for persistent queue | persisted |
Must be persisted for persistent queue |
| queue.path | Directory where queue files are stored | /var/lib/logstash/queue |
Must be writable by Logstash process |
| queue.max_events | Maximum number of events to queue | 1024 |
Set to 0 for unlimited |
| queue.max_bytes | Maximum size of queue in bytes | 1073741824 |
Default is 1GB |
| queue.checkpoint.warnings | Enable warnings when checkpoint files are too large | true |
Set to false to disable warnings |
Example: Persistent Queue Configuration
queue.type: persisted
queue.path: /var/lib/logstash/queue
queue.max_events: 2048
queue.max_bytes: 2147483648
queue.checkpoint.warnings: false
Note: Persistent queue is enabled by default in Logstash 8.x. It ensures that events are not lost during restarts or system failures.
10. Setting Pipeline Ordering
| Pipeline | Order | Description |
|---|---|---|
| pipeline.order | 0 |
Defines the order in which pipelines are processed. Lower numbers are processed first. |
| pipeline.name | main-pipeline |
Name of the pipeline for identification in logs and monitoring tools. |
Note: The
pipeline.order setting ensures that pipelines are processed in a specific sequence, which is crucial for maintaining data flow integrity.
11. Using Environment Variables
| Variable | Description | Default Value | Usage |
|---|---|---|---|
| LOGSTASH_HOME | Root directory of Logstash installation | /usr/share/logstash |
Used to locate Logstash configuration and plugin directories |
| LS_JAVA_OPTS | Java options for Logstash process | -Xmx1g -Xms256m |
Set memory limits and JVM options |
| LS_SETTINGS_DIR | Directory containing Logstash settings files | /etc/logstash |
Overrides default settings directory |
| LS_LOG_DIR | Directory for Logstash log files | /var/log/logstash |
Configures where logs are written to |
Example: Setting Environment Variables in systemd Service File
# /etc/systemd/system/logstash.service
[Service]
Environment=LS_JAVA_OPTS="-Xmx2g -Xms512m"
Environment=LOGSTASH_HOME=/opt/logstash
Environment=LS_SETTINGS_DIR=/etc/logstash-custom
Note: Environment variables are loaded before Logstash starts and can be overridden by command-line arguments or configuration files.
12. Reloading Configuration
Logstash supports reloading configurations without restarting the entire service. This is useful for applying changes to pipelines dynamically.
| Method | Description | Notes |
|---|---|---|
| SIGUSR1 signal | Send SIGUSR1 to the Logstash process to trigger a configuration reload. | Works for configurations managed via logstash.yml or file-based pipelines. |
| API endpoint | Use the /_node/hot_reload API to reload configurations. |
Available in Logstash 7.10+. |
Note: Configuration reloads are asynchronous and may take a few seconds to complete.
Warning: If a configuration is invalid, Logstash will continue running the previous valid configuration and log an error.