SIEM and Log Management Release Notes

Updates for security event monitoring and tools for collecting, searching, and investigating logs.

Get this feed:

Products (9)

Latest SIEM and Log Management Updates

Nov 10, 2026
Date parsed from source:
Nov 10, 2026

First seen by Releasebot:
Nov 11, 2026
Datadog

Monitor and troubleshoot employee devices with Datadog End User Device Monitoring

Datadog makes End User Device Monitoring generally available, helping IT teams spot device issues early, connect device health with network and application context, and investigate root causes with shared findings and recommended actions to resolve disruptions faster.
When an employee’s Zoom call drops, Excel freezes, or an application fails to load, work stalls. Repeated interruptions put deadlines and business outcomes at risk, yet many disruptions go unreported as employees work around or ignore them. To move beyond firefighting, IT teams need tools that help them spot emerging issues, understand who’s affected, and act before disruptions spread.

Datadog End User Device Monitoring (EUDM) helps IT operations and service desk teams catch device problems early and fix recurring disruptions at the source. EUDM extends the Datadog Agent to employee laptops and workstations, combining visibility into device health with network and application context in the platform infrastructure teams already use. IT can investigate without prolonged back-and-forth with employees or waiting on other teams, and hand off issues with the evidence attached.

In this post, we’ll show how EUDM helps IT teams move from firefighting to proactive resolution:

Start the day knowing which devices need attention

Find the cause before escalating to other teams

Catch recurring problems and risks at their source

Start each fix with the root cause already identified

Start the day knowing which devices need attention

IT teams often begin their days by working through a backlog of employee-submitted tickets. Let’s say salespeople at a branch office are struggling through choppy Zoom calls with customers, while employees working from home cannot connect to an internal application. Before deciding what takes priority, IT needs to understand the scope of each problem.

Gathering that information often starts with screen sharing and asking employees to collect diagnostics. EUDM gives IT a head start before anyone contacts the person who filed the ticket. The fleet overview shows other laptops with declining health at the same branch, including devices whose users haven’t reported a problem. The map shows that the pattern is concentrated at that branch.

In Command Center, now available in preview, IT reviews detected issues, ranked by severity. Each issue has a card that summarizes its scope and root cause, so the team can assess impact without piecing it together ticket by ticket. A high-severity issue covers the branch’s disrupted Zoom calls. A medium-severity issue shows increased connection errors for the internal application, affecting employees working remotely.

The application issue affects a few employees, while the critical Zoom issue is putting customer deals at risk. IT has a clear view of each issue’s severity and can quickly set priorities: They get to work on the Zoom issue. Because the investigation findings are already attached, the team starts in on root cause analysis without any back-and-forth with employees.

Find the cause before escalating to other teams

EUDM narrows down root causes by correlating device performance, application activity, and network conditions. For the dropped Zoom calls, the Command Center card shows that all of the affected laptops at the branch are connected to the same access point. That makes the access point the likely culprit, so IT checks the laptops’ Wi-Fi metrics and network paths to confirm it before escalating.

As more laptops report the same problem, related findings are added to the open issue. To see where the calls degrade, IT checks Network Path, which uses real traffic to trace connections from devices to SaaS applications like Zoom, Microsoft Teams, or Salesforce. It shows latency at each hop, from the router through the internet service provider (ISP) to the application’s CDN and servers.

Network Path shows exactly where the connection degrades, pinpointing the problem at a network access point. Before escalating to the Network team, IT reviews the suggested next steps in EUDM’s Command Center to determine what needs to change. IT then hands off the issue with all the context the Network team needs to resolve it.

In the meantime, IT moves affected employees to a nearby access point with more available capacity. Using the investigation findings, the network team confirms that the original access point is congested, serving 60 clients on a single channel, and adjusts its configuration to reduce the load. Because both teams work from the same data, IT is able to restore the branch’s customer calls without the investigation bouncing between teams and tools.

Catch recurring problems and risks at their source

Investigating one ticket at a time obscures problems that affect multiple employees at once. A software update might cause the same application to crash on dozens of laptops, with each affected employee reporting it separately, leading service desk engineers on different shifts to repeat the same investigations.

EUDM links the current issue to relevant past investigations, helping the team check whether similar issues have come up before. Earlier findings show which causes were already examined, so a returning problem doesn’t send the investigation back to square one.

The Command Center issue card carries Bits Investigation’s root cause findings, supporting evidence, and recommended next steps. Its investigation trail records the diagnostic queries and hypotheses already examined, so the receiving team knows where the work left off.

Bits Investigation correlates related issues across devices into a single issue card, and if the problem spreads, it updates that card instead of creating a duplicate. In this case, Bits identified that employees were reaching the internal application without first connecting to the VPN. IT can fix this issue at the source by reminding these employees of the VPN step.

Start each fix with the root cause already identified

EUDM uses Bits Investigation to help IT operations move from reactive to proactive, with faster issue detection and root cause analysis. Each issue card includes an investigation trail showing the diagnostic queries, hypotheses, and decision path behind the findings. IT teams can review this evidence before taking action or escalating the issue. To dig deeper, they can continue in Bits Chat with the investigation context intact. For example, they can ask which laptops have low battery capacity or which devices use the most CPU. Recommended next steps include opening an incident, triggering a workflow, or notifying affected employees, all of which can be done in Datadog.

The service desk assigns ownership, updates priority, and links related work in existing tools like Jira or ServiceNow without leaving the card. Datadog Work Management keeps those actions and the investigation together as one work item. A bidirectional integration keeps history in sync wherever updates are made, so both teams follow progress from the tools they use.

With EUDM, IT catches device problems before employees report them, resolves them at the source, and hands off evidence that stays with the issue. Calls stay stable, applications stay available, and the team spends its time getting ahead instead of firefighting.

Get started with End User Device Monitoring

A problem affecting dozens of employees shouldn’t require dozens of investigations. Datadog End User Device Monitoring brings device, application, and network context together so IT can quickly understand what’s wrong, see which devices are affected, and coordinate a fix. With shared findings and recommended next steps, teams can spend less time piecing together the problem and more time resolving it across their fleet.

End User Device Monitoring is now generally available. Explore the documentation to get started. If you’re new to Datadog, sign up for a 14-day free trial.
Original source
Nov 10, 2026
Date parsed from source:
Nov 10, 2026

First seen by Releasebot:
Nov 11, 2026
Datadog

Monitor OCI workloads in US government clouds with Datadog

Datadog now supports monitoring OCI workloads in the OC2 and OC3 government cloud regions through Datadog for Government, while Cloudcraft helps teams map OCI resources alongside other infrastructure using familiar observability workflows.
Government agencies and contractors often choose dedicated Oracle Cloud Infrastructure (OCI) government environments for workloads that are subject to specific security, data residency, and compliance requirements. But the boundaries that help agencies meet those requirements can complicate observability. Monitoring OCI government environments can require separate tools and processes from the ones that teams use across the rest of their infrastructure.

Datadog for Government, operated in a FedRAMP® High–certified GovCloud (US1-FED) environment, helps teams take a more consistent monitoring approach by supporting OCI workloads in Oracle’s US government cloud regions. Teams that already use Datadog for Government can monitor those OCI environments by using familiar dashboards and observability workflows without learning new tools or building custom pipelines. Teams can also use Cloudcraft in GovCloud and other Datadog environments to create interactive maps of their OCI resources.

In this post, we’ll explain how you can:

Monitor OCI workloads across Oracle US Government Cloud (OC2) and Oracle US Defense Cloud (OC3)

Visualize your OCI environment with Cloudcraft

Monitor OCI workloads across OC2 and OC3

OC2 and OC3 are both FedRAMP High–authorized realms for US government workloads. OC2 supports US government workloads at Defense Information Systems Agency (DISA) Impact Level 4 (IL4), while OC3 supports Department of Defense (DoD) workloads at DISA IL4 and Impact Level 5 (IL5). The two realms are isolated from each other and from commercial OCI regions, so agencies need monitoring for the specific environment where their workloads run.

Datadog for Government supports OCI monitoring for OC2 and OC3 workloads. Existing Datadog for Government customers can enable the OCI integration from the US1-FED site by following the same setup flow used for commercial OCI monitoring. For more information about the OCI integration and the visibility it provides, see our blog post about monitoring OCI with Datadog.

Visualize your OCI environment with Cloudcraft

In addition to monitoring OCI workloads in Datadog for Government, teams can use Cloudcraft to visualize their OCI resources and understand how they fit together. Cloudcraft provides an interactive, isometric map that organizes resources by tenancy, compartment, region, virtual cloud network (VCN), and service.

Teams can also view OCI resources alongside their AWS, Microsoft Azure, Google Cloud, and VMware vSphere infrastructure. This shared view makes it easier to understand dependencies and investigate unfamiliar infrastructure while retaining the architectural context surrounding individual resources.

Start monitoring OCI government cloud workloads with Datadog

Datadog for Government support for OC2 and OC3 gives government agencies and contractors a consistent way to monitor OCI workloads across both realms. Cloudcraft complements this monitoring by helping teams visualize their OCI resources alongside other cloud infrastructure. Together, these capabilities enable teams to use familiar Datadog workflows to monitor and understand their Oracle infrastructure. To learn more, read the OCI integration documentation for US1-FED and the Cloudcraft in Datadog documentation.

As with other integrations, customers should review Datadog’s FedRAMP Customer Responsibility Matrix (CRM) for US1-FED for more information about their responsibilities under the shared responsibility model when they connect external environments to Datadog. To request access to the CRM, contact us at [email protected].

If you’re interested in a free trial for Datadog for Government, contact us at [email protected]. You can also request a demo with our public sector experts to explore how Datadog can support your mission.
Original source
All of your release notes in one feed

Join Releasebot and get updates from Datadog and hundreds of other software products.

Create account
Get updates with:
Nov 10, 2026
Date parsed from source:
Nov 10, 2026

First seen by Releasebot:
Nov 11, 2026
Datadog

