...
As mentioned above, Filebeat will be firstly configured to dump the output in a file. Below is shown the configuration file of Filebeat for each agent. It configures an input of type log, which is needed to read lines from log files. There's also the output which configures the path and the filename to dump the data in, and finally the section of processors to drop some fields Filebeat adds by default, and to add the logtype field used in the Logstash beats-pipeline(todo:link) output output.
RADIUS Server
The following is the Filebeat configuration on the radius server, which dumps the data in the /tmp/sample_logs_output.json file.
...
The logs are located in the message field. The logtype field holds the radius value, thus differentiating these events from the dhcp ones when arriving at Logstash pipeline(todo:link).
DHCP Server
The following is the Filebeat configuration on the dhcp server, which dumps the data in the /tmp/sample_logs_output.json file.
...
The logtype field contains the dhcp value, thus differentiating these events from the radius ones, when arriving at Logstash pipeline(todo:link).
Filtering Log Events
Apart from adding or dropping named fields, processors can also be used to filter log events when certain criteria are met. For example, to send out only the log events containing the value Eduroam in the NAS-Identifyer field, the following configuration could be applied.
...
For each pipeline, an id and the configuration file is defined. The beats-pipeline functions as a gate receiving logs from both (radius, dhcp) streams and then feeds their pipelines, respectively.
| Anchor | ||||
|---|---|---|---|---|
|
As already mentioned, the beats-pipeline acts as receiver / forwarder of log-events coming from radius and dhcp streams. It doesn’t configure any filter element, but the input and output ones.
...