Centralized log management is the practice of collecting logs from across an environment, including applications, servers, containers, networks, and cloud services, and storing them in a single location where they can be searched and analyzed. For operations and security teams, centralized logging is now a core requirement. Without it, logs are scattered across hosts, ephemeral containers, cloud consoles, and disconnected tools. This fragmentation slows troubleshooting, complicates incident response, and limits visibility during security investigations.

We are happy to announce the latest release of NXLog Platform, version 1.11. This version focuses on operational visibility and compliance, smoother troubleshooting, and improved security and access controls. Want a quick overview? Watch a short demo showcasing the new features in this release: Read on for more details about these updates. Monitor data volume in the NXLog Platform UI You can now monitor the volume of inbound and outbound data flowing through your agents directly in the NXLog Platform UI, either from the agent statistics view or via the data flow visualization.

A practical approach to converting existing logs into modern observability. OpenTelemetry promises a vendor-neutral standard for observability, consistent telemetry, and the flexibility to change backends without rewriting everything. In practice, however, OpenTelemetry adoption often runs into a familiar obstacle: reality. Here’s a common scenario. You’re eager to improve observability, but your environment includes a mix of legacy applications, network devices, and third-party systems. Many of these were never designed for modern instrumentation, and changing them is risky, expensive, or simply not an option.

Centralized logging is no longer optional. Whether you’re troubleshooting production incidents, investigating suspicious activity, or meeting audit requirements, you need a way to collect logs from many sources, normalize them, search them quickly, and turn them into alerts and dashboards. In practice, that starts with reliable collection — often via solutions like NXLog Platform — so the data arrives clean and consistent. Two of the most common open-source paths people compare are Graylog vs ELK Stack.

How a federal agency’s monitoring gaps turned a containable incident into a three-week nightmare In September 2025, CISA responded to a federal agency breach that security teams could have stopped in hours. Instead, threat actors roamed the network undetected for three weeks. The damage? Multiple compromised servers, web shells planted across the infrastructure, and a persistent foothold that took significant resources to remediate. The root cause wasn’t a zero-day exploit or sophisticated malware.

From years of supporting NXLog Agent deployments across many environments, we’ve learned that while Linux generates a wealth of security logging, much of it remains underutilized. Critical security events are buried across multiple log files and subsystems, making it more complicated than it should be to spot suspicious activity. Efficient Linux security logging requires knowledge of which events matter and where to get them. Authentication attempts, privilege changes, package installations, audit events, and system shutdown events can all tell a story when viewed together.