Monitor OpenAI Codex usage and impact with Datadog

Datadog adds an OpenAI Codex integration and dashboard to track adoption, token use, code contributions, and review engagement. Teams can also connect Codex activity to AI Impact to compare delivery and reliability metrics for AI-assisted and non-AI work.
As engineering organizations deploy AI coding agents such as OpenAI Codex across their teams, access alone provides an incomplete view of adoption. Engineering leaders need visibility into how developers use Codex across models and clients, how much Codex-generated code they accept, and whether they find its code review feedback useful. Connecting these signals to software delivery outcomes can help leaders understand how AI-assisted development relates to engineering performance.

The Datadog OpenAI Codex integration collects per-user Codex activity from the Codex Analytics API and reports it as Datadog metrics. The out-of-the-box OpenAI Codex Overview dashboard brings together usage, token consumption, client activity, code attribution, and code review data. Teams can also send Codex engagement data to AI Impact, where they can compare software delivery performance between AI-assisted and non-AI work.

In this post, we’ll show you how to:

Track Codex adoption across users, models, and clients

Measure Codex contributions to your codebase

Evaluate how developers engage with Codex code reviews

Connect Codex adoption to software delivery performance

Track Codex adoption across users, models, and clients

Organization-wide usage totals can tell you that Codex adoption is growing, but they don’t tell you how that adoption is distributed. For example, a small group of engineers could account for a large share of activity, or developers might rely heavily on one Codex client while barely using another. Understanding these differences helps engineering leaders identify where Codex has become part of everyday development workflows and where adoption remains limited.

The OpenAI Codex Overview dashboard gives you a central view of Codex activity across your enterprise workspaces. Datadog collects per-user activity once per day and tracks threads, turns, consumed Codex credits, and tokens. You can filter the dashboard by workspace, account, user, model, or Codex client to investigate how usage differs across your organization.

Threads represent Codex conversations that an engineer starts, while turns represent messages sent across those threads. Metrics such as openai.codex.usage.threads and openai.codex.usage.turns therefore provide complementary measures of engagement. The dashboard plots these metrics over time and ranks users by activity, helping you determine whether changes in aggregate usage reflect broad adoption or activity concentrated among a smaller group of engineers.

The dashboard also tracks consumed Codex credits and token usage. Credits reflect Codex credit consumption rather than dollar amounts. The integration does not collect spend or currency data. You can break token consumption down into cached input, uncached input, and output tokens to understand how Codex processes context and generates responses over time.

Model-level views show how engineers use Codex across different models. The dashboard breaks down input and output token usage by model and speed tier, and ranks models by total token consumption. Engineering leaders can use these views to identify which models account for the largest share of usage and how those patterns change over time.

You can also compare adoption across Codex clients. The dashboard tracks threads and turns for clients such as the CLI, desktop app, GitHub, web, and IDE integrations. Because the Codex Analytics API does not provide a token breakdown by client, these views focus on threads and turns. Together, these dimensions help answer whether engineers primarily use Codex from the command line, a desktop application, or directly within development workflows.

Measure Codex contributions to your codebase

Usage metrics show how often engineers interact with Codex, but they do not indicate how much Codex contributes to the codebase. An engineer could have many conversations with Codex without using the resulting code, while another could use it to generate substantial changes with relatively few interactions.

The OpenAI Codex integration collects the lines of code added and removed that are attributable to Codex. The OpenAI Codex Overview dashboard plots these additions and removals over time, giving you another measure of adoption beyond conversations and token consumption. For example, rising attributed lines alongside rising thread and turn counts can indicate that increased engagement is also translating into a larger Codex footprint in the codebase.

Code attribution is useful when considered alongside the usage dimensions described above. If one team generates many turns but relatively few attributed code changes, while another has fewer turns and substantially more attributed code, the teams may be using Codex for different kinds of work. Engineering leaders can use these signals to understand how Codex fits into different development workflows rather than relying on a single organization-wide adoption metric.

Evaluate how developers engage with Codex code reviews

Code generation is only one part of Codex usage. Codex can also review pull requests and reason about changes in the context of a larger codebase. As engineering organizations expand AI-assisted review, measuring the number of generated comments alone does not reveal whether developers find that feedback useful.

The OpenAI Codex integration tracks completed reviews and review comments by priority: P0, P1, and P2. It also tracks how developers respond to those comments through upvotes, downvotes, other reactions, and replies. The OpenAI Codex Overview dashboard combines these signals so you can compare review volume with developer engagement over time.

These metrics can help you evaluate whether developers are engaging with Codex feedback. For example, replies and upvotes can indicate which comments prompt developer interaction, while downvotes can point to feedback that teams may want to examine more closely. Tracking these responses over time gives engineering leaders quantitative context to pair with direct developer feedback about AI-assisted code review.

At Datadog, code review is one area where Codex has demonstrated value beyond the immediate diff. In OpenAI’s case study about Datadog’s use of Codex, engineers reported that Codex identified interactions with modules outside a diff, missing test coverage involving cross-service coupling, and API contract changes with downstream risk.

Datadog’s AI Development Experience team also tested Codex against historical incidents by reconstructing pull requests that had contributed to those incidents. Codex found more than 10 cases, or roughly 22% of the incidents examined, where the engineers who owned the incidents said that its feedback would have made a difference. Following this evaluation, Datadog deployed Codex more broadly, and more than 1,000 Datadog engineers use it regularly.

Review metrics from the integration give other engineering organizations a way to examine similar questions within their own workflows. Rather than treating the number of generated comments as a measure of success, teams can examine comment priority and developer responses to understand how Codex review activity is received.

Connect Codex adoption to software delivery performance

Usage, code attribution, and review metrics show how engineers are adopting Codex, but engineering leaders also need to understand how that adoption relates to software delivery performance. Increased Codex activity alone does not indicate whether AI-assisted development is associated with faster delivery or changes in reliability.

Codex usage data feeds Datadog AI Impact, which measures how AI coding assistants affect software delivery performance. AI Impact classifies pull requests as AI-assisted or non-AI and compares their performance, helping teams measure AI adoption and correlate it with changes in delivery outcomes.

For Codex, AI Impact can infer AI assistance from user activity. When Codex reports that an engineer created lines of code with the tool on a given day, Datadog can classify commits that the engineer created that day as AI-assisted. A pull request is then considered AI-assisted when it contains at least one AI-assisted commit. This attribution gives teams a consistent way to connect Codex activity with the code that moves through their delivery process.

With AI Impact, you can track the percentage of pull requests that are AI-assisted and compare PR throughput, PR cycle time, change failure rate, and recovery time between AI-assisted and non-assisted development. For example, you can examine whether higher Codex adoption corresponds with changes in how many pull requests developers merge or how long those pull requests take to move from their first commit to merge. You can then consider those velocity signals alongside change failure rate and recovery time to understand how AI-assisted development relates to reliability.

Start monitoring OpenAI Codex with Datadog

The Datadog OpenAI Codex integration helps engineering leaders measure Codex adoption and connect AI-assisted development with code contributions, review engagement, and software delivery performance.

To configure the integration, an organization needs a ChatGPT Enterprise workspace with Codex enabled. A workspace owner or admin creates a workspace-scoped Admin key in the OpenAI Admin Console, grants it Codex analytics API read access, and provides the key and Workspace ID in the Datadog OpenAI Codex integration tile.

For setup requirements, supported metrics, dashboards, and configuration instructions, see the OpenAI Codex integration documentation. You can also read about how Datadog uses Codex for system-level code review.

If you don’t have a Datadog account, sign up for a 14-day free trial to start monitoring Codex adoption and its relationship to software delivery performance.
Original source
Nov 10, 2026
Date parsed from source:
Nov 10, 2026

First seen by Releasebot:
Nov 11, 2026
Datadog

Detect and respond to PHP2Shell with Datadog

Datadog adds PHP2Shell detection coverage to Cloud SIEM, helping teams identify exploitation attempts through suspicious processes and PHP-related activity. Its security tools also help locate vulnerable deployments, prioritize remediation, investigate past activity, and track patched runtimes.
On October 21, 2026, the PHP security team disclosed two critical remote code execution (RCE) vulnerabilities, CVE-2026-109618 and CVE-2026-109619, collectively known as PHP2Shell. Both vulnerabilities have a Common Vulnerability Scoring System (CVSS) v4.0 score of 9.2 and can be exploited without authentication. Because exploitation occurs before PHP executes application code, application-level authentication and input validation cannot prevent an attack. Even a PHP script that simply returns a response can expose the vulnerable code path.

AWS had observed exploitation attempts as early as October 17, before patches were available. Datadog Security Labs analyzed both vulnerabilities and published a technical breakdown of the vulnerabilities and the exploitation process, including a working reproduction. For teams running PHP applications, responding to PHP2Shell requires identifying affected deployments, applying patches, and investigating whether exploitation occurred before remediation.

Datadog Security helps teams perform these tasks by connecting vulnerability findings, infrastructure inventory, process activity, and security logs in one platform.

In this post, we’ll explain how you can use Datadog to:

Assess your exposure to PHP2Shell

Identify vulnerable PHP deployments and prioritize remediation

Detect exploitation attempts and investigate suspicious activity

Track remediation and verify that patches have been deployed

Assess your exposure to PHP2Shell

The Datadog Security Research Feed provides information about emerging vulnerabilities, including affected software versions, exploitation methods, and queries for investigating potential exposure. For PHP2Shell, the Research Feed includes an impact assessment that correlates the advisory with security data from your environment.

The impact assessment summarizes matches across vulnerability findings, library vulnerabilities, threats, and Agent events. You can use these results to determine where to investigate further. For example, if the assessment identifies vulnerable resources and related Agent events, you can open those results to review the affected systems and their activity.

The impact assessment provides a starting point for investigating PHP2Shell across your environment. From there, you can use Datadog Cloud Security to examine vulnerable infrastructure and Datadog Workload Protection or Cloud SIEM to investigate signs of exploitation.

Identify vulnerable PHP deployments and prioritize remediation

