This simplified guide to logging Docker to Elasticsearch shows you how to send logs of containers into Elastic. Although there are many tutorials on to logging Docker to Elasticsearch, this one is different from all as it uses syslog-ng. Visualize them on a nice dashboard in Kibana. And you can download it all at the end of the post!
Update: I moved the chapters about parsing and visualizing NGINX / Apache access logs in Kibana into a dedicated post / github repo.
Update 2: This post has been refactored and simplified to be compatible with Elasticsearch ECS and make it easier to implement. Compatible with Elasticsearch 7.x. Continue reading
In the last post I wrote about how you can create a central syslog server. This time I will show you how you can use syslog-ng to parse fail2ban log messages, enrich it with GeoIP metadata and send into Elasticsearch. You can even visualizing Fail2ban logs in Kibana to see where the failed login attempts are coming from.
Update: This post has been reviewed and all Fail2ban and GeoIP related contents have been merged here from the previous post. Look no further, you will find everything you need here. Note that this guide requires Elasticsearch 7.x.
Your home network might already contain some devices or systems like a home server, a WiFi router, a media player, or home automation system. It is a best practice creating a central syslog server and storing logs of various sources in one place.
Update: The fail2ban and GeoIP related contents have been merged into post visualizing Fail2ban logs in Kibana.
This post will cover the basics. Creating a central log server and receiving logs from an OpenWRT device. Please note that you can do many more. See the other posts I created in this subject.
I already had plans to write about Docker. However a recent system update caused issues and Docker failed to restart. This service outage made me think and write about such a typical maintenance task.
I know that I created the issue at the first place. However I could fix it and I will show you how I did it and how can I avoid that in the future.
When I created a central file sever, I mentioned that some of the problems with the solution are yet to be resolved.
- YaST created an import rule in file /etc/fstab, which is the de-facto place for storing such information. Its content and the mounts are usually static in server environments. On most client (in term of using an export of an NFS server) the network connectivity rarely or never changes in traditional environments.
However in case of mobile devices like on laptops, the network state could vary a lot. It can be offline, or on WiFi, or on wired connection, maybe using VPNs. We need much more flexibility than a mostly static file.
- Users would like to mount exports on their own. The system should be as transparent as possible to the end users.
Lucky for us, mounting NFS exports by using autofs service help us and gives the following advantages too. Continue reading