Why the federal agency breach shows that standardized telemetry formats aren’t optional anymore When CISA analyzed the federal agency breach that went undetected for three weeks, they identified a familiar pattern: EDR alerts existed but weren’t continuously reviewed. Security teams had visibility tools, but critical signals got lost in the noise. What the advisory doesn’t detail—​but every security practitioner knows—​is the infrastructure nightmare hiding behind that simple statement. Those unreviewed alerts likely came from dozens of sources, each speaking its own dialect of security telemetry.

The SentinelOne outage showed why visibility isn’t optional—​even when your defenses keep running. On May 29, 2025, organizations running SentinelOne experienced something unsettling: their security controls kept working, but they couldn’t see what was happening. A software flaw in SentinelOne’s infrastructure control system caused a global service disruption that lasted several hours. According to reports, the incident significantly impacted customers' ability to manage their security operations and access important data.

Collecting, processing, and forwarding logs and metrics at scale. OpenTelemetry provides a common instrumentation model that makes it easier to collect telemetry data across distributed systems, and many modern applications are adopting it as a standard for generating logs and metrics. However, in practice, you still need to collect, process, and shape the data before it becomes useful. You cannot simply forward raw telemetry data downstream without risking that your observability platform becomes expensive storage instead of a means of maintaining visibility into your environment.

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.