PHP2Shell affects the PHP interpreter itself, so remediation requires updating the PHP runtime on affected hosts and container images. Updating Composer dependencies will not address these vulnerabilities.

Cloud Security helps identify affected infrastructure, while Code Security provides additional context about PHP applications and their owners. Together, these products can help security and engineering teams determine which deployments need attention and coordinate the required updates.

Find vulnerable hosts and container images with Cloud Security

To investigate PHP2Shell, you can filter Cloud Security vulnerability findings by CVE-2026-109618 and CVE-2026-109619 to identify affected resources.

You can also use the Infrastructure Package Catalog to search for PHP installations across your infrastructure. Because the catalog maintains an inventory of installed packages independently of vulnerability advisories, you can use it to find PHP deployments even before a specific vulnerability has been added to Datadog’s vulnerability database.

Searching by package name is useful when investigating a vulnerability that affects multiple versions or distributions. It can also help identify PHP installations that require further review but do not appear in the initial CVE results.

Once you’ve identified affected resources, the Runtime Prioritization Engine helps you determine which findings to address first. It considers factors such as whether a resource is publicly accessible or runs in production, whether public exploits are available, and whether there’s evidence of suspicious activity.

For PHP2Shell, internet-facing Apache deployments that use mod_php warrant particular attention. The mod_php execution model runs PHP’s request shutdown procedure even when request initialization fails, which is relevant to the exploitation technique described in the PHP2Shell Security Labs analysis.

Identify affected applications and owners with Code Security

Code Security’s Software Composition Analysis (SCA) provides information about libraries loaded by running services, including those already in production. This runtime context can help teams identify differences between the dependencies recorded in source control and those used by deployed applications.

Code Security also helps identify PHP codebases and the teams responsible for them. By filtering the Library Inventory and Repositories views to the PHP (Packagist) ecosystem in SCA, you can find repositories associated with PHP applications.

Because PHP2Shell affects the interpreter, SCA flags the two CVEs in running services (where it can see the PHP runtime) rather than in repository dependency files. However, repository inventories still help you determine which applications rely on vulnerable PHP runtimes and which teams should participate in remediation.

For example, the team responsible for a container base image may need to update PHP, while the application team may need to validate the service after the updated image is deployed. Repository and ownership information helps coordinate that work.

Detect exploitation attempts and investigate suspicious activity

Patching vulnerable PHP applications and infrastructure addresses the underlying vulnerabilities, but it does not establish whether attackers compromised a system before the patch. Because exploitation attempts were observed before public disclosure, teams should also investigate historical activity on affected systems.

Workload Protection and Cloud SIEM provide complementary ways to investigate PHP2Shell. Workload Protection monitors process activity within workloads, while Cloud SIEM analyzes security events and logs from sources such as web servers, PHP, and Linux auditd.

Investigate suspicious process activity with Workload Protection

Workload Protection monitors process execution to identify suspicious activity in running workloads. Its general-purpose RCE detection can identify application processes that are spawning shells, a behavior associated with successful exploitation of PHP2Shell.

Because the detection examines process behavior, it can identify suspicious execution activity without depending on a particular PHP2Shell payload.

When Workload Protection detects suspicious activity, process information helps responders investigate what occurred. For example, the Investigation Graph can show a shell launched by a PHP or web server process, followed by commands that download additional software, such as malware, or inspect the host.

Responders can use process execution details and command-line arguments to investigate subsequent activity, including reconnaissance, credential access, persistence attempts, and lateral movement.

Process-based detection is especially useful when an attacker modifies an exploit payload to evade signatures based on request content. However, responders should still review the available process and security evidence to determine whether an alert represents successful exploitation.

Detect PHP2Shell activity with Cloud SIEM

Cloud SIEM analyzes logs and security events to identify suspicious activity across monitored infrastructure. For PHP2Shell, Datadog released dedicated detection rules within 24 hours of disclosure and added further coverage as the investigation progressed.

Two general-purpose detections can identify suspicious processes associated with RCE:

Shell spawned by web server or PHP process (def-000-9h1): Uses process activity events and parent process information to identify suspicious shell execution, download utilities, and reconnaissance commands.

Shell spawned by web process (def-000-gn1): Uses Linux auditd process execution logs to identify shells launched by web processes.

The auditd-based detection requires process execution events to be collected. Linux auditd does not record these events by default, so teams must configure the appropriate audit rules. Collecting additional process events can also increase log volume and host overhead.

Cloud SIEM also includes three PHP2Shell-specific detections that examine activity associated with the exploitation process, including memory exhaustion, session decoding failures, and PHP worker crashes.

These detections are useful because they can identify indicators of attempted exploitation even when an attacker does not successfully execute a shell. Memory exhaustion during request initialization, for example, is part of the PHP2Shell exploitation sequence.

Teams can use these detections to investigate suspicious activity in PHP error logs, web server logs, and PHP-FPM logs. The available evidence depends on which log sources and process events are collected. Bits Security Analyst can help automate triage, including for related signals that aren’t directly tied to PHP2Shell.

Workload Protection and Cloud SIEM can help responders investigate different stages of an attack. Log-based detections provide evidence of potential exploitation attempts, while process activity can help establish what happened after an attacker executed code.

Track remediation and verify that patches have been deployed

Remediating PHP2Shell requires more than updating a package or merging a change to a Dockerfile. Teams also need to confirm that the updated PHP runtime has reached the affected workloads.

For containerized applications, that means rebuilding affected images and deploying the updated containers. PHP-FPM workers and Apache processes must also be restarted to load the patched runtime. Otherwise, existing processes may continue running the vulnerable PHP version.

Cloud Security helps teams track this work by reporting vulnerability findings against deployed infrastructure. After applying updates, you can review the remaining PHP2Shell findings to identify hosts or container images that still require remediation.

For example, if an updated container image has been deployed to most replicas but an older image remains in one cluster, the corresponding vulnerability finding can help identify that remaining exposure.

Teams can also use the DDSQL Editor to query PHP package versions across hosts and container images, then save the results in Sheets or Notebooks. Tracking affected resources over time provides a record of remediation progress and helps identify deployments that still require attention.

Datadog Work Management and Workflow Automation can help teams coordinate remediation. Responders can create cases from security signals or vulnerability findings and use the associated resource context during investigations.

Workflow Automation can also trigger notifications or ticket creation based on vulnerability findings and security signals. By using ownership information from the Catalog, teams can route remediation work to the appropriate engineers.

These workflows help security teams track outstanding work while application and infrastructure owners deploy updates and verify their services.

Protect your PHP applications against PHP2Shell

Responding to PHP2Shell requires multiple teams working together to address vulnerable PHP runtimes and investigate possible exploitation. Datadog Security helps teams identify affected infrastructure, prioritize remediation, detect suspicious activity, and track outstanding vulnerability findings.

To remediate the vulnerabilities, upgrade to PHP 8.2.35, 8.3.36, 8.4.27, or 8.5.12 (or later), or install the corresponding patched package from your distribution. Rebuild affected container images, restart PHP workers, and verify that the updated runtime is deployed across your infrastructure. Review security events from before the patch to investigate potential exploitation.

For more information about the vulnerabilities and their exploitation techniques, read the Datadog Security Labs PHP2Shell analysis. You can also learn more about Cloud Security, Workload Protection, Cloud SIEM, and Code Security.

If you don’t have a Datadog account, sign up for a 14-day free trial to start investigating vulnerabilities and security threats in your environment.
Original source
Nov 10, 2026
Date parsed from source:
Nov 10, 2026

First seen by Releasebot:
Nov 11, 2026
Datadog

Troubleshoot Kubernetes inference workloads with Datadog

Datadog introduces Kubernetes inference workload monitoring in Preview, bringing model configuration, serving resources, pod readiness, runtime metrics, and GPU capacity into a unified view. Teams can trace inference issues across supported vLLM frameworks and investigate scheduling constraints with Kubernetes Explorer and MCP tools.

Datadog’s Kubernetes inference workload, now available in Preview, connects the orchestration configuration declared in custom resources with the resources they manage across the cluster.

Bring inference resources into one workload view

According to CNCF’s 2025 survey, 66% of organizations hosting generative AI models reported using Kubernetes for some or all of their inference workloads.

In Datadog, an inference workload is a virtual resource that groups the Kubernetes resources supporting a serving model. In Kubernetes Explorer, model, framework, and cluster context help you identify the workload to investigate. From its workload view, examine related resources such as pods, deployments, replica sets, and the custom resources that control them. The available details depend on the framework and its configuration.

Datadog already lets you inspect custom resources in Kubernetes Explorer. Inference workload monitoring brings the custom resource, its underlying Kubernetes objects, and the inference engine—such as vLLM running inside the serving containers—into one workload view.

Correlate telemetry across workload components

Datadog automatically detects pods running supported inference frameworks and assigns inference_workload and inference_workload_component tags. Metrics, traces, and logs inherit these tags when they can be linked to those pods. You can use the tags to correlate telemetry for a workload or component across Datadog products.

Inference workloads are also exposed through Datadog’s Kubernetes MCP tools. Through an MCP-compatible assistant, you can discover inference workloads and identify their model and framework. Use the Kubernetes resource tools to inspect underlying resource details, parent relationships, and manifests as you investigate pod state and configuration.

Investigate inference readiness and resource usage

A running pod alone does not establish that the serving system is healthy. Routing, cache state, and the relationship between serving components can also affect performance.

Use the Components tab to inspect pod health within the framework’s serving structure, such as Ray head and worker components or Dynamo frontend and worker components. The topology shows each component’s readiness and pod counts, with the selected component’s pods listed below. Inspect pod status, restarts, node placement, and scheduling details to distinguish pods waiting for resources from running pods that are unhealthy.

Use the Metrics tab to examine runtime performance and resource usage. For Dynamo workloads with paid GPU Monitoring access and the relevant collection configured, available metrics include GPU memory, activity, and occupancy, plus container CPU and memory usage. Compare these signals across running pods to identify resource pressure, then select View in GPU Monitoring to investigate device health. Together, pod state and GPU telemetry help you determine whether to focus on orchestration, capacity, or hardware.

