There are two interesting types of information:
- Events: all the changes made by the the agents on your Nodes
- Compliance: the current state of your Nodes compared with the expected configuration
The Web interface gives access to this, but we will here see how to process events automatically. They are available on the root server, in /var/log/rudder/compliance/non-compliant-reports.log. This file contains two types of reports about all the nodes managed by this server:
- All the modifications made by the agent
- All the errors that prevented the application of a policy
The lines have the following format:
[%DATE%] N: %NODE_UUID% [%NODE_NAME%] S: [%RESULT%] R: %RULE_UUID% [%RULE_NAME%] D: %DIRECTIVE_UUID% [%DIRECTIVE_NAME%] T: %TECHNIQUE_NAME%/%TECHNIQUE_VERSION% C: [%COMPONENT_NAME%] V: [%KEY%] %MESSAGE%
In particular, the RESULT field contains the type of event (change or error, respectively result_repaired and result_error).
Below is a basic Logstash configuration file for parsing Rudder events. You can then use Kibana to explore the data, and create graphs and dashboards to visualize the changes in your infrastructure.
input {
file {
path => "/var/log/rudder/compliance/non-compliant-reports.log"
}
}
filter {
grok {
match => { "message" => "^\[%{DATA:date}\] N: %{DATA:node_uuid} \[%{DATA:node}\] S: \[%{DATA:result}\] R: %{DATA:rule_uuid} \[%{DATA:rule}\] D: %{DATA:directive_uuid} \[%{DATA:directive}\] T: %{DATA:technique}/%{DATA:technique_version} C: \[%{DATA:component}\] V: \[%{DATA:key}\] %{DATA:message}$" }
}
# Replace the space in the date by a "T" to make it parseable by Logstash
mutate {
gsub => [ "date", " ", "T" ]
}
# Parse the event date
date {
match => [ "date" , "ISO8601" ]
}
# Remove the date field
mutate { remove => "date" }
# Remove the key field if it has the "None" value
if [key] == "None" {
mutate { remove => "key" }
}
}
output {
stdout { codec => rubydebug }
}
