Windows DNS Server log collection is essential yet complex, primarily because Windows DNS Server provides logs in various places in different forms containing a vast amount of information. Nevertheless, we all know that DNS Server log collection is paramount in IT security. Getting it right can be challenging. The Windows DNS Server section in the NXLog user guide offers a comprehensive guide on collecting log records from a Windows DNS Server.

syslog-ng and NXLog are both powerful log collectors providing flexible log processing. However, you might be in a position where you need to switch from syslog-ng to NXLog. Whether it’s because syslog-ng doesn’t support an operating system or you want to upgrade your log collection solution to one that can be centrally managed, converting your syslog-ng configuration to NXLog is a simple task. How do syslog-ng and NXLog differ? syslog-ng and NXLog are alike in many ways.

Log collection is most closely linked to enterprise security practices—​for example, aggregation and analysis in a SIEM. However, collecting certain logs for reasons other than security is often valuable. It may even be a requirement of your organization for the purposes of auditing, legal compliance, or data retention. Storing all these logs in a database is the most efficient way to manage the data. Finding and managing logs stored as flat files or structured data can be challenging without a database.

Puppet Bolt is an open-source orchestration tool that automates the manual configuration and management of your infrastructure. In this post, we will look at how you can create your Puppet Bolt project directory, your inventory YAML file, and finally, your Puppet Bolt Plan to deploy NXLog on a variety of Operating Systems. Why use Puppet Bolt to deploy NXLog? Apart from the usual tasks of updating software packages, configuring web servers and databases, the need for constant logging has become extremely important, and a de facto necessity nowadays.

Ansible has become an industry standard when it comes to configuring and managing servers. As a configuration management tool, it carries the burden of simplifying system administration tasks, such as installing and updating software packages, and infrastructure provisioning. In this post, we will create an Ansible playbook that will enable us to automate the installation and configuration of NXLog across multiple endpoints. Whether you need only a single endpoint today or thousands of endpoints next week, Ansible will do the heavy lifting for you.

If you are reading this, then it is safe to say that you are now part of the NXLog community. In other words, you are ready to dive into the world of log collection. Excellent. You have made a great choice. However, before you start collecting logs you should know just how your NXLog log collection tool works. The NXLog log collection tool uses loadable modules that are invoked within the input, data modification, and output stages.

One of the harder decisions revolve around implementing agent-based vs agentless log collection. This post covers the two methods - their advantages and disadvantages - and provides some quick and actionable implementation notes. Why does log collection agent choice matter? When deploying a log collection strategy, administrators usually tend to zone in on already selected solutions that answers fundamental questions, such as "Will this solution collect and ship these types of log sources?