Investigate GPU capacity constraints

The custom resource defines how the inference workload should run; resource status and pod readiness show whether that configuration is taking effect. Consider a critical Dynamo model with separate prefill and decode components. After noticing an outlier in the main table or receiving a model alert, you open the workload’s Components tab and find a decode worker pod stuck in Pending. Its scheduling details report insufficient capacity for the required GPU type, explaining why the requested serving capacity has not become available.

Find capacity to reclaim

To find capacity you could reclaim, filter the Inference Workloads page by that GPU type and examine other workloads using it. In this example, a lower-priority Dynamo model consumes capacity that the critical workload needs. Review the model demand and resource configuration to assess whether scaling it down is appropriate. For customers with GPU Monitoring enabled, follow the “View in GPU Monitoring” link to examine usage and device health alongside the scheduling evidence.

Investigate with Bits

Investigate with Bits uses Kubernetes MCP tools to gather workload context about the pending pods and recommend next steps. In this scenario, reducing the lower-priority model’s replicas could release GPU capacity for the critical model’s decode worker, provided the released resources satisfy its scheduling requirements.

Start investigating Kubernetes inference with Datadog

Datadog’s Kubernetes inference workload connects orchestration configuration with serving readiness, helping teams move from a model-level symptom to the pods and capacity constraints behind it. Use that context to investigate placement failures, identify opportunities to reallocate GPUs, and evaluate changes to the workloads involved.

Learn more about Datadog Container Monitoring and GPU Monitoring. If you’re new to Datadog, sign up for a free 14-day trial.
Original source
Nov 9, 2026
Date parsed from source:
Nov 9, 2026

First seen by Releasebot:
Nov 11, 2026
Datadog

Investigate Kubernetes health and processes with the Datadog MCP Server

Datadog expands its MCP Server with Kubernetes control plane health tools, Live Processes search, and a process guidance skill, helping AI agents investigate cluster health, process activity, resource usage, and instrumentation coverage using read-only observability data.
When investigating issues with a Kubernetes service, SREs and platform engineers need to understand what’s happening across its supporting infrastructure. For example, is a process still running? Did it restart? Is the scheduler struggling to place pods? Finding the answers to these questions often requires engineers to search process inventories, examine resource metrics, and query Kubernetes control plane telemetry. AI agents can help with these investigations, but they need access to the right data and enough context to interpret it. Otherwise, they may spend excess time discovering available metrics and constructing queries, or end up working with incomplete information.

The Datadog MCP Server connects AI assistants to observability data in Datadog through the Model Context Protocol (MCP). We’ve expanded our MCP Server’s infrastructure investigation capabilities with Kubernetes control plane health tools, Live Processes search, and a processes skill that guides agents toward the appropriate data source for each question. Together, these capabilities help agents investigate infrastructure issues by using process observations, resource metrics, and control plane health signals collected by Datadog.

In this post, we’ll show how you can:

Check Kubernetes control plane health in a single call

Give agents process-level evidence with Live Processes search

Answer broader process questions with the processes skill

Check Kubernetes control plane health in a single call

Kubernetes control plane issues can affect workloads even when the underlying nodes appear healthy. For example, pods that remain in Pending might indicate scheduling problems, while slow kubectl responses can point to API server latency or resource contention. Diagnosing these problems requires examining different metrics depending on which control plane component is affected.

The Datadog MCP Server provides four read-only tools that enable AI agents to assess the health of a Kubernetes cluster, retrieving a set of relevant health metrics for a specific cluster in one call:

API server: Examine request error rates, rate-limited client requests by verb and resource, maximum in-flight requests, requests rejected by API Priority and Fairness, and queued requests by priority level.

Scheduler: Review scheduling attempts, scheduling attempt duration, scheduling algorithm duration, and pod scheduling duration to identify delays in placing workloads.

Controller manager: Inspect work queue depth, additions to work queues, processing duration, time spent waiting in queues, goroutine counts, and thread counts.

etcd: Check leader availability, leader changes, failed write proposals, backend commit duration, write-ahead log (WAL) fsync duration, and peer round-trip time.

Each tool accepts a Kubernetes cluster name through the kube_cluster_name parameter and an optional time window. The default window is the last 10 minutes, and queries can cover up to 4 hours. Before querying metrics, the tool checks whether Datadog recognizes the specified cluster.

For example, suppose pods in the checkout-cluster cluster have remained in Pending for 20 minutes. You can ask your AI assistant, “Pods have been stuck in Pending on checkout-cluster for 20 minutes. Is the scheduler keeping up?” The agent can call the scheduler health tool to retrieve scheduling attempts and duration metrics for that cluster. By examining the returned signals, it can help determine whether scheduling delays warrant further investigation. You can also ask whether etcd has experienced leader changes or slow commits over the past hour, or request a broader assessment of control plane health.

With these tools, agents can investigate control plane issues without first searching the metric catalog or constructing individual queries for each signal. Each metric the tools provide includes:

A plain-language description

An individual status of OK, no data, or error to help agents distinguish missing telemetry from successful query results, and so that a missing metric does not cause the entire tool call to fail

The exact Datadog query used to retrieve the metric, which engineers can reuse in dashboards, notebooks, or monitors to examine the metric during future incidents

The tools operate on telemetry data already collected by Datadog. They do not execute commands inside Kubernetes clusters or modify cluster resources. Access follows the calling user’s permissions, including Timeseries Query, Metrics Read, and Hosts Read.

The control plane tools complement our existing Kubernetes MCP tools, which help agents find and inspect Kubernetes resources. An agent can use those tools to investigate affected workloads, then query the control plane tools to determine whether cluster-level behavior might explain the symptoms.

Give agents process-level evidence with Live Processes search

The search_datadog_live_processes tool gives AI agents access to recent process observations collected by Datadog’s Live Processes. Agents can search for processes by executable, command line, tags, or observation time to investigate whether a process is running, when it started, and which user owns it.

Process-level evidence is useful when service metrics indicate a problem but do not explain the behavior of an individual process. For example, a service might experience intermittent failures because a process restarted, or an engineer might need to confirm which command-line arguments a process received when it started.

The Live Processes search tool returns information including:

Executable name and command line

Process ID (PID) and parent process ID (PPID)

Process owner and host

Process start time and last observation time

Process tags

Agents can filter observations by searching executable names or command lines, or by using exact tags such as host, service, env, Kubernetes metadata, and user: for process ownership. The tool searches for a default window of 15 minutes. Live Processes retains observations for 36 hours, and individual queries can cover up to 1 hour.

Suppose an engineer suspects that PostgreSQL restarted on a production database host. They can ask, “Did the Postgres process on db-prod-03 restart within the last day?”

The agent can search process observations for the specified host and executable, then compare process start times to identify evidence of a restart. Similarly, an engineer could ask which processes the deploy user is running on a host or which command-line arguments NGINX is using on checkout hosts.

In an internal evaluation against live production data, Datadog tested the Live Processes search tool across 10 natural-language scenarios, with three runs per scenario. Answer correctness increased from 10% without the tool to 96.7% with it—i.e., in 96.7% of runs, the returned process records matched the public API. These results indicate how direct access to process observations can improve agent responses for the evaluated questions.

Keep process search results within an agent’s context budget

A single process in a Kubernetes environment can carry more than a hundred tags from its host, container, cluster, and cloud environment. Returning every tag for every process can consume much of an agent’s available context before it has analyzed the results. The Live Processes search tool limits response size to help agents work with process data from heavily tagged infrastructure.

The tool enforces a token budget of 10,000 tokens by default. It also provides pagination cursors and indicates when results have been truncated. Agents can use this information to recognize incomplete responses and refine their searches.

For broad process inventory or counting questions, agents can set include_tags: false to omit detailed tag information. This reduces the size of each process record and allows more processes to fit in a response. For targeted investigations, agents can retain tags to identify the processes associated with a particular service, host, or Kubernetes workload.

Datadog also removes secrets from returned command lines before passing them to the agent. The search tool is read-only and uses the calling user’s Hosts Read permission.

Answer broader process questions with the processes skill

Live Processes search provides evidence about individual processes. For questions involving process discovery, instrumentation coverage, or resource consumption over time, agents need to choose from additional Datadog data sources.

The datadog/infrastructure/processes skill helps AI agents choose the appropriate Datadog data source for process-related questions. The skill provides guidance on process discovery, Live Processes observations, and process metrics, including which data to query and how to interpret the results.

Datadog provides three complementary sources of process information, each suited to different investigation tasks:

Discovered processes: Use DDSQL to investigate service identity, programming language, vendor software, integrations, APM tracer detection, and process placement across hosts, containers, and Kubernetes resources. Discovery provides hourly snapshots and does not require Live Processes to be enabled.

Live Processes: Use search_datadog_live_processes to investigate observed processes, command lines, ownership, start times, and evidence of restarts.

Process metrics: Query per-process CPU usage through process.stat.cpu.total_pct and resident memory usage through process.stat.memory.rss. Agents can analyze rankings or timeseries covering up to 36 hours by using code execution with the Datadog TypeScript SDK.

The skill helps agents route questions to the source most likely to answer them. For example, asking where Redis is running across a fleet is a discovery question. Asking whether a specific Redis process restarted requires Live Processes observations. Investigating whether a process’s memory usage has increased over the last hour calls for process metrics.

The processes skill can guide an agent through questions that combine service identity with infrastructure context. For example, an engineer investigating instrumentation coverage could ask, “Which services in the payments namespace don’t have APM?” The agent can use discovered process data to identify application processes in the specified namespace and inspect whether Datadog detected an APM tracer. For resource investigations, an engineer could instead ask, “Which process is using the most memory on web-prod-01 over the last hour?” The skill directs the agent toward process memory metrics, enabling it to compare processes over the requested time window.

