Below is the list of blog posts with the “deployment” category.

NXLog Agent plays a vital role in aggregating, processing, and forwarding logs to centralized platforms for analysis. Whether it’s system logs, application logs, or security audit trails, these agents are often the first line of visibility into what’s happening in your environment. In many setups, especially large-scale infrastructures, NXLog Agent relays act as crucial intermediaries, collecting logs from edge systems and forwarding them to a SIEM or log analytics platform.

Imagine trying to buy tickets for your favorite band’s concert, only to find the website down just minutes before they sell out. Or logging into the cloud to look through your cherished digital photos and discovering they’ve been lost because of a data center failure. These scenarios are — at best — frustrating for you. But, for your customers, they can erode trust and damage your business’s reputation. That’s why organizations invest in strategies like high availability (HA) and fault tolerance (FT).

In my early days as a Junior Sysadmin, I learned the value of automation when tasked with configuring hundreds of Windows XP machines. Yes, there was a version of Windows called XP. Automating large and repetitive tasks saves time and ensures scalability and consistency in IT environments. Scalability has become very important in IT, and in the golden age of automation tools and APIs, what could be a better way to execute the mass deployment and configuration of your log collection tool than using these very mature and available technologies?

Logs play a critical role in IT infrastructure, and choosing the right log management solution is key to effective operations. This guide explores the core principles for selecting a solution that aligns with your log collection and management needs. Given the wide range of options available, we categorize them into three main groups for clarity. End-to-end Log Management Solutions Security Information & Event Management (SIEM) Application Performance Monitoring and Observability (APM)

With an ever-expanding choice of technologies on the market, navigating the range of open-source observability tools can be a challenge. Which is why, when it comes to managing complex multicloud environments and their services, standardization is crucial. Here’s where OpenTelemetry (OTel) can play a key role. Developed through the merger of OpenCensus and OpenTracing, OpenTelemetry has become the new standard for open-source telemetry. Discover what OTel is, the types of telemetry data it encompasses, its potential benefits, and how NXLog can support your OpenTelemetry ecosystem.

Back in the day, Gordon Moore made relatively accurate observations and projections about the exponential growth of transistors on semiconductors. It still amazes me, yet very few predicted the incredible growth of system interconnectedness and the vast amount of data it generates. It is estimated that 90% of all data was created in the last last two years. Given that everything is connected, the need for telemetry is growing at an unprecedented rate, and thus, the need to efficiently channel and manage telemetry data has also grown.

Automatic updates are recommended by many vendors as they are considered essential for safeguarding against security threats and maintaining system performance. Updates not only enhance security but also deliver bug fixes and new features, contributing to improved user experience. Software updates, however, come with the inherent risk of breaking existing functionality and can potentially interfere with other software or the operating system itself causing unintended side effects. Automatic updates that the user has no control over escalate the risk further.

Agentless log collection refers to gathering log data from various sources without installing dedicated software agents on the systems generating the logs. Instead, it leverages protocols such as SNMP traps, WECS, WMI, and syslog to retrieve log data remotely. It is easier to explain what agentless log collection is by also providing some context about agent-based log collection. The truth is that these two options for collecting logs walk hand in hand, meaning that they can and will likely coexist on your network.

An excellent way to get started in a new technology area or refresh our knowledge is to devise a solution based on a small idea or need. This blog post covers such a situation, with a small personal project demonstrating how to use NXLog’s powerful features. I embarked on a small pet project centered around a cloud machine running Debian 10. It connects telemetry from my home, country house, and notebook.

The NXLog team is constantly improving the quality of NXLog Enterprise Edition and will soon introduce a new major release - NXLog Enterprise Edition 6.0. This release will bring a large number of changes and it is important to correctly adapt your current configuration when upgrading your system. Warning We strongly recommend testing NXLog Enterprise Edition 6.0 operation on a smaller set of devices before commiting to a full-scale upgrade of your complete system.

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?