The processes skill also provides guidance for situations in which an agent might draw the wrong conclusion from an incomplete response. For example, an empty process discovery result does not necessarily mean that the process is absent, but simply that coverage is missing for the relevant environment. The skill also explains how to handle truncated Live Processes search results, instructing the agent to narrow its filters and retry the same page before following the pagination cursor.

When Live Processes is not enabled, the skill provides setup guidance for supported environments, including the Datadog Agent, Docker, Helm, the Datadog Operator, and Amazon ECS Fargate. The guidance also accounts for plan and billing requirements. Any remote configuration change through Fleet Automation requires explicit user approval.

By teaching agents how to select data sources and handle incomplete observations, the processes skill helps them produce answers grounded in the available evidence.

Get started with Kubernetes investigations through the Datadog MCP Server

The Datadog MCP Server makes Kubernetes control plane metrics and process data available to AI assistants through read-only investigation tools. Combined with the processes skill, these capabilities help SREs and platform engineers investigate cluster health, process restarts, resource usage, and instrumentation coverage by using natural-language questions.

To get started, connect your AI assistant to the Datadog MCP Server. Supported clients include Claude Code, Cursor, Codex, GitHub Copilot, and VS Code.

Enable the relevant MCP toolsets for your investigation:

Processes: Enable the processes toolset to access Live Processes search. The processes skill is available when either the processes or ddsql toolset is enabled.

Kubernetes control plane: Enable the kubernetes-ops-center toolset to query API server, scheduler, controller manager, and etcd health metrics.

Live Processes must be enabled to use the search tool and process metrics. For control plane investigations, Datadog must already be collecting the relevant metrics from the cluster. Available metrics can vary by Kubernetes distribution and managed service.

The processes tools require Hosts Read permission. Control plane tools require Timeseries Query, Metrics Read, and Hosts Read permissions.

For more information, explore the Datadog MCP Server’s Kubernetes tool documentation. If you don’t have a Datadog account, sign up for a 14-day free trial to start investigating your containerized infrastructure and more with Datadog.
Original source
Nov 5, 2026
Date parsed from source:
Nov 5, 2026

First seen by Releasebot:
Nov 5, 2026
Datadog

Manage Kubernetes observability with DatadogInstrumentation

Datadog introduces DatadogInstrumentation, a Kubernetes-native resource that lets workload teams manage checks, logs, and APM settings together. Teams can update checks and log processing without rolling out applications or restarting the Agent, while tracing and profiling changes apply to new pods.
For teams that own an application running on Kubernetes, updating its observability configuration should be as straightforward as updating any other Kubernetes resource. But configuring integration checks, log collection, and tracing often means working across multiple configuration paths. If those settings live in pod annotations, adding a metric check or changing log processing rules requires a Deployment rollout. If they live in Datadog Agent configuration files, an application team must coordinate the change with the platform team, which may need to restart the Agent.

The DatadogInstrumentation custom resource provides a Kubernetes-native way to manage observability configuration for individual workloads. DatadogInstrumentation brings integration checks, log collection, and Application Performance Monitoring (APM) settings into a single Kubernetes custom resource. Unlike pod annotations, which require an application rollout to change, DatadogInstrumentation applies check and log changes at runtime, without restarting the application or the Agent. Application teams can configure observability by using the same tools and workflows they use to manage their Deployments. Platform teams retain control of the Datadog Agent deployment.

In this post, we’ll show you how to use DatadogInstrumentation to:

Configure observability for a specific Kubernetes workload

Define metrics, logs, and traces in one resource

Change observability configuration independently of application releases

Configure observability for a specific Kubernetes workload

Instead of spreading observability settings across pod annotations and Agent configuration, teams consolidate them in one DatadogInstrumentation manifest for each workload and manage that manifest through version control.

Consider an example team that operates a checkout application and manages it with a Deployment in the apps namespace. To configure the application’s observability, the team uses a DatadogInstrumentation resource alongside its Deployment manifest. When the team needs to change what telemetry data it collects, it edits the resource and reviews the change in a pull request. It then applies the change through its GitOps workflow, just as it does for its Deployment.

Define metrics, logs, and traces in one resource

Moving the checkout service to DatadogInstrumentation replaces two separate configuration sources with one resource. The following example walks through the equivalent DatadogInstrumentation resource, then shows how the team applies and verifies it.

Without DatadogInstrumentation: Settings split across the DatadogAgent resource and annotations

The checkout team’s observability settings live in two places. The platform team deploys the Agent with the Datadog Operator and maintains APM targeting rules in the Operator’s DatadogAgent resource, including a rule that selects the checkout pods and configures their Java SDK and trace settings. The checkout team configures its HTTP check and log collection as JSON in annotations on the Deployment’s pod template.

With this split, a tracing change means asking the platform team to edit its DatadogAgent resource. A change in checks or log configuration requires editing the pod template, which triggers a rollout of the application.

With DatadogInstrumentation: Checks, logs, and APM in one resource

After adopting the DatadogInstrumentation custom resource definition (CRD), the checkout team consolidates these settings into a single Kubernetes resource. In the following example, the spec.targetRef points to the checkout Deployment and the spec.config specifies how the Datadog Agent collects metrics, logs, and traces from that application.

apiVersion: datadoghq.com/v1alpha1 kind: DatadogInstrumentation metadata: name: checkout-instrumentation namespace: apps spec: targetRef: apiVersion: apps/v1 kind: Deployment name: checkout config: checks: - integration: http_check containerName: checkout instances: - name: checkout-health url: "http://%%host%%:8080/health" collect_response_time: true logs: - containerName: checkout source: java service: checkout tags: - env:production - team:checkout apm: enabled: true ddTraceVersions: java: "default" ddTraceConfigs: - name: DD_SERVICE value: checkout - name: DD_ENV value: production

Metrics: The spec.config.checks section defines the HTTP check as structured YAML instead of embedded JSON. The check polls the checkout container’s /health endpoint and records response times, and containerName selects the container to check. The Autodiscovery template variable %%host%% resolves the container’s IP address at runtime, so the configuration doesn’t depend on hardcoded addresses that change as pods are replaced.

Logs: The spec.config.logs section sets the logs’ source and service values for the checkout container and adds tags. See Kubernetes log collection with DatadogInstrumentation for more information about collecting logs.

Traces: The spec.config.apm section enables Single Step Instrumentation (SSI) for the workload. ddTraceVersions selects the Java SDK, and ddTraceConfigs sets the service name and environment—the same settings the platform team set in its DatadogAgent targeting rule, but the checkout team now owns them. The resource’s targetRef selects the workload. SSI adds the specified SDK to eligible application pods when they’re created.

Apply the resource and verify the configuration

DatadogInstrumentation provides configuration feedback through Kubernetes. The Cluster Agent validates the resource at apply time, so in the case of an invalid configuration, kubectl apply returns an error.

After successfully applying the resource, the team checks its ChecksReady, LogsReady, and APMReady status conditions with kubectl describe to diagnose any issues:

kubectl describe datadoginstrumentation checkout-instrumentation -n apps

The status conditions confirm that the Cluster Agent accepted each section of the configuration:

Status: Conditions: Message: 1 check(s) configured for Deployment/checkout Reason: Configured Status: True Type: ChecksReady Message: 1 log config(s) configured for Deployment/checkout Reason: Configured Status: True Type: LogsReady Message: APM settings configured for Deployment/checkout; restart the workload to apply them Reason: Configured Status: True Type: APMReady

To verify the data collection, the team checks Datadog to see network.http.can_connect and network.http.response_time metrics, logs from the checkout service, and, once the pods have been replaced, traces from checkout in APM.

Change observability configuration independently of application releases

Suppose the checkout team is investigating intermittent slow requests and needs to change what it collects. It wants to see additional application metrics to understand the cause of any backlogs, mask customer email addresses in its logs, and enable profiling to identify where requests spend time. The team makes all three changes in its existing DatadogInstrumentation resource following its GitOps workflow, without changing the Deployment or the Agent configuration.

Add an OpenMetrics check

To see whether slow requests correlate with a growing backlog, the team adds an OpenMetrics check alongside its existing HTTP check. The new integration: openmetrics entry shown here collects checkout_active_requests and checkout_queue_depth from the application’s /metrics endpoint and reports them as checkout.active_requests and checkout.queue_depth.

config: checks: - integration: http_check containerName: checkout instances: - name: checkout-health url: "http://%%host%%:8080/health" collect_response_time: true - integration: openmetrics containerName: checkout instances: - openmetrics_endpoint: "http://%%host%%:8080/metrics" namespace: checkout metrics: - checkout_active_requests: active_requests - checkout_queue_depth: queue_depth

After the team applies the updated resource, the new check takes effect without requiring an application rollout or Agent restart.

Mask sensitive data in logs

Next, the team adds a processing rule that masks email addresses so logs can be viewed and shared without compromising privacy:

logs: - containerName: checkout source: java service: checkout tags: - env:production - team:checkout log_processing_rules: - type: mask_sequences name: mask_email_addresses pattern: '[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Za-z]{2,}' replace_placeholder: '[REDACTED_EMAIL]'

The mask_sequences rule replaces any email address in a log message with [REDACTED_EMAIL] before the Agent sends the log to Datadog, so customer email addresses in logs aren’t stored. As with the new check, the updated log configuration takes effect without an application rollout or Agent restart. The team can inspect the resource status for configuration feedback, then check logs in Datadog to verify that data is being redacted.

Enable Continuous Profiler

Finally, the team enables profiling in its APM configuration so they can troubleshoot any backlogs by visualizing where requests spend their time:

apm: enabled: true ddTraceVersions: java: "default" ddTraceConfigs: - name: DD_SERVICE value: checkout - name: DD_ENV value: production - name: DD_PROFILING_ENABLED value: "auto"

Adding DD_PROFILING_ENABLED to spec.config.apm.ddTraceConfigs enables Continuous Profiler through the Java tracer, and the auto value profiles only eligible processes, as the SSI documentation recommends. Because the change applies only to new pods, the team triggers a rollout to replace the existing ones. The Continuous Profiler shows that most threads’ wall time is spent waiting for a payment worker to become available, represented by the acquirePaymentWorker span.

Get started with DatadogInstrumentation

With DatadogInstrumentation, application teams change checks and logs on their own schedule, without an application rollout or an Agent restart. Every change in this post’s example happened in the same resource. Changes to tracing and profiling take effect when pods are created, so the team applies them with its next rollout. Platform teams continue to manage the Datadog Agent deployment, while workload owners configure the checks, logs, and traces their services need.

The example in this post, which combines checks, logs, and APM, requires Datadog Agent and Datadog Cluster Agent (both v7.85 or later), with Datadog Operator v1.31 or later or Datadog Helm chart v3.255.0 or later. To get started, install the DatadogInstrumentation CRD with the Datadog Operator or the Datadog Helm chart.

Next, follow the DatadogInstrumentation Autodiscovery setup guide, which lists version requirements and supported workloads. For configuration options, see the documentation for Kubernetes log collection and workload-specific APM instrumentation.

If you don’t already have an account, you can sign up for a free 14-day trial.
Original source
Nov 4, 2026
Date parsed from source:
Nov 4, 2026

First seen by Releasebot:
Nov 4, 2026
Datadog

Migrate Splunk queries, alerts, and dashboards to Datadog

Datadog releases Translate and Import for Log Management customers, making it easier to move Splunk queries, alerts, and dashboards with query validation, bulk migration, progress tracking, and draft publishing.
Moving your logs to a new platform is only part of a migration. Over the years, your teams have built saved searches, alerts, and dashboards in Splunk’s Search Processing Language (SPL). These assets capture which errors matter, which conditions trigger paging alerts, and which views an on-call engineer opens first. Rebuilding that library by hand is slow and error-prone, typically requiring you to inventory every asset, learn a new query syntax, rewrite each search, and manually confirm that the results match. This work can be complex and time-consuming even for experienced users, and often delays or blocks a migration entirely.

Datadog’s in-app migration tools, Translate and Import, help you recreate your SPL queries, alerts, and dashboards in Datadog without rewriting them from scratch. In this post, we’ll show how you can:

Translate and validate individual SPL queries

Import alerts and dashboards in bulk

Track your migration over time

Simplify searches with native Datadog features

Translate and validate individual SPL queries

Datadog’s Translate tool converts individual SPL queries into Datadog log searches and lets you validate the results against your own logs. Suppose you run an ecommerce platform and want to confirm that your critical observability workflows and assets will carry over to Datadog. One of the assets is a storefront health scorecard that tracks request counts, error rates, and latency across different endpoints. The underlying query that powers the scorecard combines search filters, conditional evaluations, aggregations, and commands to filter and sort the results:

search service=web-store http.status_code=* NOT http.url_details.path="/_health" | eval is_5xx=if('http.status_code'>=500,1,0), is_4xx=if('http.status_code'>=400 AND 'http.status_code'<500,1,0) | stats count AS requests, sum(is_5xx) AS errors_5xx, sum(is_4xx) AS errors_4xx, avg(duration) AS avg_ms, perc95(duration) AS p95_ms, max(duration) AS max_ms, dc(host) AS hosts BY controller, http.url_details.path | eval error_rate_pct=round((errors_5xx / requests)*100,2), avg_ms=round(avg_ms,1), p95_ms=round(p95_ms,1) | where requests > 100 | sort - error_rate_pct | head 10

In Datadog Log Management, open Translate and paste the query. Alongside the translation, you get:

A step-by-step explanation that maps each part of the SPL pipeline to its Datadog equivalent, so you can learn the new syntax as you go

Live results from your own logs, so you can check that the output matches what you saw in Splunk

Quick actions, such as opening the search in the Log Explorer or creating a monitor from it

Because the results come from your live data, you can spot problems right away. For example, if a field is named differently in Datadog than it was in Splunk, the results show you before you’ve built anything on top of the query.

Import alerts and dashboards in bulk

While you can use Translate to convert and validate individual SPL queries, Import enables you to translate alerts and dashboards in bulk. Import saves you from having to translate hundreds of assets separately and reduces the risk of overlooking one that matters.

In Log Management, open Import and follow the in-app instructions to export your saved searches, alerts, and dashboards from Splunk. You don’t need to install anything in your Splunk environment. Then drag the export file into Datadog.

Datadog translates each asset into its Datadog equivalent:

Splunk alerts become Datadog monitors, with the translated query and the original trigger conditions.

Splunk dashboards become Datadog dashboards, translated widget by widget.

Datadog keeps translated monitors and dashboard definitions as drafts until you’re ready to publish the assets. You can open any translated monitor or dashboard, compare it with the SPL that it came from, and check its results against your data. When you have verified the translation, publish it to make it available to your team. Publishing creates standard Datadog monitors and dashboards, so you can manage them the same way as any others, including through the API and Terraform.

In early access, one design partner translated 62 of 62 queries from a batch in a single bulk run. Another team uploaded more than 1,500 alerts at once with help from Datadog Implementation Services on the first pass.

Track your migration over time

A large migration happens in waves: one team, one Splunk app, or one set of critical alerts at a time. Import keeps every upload in a single inventory, so you can see the migration status of each asset without keeping a separate spreadsheet.

For each import, you can see which assets were translated, which were skipped, and which you’ve already published. You can filter by asset type or status to focus on what still needs work.

When Datadog can’t translate an asset reliably, it marks the asset as skipped instead of publishing a monitor or widget that might return the wrong results. Assets are usually skipped for a few reasons, such as an SPL command that the tools don’t support yet or a dashboard that depends on Splunk-specific features like summary indexes. You can adjust the SPL and import those assets again, finish the query in Translate, or ask Bits AI to help rewrite it.

Simplify searches with native Datadog features

Translating your existing assets gets your teams working in Datadog quickly. A migration is also a good time to simplify searches that grew in size, scope, and complexity. Several SPL patterns have a more direct equivalent in Datadog:

Search-time field extraction with rex: Use Tap to Parse to turn values buried in a log message into structured fields in one click, without writing a regular expression.

Lookups and subsearches: Use subqueries and Reference Table joins to filter or enrich logs with related events or external metadata, including in log monitors.

Scheduled searches that send results via email: Use scheduled CSV reports to deliver Log Explorer results to email or Slack on a recurring schedule.

Long, multi-stage pipelines: Use Notebooks analysis cells to chain transformations or write SQL when a single log search isn’t enough.

Start migrating your Splunk assets to Datadog

Translate and Import are generally available to Log Management customers in all Datadog sites except US1-FED, at no additional cost. You can check queries against your own logs, translate your full library in bulk, and publish each asset individually or all at once when you’re ready. To get started, see the Query Translation migration documentation. If you’re planning a large migration, your Datadog account team can help.

If you’re new to Datadog, you can sign up for a 14-day free trial to start using Translate and Import.
Original source
Nov 4, 2026
Date parsed from source:
Nov 4, 2026

First seen by Releasebot:
Nov 4, 2026
Datadog

Compare AI agent changes with Online Experiments in Agent Observability

Datadog introduces Online Experiments in Agent Observability, helping teams compare AI agent variants on live production traffic. Teams can assess response quality alongside cost, latency, token use, and errors, then inspect traces to understand behavior and guide improvements.
Improving an AI agent often involves changing its prompts, models, retrieval methods, or tools. But determining whether those changes actually improve performance can be difficult. A revised prompt might produce better answers for a handful of test cases but perform poorly on unexpected user requests. A cheaper model might reduce token costs while introducing tool-calling errors or longer execution times. Before rolling out a change, teams need to understand how it affects agent quality, reliability, and cost under real usage.

Datadog Online Experiments, available in Agent Observability, enables teams to compare agent variants by using live production traffic and measure how a change impacts agent behavior and performance. By bringing agent evaluations together with Datadog Experiments, Online Experiments helps you assess response quality alongside operational metrics such as latency, cost, token usage, and errors. You can also investigate the underlying traces to understand why an agent change caused variations in behavior.

In this post, we’ll walk you through:

The differences between offline and online experiments

How Datadog Online Experiments helps you compare agent variants using real production traffic

How we used Online Experiments internally to evaluate a model change

Offline versus online experiments for AI agents

Offline experiments are an integral part of agent development. They let teams run versions of their agents against predefined datasets, compare outputs, and catch known regressions before deployment, without waiting for them to appear in live traffic. In Datadog Agent Observability, offline experiments support testing for both individual components and complete agent workflows.

But building comprehensive offline evaluation datasets takes time and product knowledge. Teams need to choose representative requests, agree on what good behavior looks like, and decide which checks would reveal a regression. A model-based judge needs a rubric your team understands and a human to check its assessments. The work continues as your product changes: New workflows expose gaps in the dataset, tools return different information, and a judge that captures one failure mode may miss another. Early in development, you may still be discovering the requirements that would let you choose the right cases and criteria.

Online experiments test performance and behavior in agent variants based on real user interactions. They rely on online evaluations, which score agent behavior in production, rather than predefined test cases. This allows you to compare how different versions of your agent behave under production workloads, so you can catch patterns that you may not otherwise have included in your offline evaluation datasets.

For example, consider a support agent that retrieves documents to answer customer questions. Your team might discover that its search tool frequently returns long passages, causing the agent to perform repeated searches before generating an answer. With offline evaluations, you could modify the tool to return shorter excerpts and check whether the agent still cites relevant evidence. But these tests might not capture the full range of requests users make or reveal whether the change helps users resolve their issues.

Online evaluations help you see, for example, whether users bring requests your team did not anticipate or ask follow-up questions, so you can better determine if the change you’ve made helps users resolve their issues. You can then run online experiments that use those scores to compare different versions of your agent. You keep the existing version as a control and test a changed version over the same period, using random assignment to separate the effect of your change from existing differences in usage (e.g., a revised search tool looks better because it receives easier questions). This helps you establish which version of your agent performs best in real production situations and, in turn, enables you to build better offline evaluation datasets as well.

Compare agent variants using real production traffic with Datadog Online Experiments

Running online experiments requires teams to connect each agent variant they are testing to the appropriate measurements and analyze the differences in performance. Datadog Online Experiments brings Agent Observability data together with Datadog Experiments to help you manage this process. You can use evaluators you’ve created in Agent Observability and connect their scores to experiment metrics, alongside the operational measures you choose to collect. With assignment and measurement configured, Experiments calculates the relative changes and confidence intervals.

You also choose how much exposure a change should receive. Once the variants are wired into your application, Datadog Feature Flags can manage the traffic split and let you adjust exposure without deploying the application again. You can begin with a small share of users while retaining a control group for the comparison.

The measures should reflect the decision you’re making. A revised tool might improve evidence quality while adding extra searches. A cheaper model might require more attempts to complete a task. Comparing evaluation scores with duration, cost, and errors helps you see those trade-offs.

From your experiments, you can also view traces in Agent Observability to inspect the individual executions: which tool the agent called, what arguments it supplied, and how it responded to the result. This provides context that helps you dig deeper when an experiment leaves you with questions. For example, a promising cost result may justify pursuing a change, while uncertainty about its other effects warrants a closer look. Next, we’ll show you how we used Online Experiments internally at Datadog to assess this exact type of change in one of our own agents.

How we used Online Experiments to evaluate a model change

We used Online Experiments to compare OpenAI’s GPT-5.6 Luna and GPT-6 Luna in our Insights agent, which investigates agent behavior by using trace evidence. We wanted to test whether Luna 6’s lower model prices translated into cheaper investigations and understand what the change meant for investigation quality and tool behavior. We split traffic evenly between the models, keeping Luna 5.6 as the reference while evaluating Luna 6 under real usage.

Our primary measure was investigation quality. An LLM judge scored investigations from 1 to 5 using the request, tool inputs and outputs, and the agent’s conclusions. The rubric covered accuracy, completeness, and how well conclusions followed from the available evidence, including whether the agent acknowledged uncertainty or missing data. We collected duration, estimated cost, estimated token usage, and workflow errors from the agent’s traces as separate measures.

Online Experiments brought those scores and operational measures into the same comparison in Agent Observability. We could assess cost alongside the work the agent performed to complete an investigation.

Luna 6’s estimated cost was 44.3% lower. The confidence interval—a range of differences consistent with the data—ran from 37.5% to 51.2% lower. This result supported our hypothesis that the model change could reduce investigation cost. Quality scores were close at 3.84 for Luna 5.6 and 3.86 for Luna 6, although close averages alone do not establish equivalent quality.

Duration and workflow errors left more uncertainty. The best estimates were 12.8% higher duration and 13.6% more workflow errors. But the duration interval ranged from 4% lower to 30% higher, and the error interval from 16% lower to 43% higher—effectively, a range between little-to-no difference and a meaningful increase. We inspected the traces to understand the risk before deciding whether to proceed.

In the traces we reviewed, Luna 6 supplied invalid tool parameters more often than Luna 5.6. It usually corrected those errors after retries. Our quality judge considered tool use, but its overall score did not tell us how often calls failed or how much work recovery required. We were thus able to use traces to expose a specific behavior in the agent’s handling of tool calls that could be improved in the Luna 6 version of the agent. We addressed the tool parameter issue that our investigation uncovered before proceeding with the Luna 6 version that helped us lower costs.

The experiment also revealed next steps that could help us improve our agent in the future. The failed calls we found are useful candidates for offline regression tests. A follow-up online experiment could test a change to tool definitions or error feedback while continuing to measure quality, duration, and cost.

Improve AI agents faster with Online Experiments in Agent Observability

Datadog Online Experiments helps teams evaluate AI agent changes under real production conditions, compare quality and operational performance, and investigate unexpected behavior by using traces. Whether you’re testing a different model, refining retrieval, or modifying a tool, controlled experiments provide evidence to help you determine which changes improve your agent and which require further work.

The findings from each experiment can also help improve offline evaluation coverage. As your team discovers new failure modes and user workflows, you can turn those observations into regression tests and use subsequent experiments to measure whether your fixes work under real usage.

Online Experiments is free for Agent Observability customers submitting up to 40,000 LLM spans per month. To learn more about getting started with Agent Observability, see the product page and documentation.

New to Datadog? Start a 14-day free trial.

Startup? Eligible companies get a year of free Datadog credits. Apply here.
Original source
Nov 4, 2026
Date parsed from source:
Nov 4, 2026

First seen by Releasebot:
Oct 21, 2026

Modified by Releasebot:
Nov 4, 2026
Splunk Enterprise Security by Splunk

Splunk Enterprise Security 8.8.0

Splunk Enterprise Security releases version 8.8 with agentic SOC capabilities, investigation aggregation, detection reruns, expanded exposure analytics and access controls, plus dashboard and automation improvements for security teams.
Release notes for Splunk Enterprise Security

Find the following information on the Splunk Enterprise Security version 8.8.0 release:

What's new

Upgrade notice for 8.x

Compatibility and support

Deprecated or removed features

Add-ons

Included libraries

What's new in 8.8.0

Splunk Enterprise Security version 8.8.0 was released for General Availability on November 4, 2026 and includes the following new enhancements:

Note: Features included in Enterprise Security Essentials Edition are also included in Enterprise Security Premier Edition.

Note: If you are on Splunk Platform version 10.6 or higher and plan to upgrade to Splunk Enterprise Security version 8.8 or higher, you might experience an increased maintenance window during the upgrade. For details, see Version specific upgrade notes.

Agentic SOC Agents and Features — Agentic SOC for Cloud Connected deployments bringing the power of AI and increased automation. Detection Builder Agent now supports the inclusion of instructions to maintain repeatable guidance and output. AI chat now supports the ability to attach files for providing additional context. Edition depends on specific agent.

Investigation Aggregation — Routes related findings and finding groups into meaningful cross-domain investigations, reducing alert noise and accelerating analyst response. It includes configurable, stack-ranked rules and timing to connect events, prioritize threats, and provide a clearer, actionable view of security incidents. Essentials and Premier.

Detection Rerun — Re-run detections that were missed or failed due to outages or errors, on demand. When scheduled detections are skipped or fail, security teams can recover those historical windows and restore threat coverage against past data. Essentials.

RBAC: Controlling Detections, UEBA, A&I, and Threat Intel — Adds custom role templates to aid in the creation and setting of permissions for custom roles without needing to apply role inheritance. Extends role-based access control across detections, UEBA, A&I, and threat intelligence so teams can apply finer-grained permissions and strengthen governance across non-team queue areas of Enterprise Security. Essentials.

UEBA Dataset Management — Transform CIM, OCSF, and indexed log data into UEBA datasets to expand the data available for UEBA detections. Premier.

Insider Threat Matrix annotations for UEBA detections — Annotates UEBA detections with Insider Threat Matrix (ITM) tactics and techniques alongside the existing MITRE ATT&CK mapping. Analysts can filter the UEBA dashboard and Explorer by ITM technique, see which techniques their enabled detections already cover, and sort by coverage to find gaps in insider threat monitoring. Premier.

New UEBA detections — New UEBA detections focused on insider threat data exfiltration available for cloud deployments. Premier.

Exposure Analytics - Entity posture — Proactively identify security control gaps across assets and users. Add metrics to help monitor and strengthen overall security posture. Essentials.

Exposure Analytics - Entity profile — Proactively identify contextual risk across assets and users based on context and security posture. Profile rules help to prioritize exposure remediation and elevate finding risk. Essentials.

Exposure Analytics - Entity actions — Proactively address security issues and contextual risks using automated actions. This helps remediate security gaps, and reduce entity attack surface. Essentials.

Exposure Analytics - Entity analysis enhancements — Add insights from entity posture and profile to Entity Analysis, to help provide additional exposure level context related to the entity under analysis. Essentials.

Quick Search and Advanced Filtering — Helps analysts find what they need faster with streamlined search and advanced filters that make it easy to narrow the queue. Essentials and Premier.

System Insights enhancements — Gain greater visibility into the health and performance of SOAR custom functions and automation brokers with newly added monitoring in System Insights. Premier.

ES-SOAR Pairing Certificate Management — Introduces a self-service feature for storing certificates from a private CA when ES and SOAR are paired. Premier.

Additional authentication support for TAXII2 data sources — The TAXII2 connector for TIM Cloud data sources now supports certificate, API key, and bearer token authentication in addition to basic authentication. Essentials, Premier.

Automation Broker High Availability — Use groups of Automation Brokers to set high availability and scalability for SOAR action execution. Add brokers to a group to scale for higher load and distribute work across them. Premier.

Dashboard Consolidation — Improves the user experience, enhances performance, and consolidates 55 lower-level dashboards into four main dashboards. Groups panels by data model for clarity. Essentials.

Upgrade notice for 8.x

Upgrading Splunk Enterprise Security to version 8.x is a one-way operation. The upgrade process doesn't automatically back up the app, its content, or its data. Perform a full backup of the search head, including the KV Store, before initiating the Splunk Enterprise Security upgrade process.

When you upgrade to Splunk Enterprise Security version 8.x, you can no longer access any investigations created prior to the upgrade. To save archives of your investigation data, back up and restore your existing Splunk Enterprise Security instance.

If you need to revert back to the version that previously existed on your search head, you must restore the previous version of Splunk Enterprise Security from a backup.

Upgrades to Splunk Enterprise Security version 8.x from versions 6.x and earlier are not supported. If you are using on-premises version 6.x or earlier, you must first upgrade to version 7.3.2 before upgrading to version 8.x.

Other important notes for upgrading include the following:

You cannot upload Splunk Enterprise Security 8.x on an on-premises deployment of Splunk Enterprise 10.x using the UI. You must install Splunk Enterprise Security 8.x using the command line.

Splunk Enterprise Security in a search head cluster environment uses an installer that creates tokens and turns on token authorization if it is not available. Post-installation, the installer deletes the tokens. If an error occurs, contact Splunk Support to delete any residual tokens.

The Splunk Enterprise Security Health app is installed but is turned off for all Splunk Cloud customers. This app is turned on by the Splunk Cloud Platform only during upgrades to ensure that the stacks get upgraded faster. Do not turn on the Splunk Enterprise Security Health app.

Share threat data in Splunk Enterprise Security

Sharing telemetry usage data is different from sharing threat data. Sharing of threat data in Splunk Enterprise Security is only introduced for Splunk Enterprise Security Hosted Service Offering (cloud) customers with a standard terms contract renewed or created after January 10, 2025.

Compatibility and support

Splunk Enterprise Security version 8.x is compatible only with specific versions of the Splunk platform.

Current versions of Splunk Enterprise Security only support TAXII version 2.0 and TAXII version 2.0.

Model Runtime in Splunk Security Assistant

Splunk Security Assistant provides the option to use the large language models (LLMs) hosted in Splunk Cloud Platform or models hosted in Azure OpenAI. When you use the Model Runtime feature, letting Splunk determine the best model to use, Splunk Security Assistant determines when to use a Splunk platform hosted LLM, and when to use a third-party LLM, based on your prompt. Third-party LLMs can provide better response quality through the assistant, depending on factors such as use case and cost. ES 8.6 or higher uses Model Runtime by default. Administrators can turn off this functionality at any time from the Settings page.

When you choose to let Splunk determine the best model to use, Splunk AI Assistant can leverage an external large language models (LLM) hosted in Azure OpenAI. This LLM generates the response provided by the app when deemed necessary, and can improve the response quality.

Splunk Security Assistant leverages the additional options from the LLM based on the intent and complexity of the request. The external LLM endpoint is secure but is outside the Splunk platform data boundary. The search prompt is sent to the third-party LLM and is governed by the third-party LLM provider's data handling policy.

The Model Runtime feature includes enterprise-grade compliance and regional data boundaries. Opting in causes no disruption to Splunk Security Assistant services or responsiveness.

When you opt-in, search responses are tagged with the source as being either internal, using the Splunk platform, or external, using the third-party LLM. Administrators can view these audit log tags as needed.

Model Runtime feature availability and region standard

Region standards are defined as follows:

Data zone standard: App requests can route to any region within the same zone. Provides zone-level routing only.

Global standard App requests can route anywhere in the world. Does not provide zone-level or country-level routing guarantees.

Deprecated or removed features

The following sources have been deprecated for Threat Intelligence Management in Splunk Enterprise Security 8.6.x and higher:

URLHaus

Abuse SSL IP Blacklist

If you are using Splunk Enterprise Security for the first time, you must not subscribe to these deprecated sources. If you are an existing user, you must unsubscribe from these deprecated sources to avoid any disruptions.

The URLHaus source is deprecated due to changes in licensing terms. A new source named URLhaus Malware URL Feed is added, which requires an API key for access.

The following features have been deprecated from Splunk Enterprise Security 8.x:

Configuring the investigation type macro is no longer available.

Incident Review row expansion is no longer available.

Enhanced workflows are no longer available.

Sequence templates are no longer available.

The Investigation bar, Investigation Workbench, and Investigation dashboard from the Splunk Enterprise Security user interface (UI) are replaced by the Mission Control UI.

Service level agreements (SLAs) and role-based incident type filtering are not available.

The Content management page was updated to remove the following types of content: Workbench Profile, Workbench Panel, and Workbench Tab.

Workbench and workbench related views such as ess_investigation_list, ess_investigation_overview, and ess_investigation have been removed.

Capabilities such as edit_timeline and manage_all_investigations have been removed.

The Comments feature is replaced by an enhanced capability to add notes.

In Splunk Enterprise Security version 7.3, admins can turn on a setting to require analysts to leave a comment with a minimum character length after updating a notable event. In Splunk Enterprise Security version 8.x, you can no longer require a note when an analyst updates a finding in the analyst queue.

Add-ons

Technology-specific add-ons are supported differently than the add-ons that make up the Splunk Enterprise Security framework. Some new features might not work for on-prem Splunk Enterprise Security deployments 8.x and higher, unless you upgrade the Splunk_TA_ForIndexers add-on for every release. Do not uninstall the Mission Control app since the app is part of Splunk Enterprise Security.

To ensure that the Splunk Enterprise Security app works correctly, turn on the following add-ons. If any of the following add-ons aren't turned on, Splunk Support gets automatically notified and ensures that all the required add-ons are turned on automatically.

DA-ESS-AccessProtection

DA-ESS-EndpointProtection

DA-ESS-IdentityManagement

DA-ESS-NetworkProtection

DA-ESS-ThreatIntelligence

SA-AccessProtection

SA-AuditAndDataProtection

SA-EndpointProtection

SA-IdentityManagement

SA-NetworkProtection

SA-ThreatIntelligence

Splunk_SA_CIM

Splunk_SA_Scientific_Python_linux_x86_64

SplunkEnterpriseSecuritySuite

Splunk_ML_Toolkit

Deprecated or removed add-ons

Splunk Enterprise Security no longer includes many of the technology add-ons in the Splunk Enterprise Security package. Instead, you can download the technology add-ons that you need directly from Splunkbase. This change improves the performance of Splunk ES by reducing the number of unnecessary enabled add-ons, and allows you to install the most appropriate and updated versions of add-ons when you install Splunk ES.

The following technology add-ons are removed from the installer, but still supported:

Splunk Add-on for Blue Coat ProxySG

Splunk Add-on for McAfee

Splunk Add-on for Juniper

Splunk Add-on for Microsoft Windows

Splunk Add-on for Oracle Database

Splunk Add-on for OSSEC

Splunk Add-on for RSA SecurID

Splunk Add-on for Sophos

Splunk Add-on for FireSIGHT

Splunk Add-on for Symantec Endpoint Protection

Splunk Add-on for Unix and Linux

Splunk Add-on for Websense Content Gateway

The following technology add-ons are removed from the installer, supported for the next year, but are deprecated and will reach end of support one year from the release date of this Enterprise Security version:

TA-airdefense

TA-alcatel

TA-cef

TA-fortinet

TA-ftp

TA-nmap

TA-tippingpoint

TA-trendmicro

Updated add-ons

The Common Information Model Add-on is updated to version 8.8.0 and was released on October 21st, 2026. The version number for the Common Information Model is synchronized with the version number of Splunk Enterprise Security.

Libraries

The following libraries are included in this release:

Splunk_ML_Toolkit-5.3.0-1631633293630.tgz

Splunk_SA_Scientific_Python_linux_x86_64-3.0.2-0

Splunk_SA_Scientific_Python_windows_x86_64-3.0.0

Original source

SIEM and Log Management Release Notes

Products (9)

Latest SIEM and Log Management Updates

Monitor and troubleshoot employee devices with Datadog End User Device Monitoring

Start the day knowing which devices need attention

Find the cause before escalating to other teams

Catch recurring problems and risks at their source

Start each fix with the root cause already identified

Get started with End User Device Monitoring

Monitor OCI workloads in US government clouds with Datadog

Monitor OCI workloads across OC2 and OC3

Visualize your OCI environment with Cloudcraft

Start monitoring OCI government cloud workloads with Datadog

Monitor OpenAI Codex usage and impact with Datadog

Track Codex adoption across users, models, and clients

Measure Codex contributions to your codebase

Evaluate how developers engage with Codex code reviews

Connect Codex adoption to software delivery performance

Start monitoring OpenAI Codex with Datadog

Detect and respond to PHP2Shell with Datadog

Assess your exposure to PHP2Shell

Identify vulnerable PHP deployments and prioritize remediation

Find vulnerable hosts and container images with Cloud Security

Identify affected applications and owners with Code Security

Detect exploitation attempts and investigate suspicious activity

Investigate suspicious process activity with Workload Protection

Detect PHP2Shell activity with Cloud SIEM

Track remediation and verify that patches have been deployed

Protect your PHP applications against PHP2Shell

Troubleshoot Kubernetes inference workloads with Datadog

Bring inference resources into one workload view

Correlate telemetry across workload components

Investigate inference readiness and resource usage

Investigate GPU capacity constraints

Find capacity to reclaim

Investigate with Bits

Start investigating Kubernetes inference with Datadog

Investigate Kubernetes health and processes with the Datadog MCP Server

Check Kubernetes control plane health in a single call

Give agents process-level evidence with Live Processes search

Keep process search results within an agent’s context budget

Answer broader process questions with the processes skill

Get started with Kubernetes investigations through the Datadog MCP Server

Manage Kubernetes observability with DatadogInstrumentation

Configure observability for a specific Kubernetes workload

Define metrics, logs, and traces in one resource

Without DatadogInstrumentation: Settings split across the DatadogAgent resource and annotations

With DatadogInstrumentation: Checks, logs, and APM in one resource

Apply the resource and verify the configuration

Change observability configuration independently of application releases

Add an OpenMetrics check

Mask sensitive data in logs

Enable Continuous Profiler

Get started with DatadogInstrumentation

Migrate Splunk queries, alerts, and dashboards to Datadog

Translate and validate individual SPL queries

Import alerts and dashboards in bulk

Track your migration over time

Simplify searches with native Datadog features

Start migrating your Splunk assets to Datadog

Compare AI agent changes with Online Experiments in Agent Observability

Offline versus online experiments for AI agents

Compare agent variants using real production traffic with Datadog Online Experiments

How we used Online Experiments to evaluate a model change

Improve AI agents faster with Online Experiments in Agent Observability

Splunk Enterprise Security 8.8.0

Release notes for Splunk Enterprise Security

What's new in 8.8.0

Upgrade notice for 8.x

Share threat data in Splunk Enterprise Security

Compatibility and support

Model Runtime in Splunk Security Assistant

Model Runtime feature availability and region standard

Deprecated or removed features

Add-ons

Deprecated or removed add-ons

Updated add-ons

Libraries