Instana 代理程序的存档版本说明

• agent-jvm-handling 1.0.32: 改进了对被忽略的 Java 进程以及 JVM 连接的处理。
• agent-ibmi-handler 1.0.3: 添加了一个 API ，用于从连接中访问 AS400 对象。
• 代理 1.1.764: 增强了对自定义日志路径的日志文件发现功能。

• Agent UI 会发现并显示在 配置文件中指定的自定义 org.ops4j.pax.logging.cfg 路径中的日志，从而更好地查看存储在非标准位置的应用程序日志。
• IBM i 传感器可直接从 AS400Connection 实例访问 AS400 对象，从而实现与 IBM i 系统的更高效集成。

• 修复了针对被忽略的 Java 进程错误删除 hsperfdata 文件的问题；现在代理在停止监控时不会删除附件文件。
• 修复了将转换中的进程误识别为JVM的问题，该问题曾导致非 Java 进程收到SIGQUIT信号。 配置 INSTANA_JVM_HANDLING_REQUIRE_ATTACH_FILES=true 为仅连接具有有效连接文件的 JVM（默认禁用）。
• 已将 Netty 从 4.1.125.Final 更新至 4.1.129.Final ，以修复安全漏洞 CVE-2025-67735。

• agent-open-telemetry-grpc 1.1.15: 增加了对可配置的旧版 OTLP gRPC 端口的支持。
• javaagent-loader 1.3.72: 防止代理升级期间发生类加载错误。
• agent-jvm-handling 1.0.31: 改进了与 JVM 的兼容性。
• agent-process-handling 1.0.36: 增强了进程监控的稳定性并加强了密钥隐藏功能。

• 可通过 INSTANA_AGENT_OTEL_GRPC_LEGACY_PORT_ENABLED 环境变量或配置文件配置旧版 OTLP 的 gRPC 端口。55680 运营商根据部署需求控制端口的使用。
  • 默认值：对于早于 1.310.0 的代理版本，该值为true
  • 默认值：对于 1.310.0 及更高版本的代理，该值为false

• 此外，您还可以在 configuration.yaml 中的“旧版端口”选项中启用该 com.instana.plugin.opentelemetry -> grpc -> legacy_port_enabled端口。

如需更多信息，请参阅旧版 OTLP gRPC 端口。

• 修复了代理重启时进程启动时间发生变化导致误报服务警报的问题；现在，在代理更新和重启期间，启动时间将保持稳定。
• 通过在启动时固定加载器类，修复了运行时删除 JAR NoClassDefFoundError 文件 javaagent-loader 导致的故障。
• 修复了错误地排除使用自定义类加载器的 JVM 的问题（例如， WebLogic'sLaunchClassLoader）；现在，代理仅会排除不受支持的 SAS 自定义类加载器。
• 修复了在使用 CRI 客户端时，Containerd 容器环境变量中的机密信息暴露的问题；代理现在可在所有容器配置位置正确地屏蔽机密信息。

• InstanaPCP 1.3.79
• 代理 1.1.763
• agent-runtime 1.0.17
• agent-runtime-api 1.0.14

• agent 1.1.762: 改进了传感器配置的可见性和验证功能。
• agent-backend 1.0.10: 增强了数据一致性，并提高了后端错误的可视性。
• agent-jvm-handling 1.0.30: 提高了容器化环境中 JVM 附件的可靠性。
• agent-process-handling 1.0.35: 增强了 Windows 进程监控的稳定性。

• 该代理现在会在创建传感器配置时验证 OSGi 束的启动级别，并在传感器因模式不匹配而无法启动时发出可操作的警告。 这些警告有助于操作员快速识别并解决配置问题。
• 现在，后端连接错误会以限流警告的形式记录，具体针对 HTTP 的 402（需要付款）响应和 HTTP 的 404（未找到）响应，从而更好地帮助用户了解端点访问限制和配置问题。
• 现在，代理仪表盘会通过监控事件自动检测并报告使用自定义类加载器的 JVM，从而清晰地显示这些进程为何不支持动态附加。

• 此前，来自多个来源的传感器有效载荷（例如 IBM MQ 的旧版传感器和辅助传感器）在同时到达时可能会相互覆盖，从而导致数据不一致。 现在，该代理会对 JSON 的有效载荷进行深度合并，以保留两个来源的所有数据。
• 此前，当 /tmp 目录是从主机根文件系统挂载到 Podman 容器中时， JVM 的挂载可能会失败，从而导致 OpenJ9 挂载文件时出现权限错误。 现在，当首次尝试失败时，代理会自动重试附件上传，无需用户切换，从而确保在这些环境中监控能够成功进行。
• 此前，在 Windows 系统中，代理程序崩溃或被强制终止后，可能会残留孤立 InstanaPCP.exe 进程继续运行，从而导致代理程序重启时无法启动新实例。 现在，该代理会自动检测并终止残留进程，从而恢复 Windows 的监控功能。
• 此前，在切换至灵活的进程名称处理机制后，由于实例名称格式不一致， InstanaPCP 的指标收集失败。 现在，该代理对所有查询都采用了统一的命名格式，从而恢复了准确的指标收集。
• 此前， pollRate 配置仅在首次重置后（传感器启动10分钟后）发送，导致初始阶段的UI图表出现数据缺失。 现在， pollRate 该信号会在首次检测到时立即发送，并在随后的复位操作中继续发送，从而确保图形的连续可视化。
• 此前，当 Instana 代理服务停止时， Windows 上的 InstanaPCP 进程无法正常关闭，导致重启时出现多个并行实例。 现在， InstanaPCP 能正确监控代理端点，并在代理停止时终止运行，从而避免了进程重复。

agent-process-handling 1.0.34: 提高了基于 CRI- API 的进程监控的稳定性。

此前，基于 CRI- API 的进程处理（与 CRI-O 和 containerd 配合使用）在未完全处理完命令输出时，可能会导致程序挂起或使后台线程保持活动状态。 这种行为可能会影响长期稳定性。 现在，后台任务和 I/O 资源已得到妥善清理，这可确保在 CRI-O 和 containerd 环境中实现稳定可靠的进程监控。

agent-util 1.0.16

• agent-api 1.2.172: 新增了对在不使用套接字访问的情况下收集 Podman 容器详细信息以及对进程执行进行精细控制的支持。
• agent-socket-server 1.0.9: 在代理端点上添加了可配置的 HTTP 消息大小限制。
• agent-open-telemetry-grpc 1.1.14: 添加了可配置的 gRPC 消息大小限制。
• agent-open-telemetry-http 1.1.15: 添加了可配置的 HTTP 消息大小限制。
• agent-process-handling 1.0.33: 增强了 Podman 的监控功能，支持无套接字容器，并改进了环境变量的处理。
• instana-podman-sensor 1.0.9: 新增了对无需暴露套接字即可监控 Podman 容器的支持。

• OpenTelemetry 基础组件现在默认情况下始终会启动，即使未显式配置 ` OpenTelemetry `，从而为遥测数据收集做好更充分的准备。
• Podman 现在，即使没有 Podman 套接字可用，或者套接字被报告为缺失，也可以对容器进行监控，从而支持在更受限的环境中进行监控。
• 现在可以通过配置 INSTANA_AGENT_HTTP_MAX_MESSAGE_SIZE (最小值：5 MB，最大值： 49.5 MB) 来设置代理端点 (:42699) 的消息大小限制，从而更好地控制资源使用情况。
• gRPC 现在可以通过 INSTANA_AGENT_OTEL_GRPC_MAX_MESSAGE_SIZE 或配置键 来设置消息 grpc.max_message_size 大小限制（最小：5 MB，最大： 49.5 MB），从而为大型遥测有效载荷提供了灵活性。
• HTTP 现在可以通过 INSTANA_AGENT_OTEL_HTTP_MAX_MESSAGE_SIZE 或配置键 来设置消息 http.max_message_size 大小限制（最小：5 MB，最大： 49.5 MB），从而能够处理更大的基于 HTTP 的遥测数据。
• 现在可以对在其他进程上下文中（例如在容器内）运行的进程进行精细控制。 现在，您可以控制环境变量的继承方式以及用户上下文的适用方式。
• “代理支持任务”现已在可下载的结果中包含 Podman 套接字检测的详细信息，从而提升了故障排除能力。
• 代理现在会在应用潜在网关端点之前，先在 Podman 进程的网络命名空间内对其进行验证，从而确保网络配置更加可靠。

• 此前，对性能计数器和临时目录的评估被错误地与 InstanaPCP 状态绑定（该状态在 1.0.27 中引入），导致当 InstanaPCP 未启用时，这些检查会失败。 现在，无论 ` InstanaPCP ` 的状态如何，临时目录都会始终被评估，且会在 ` Windows ` 上查询性能计数器，从而确保系统监控的一致性。
• 此前，在无根 Podman 监控中，针对用户上下文容器的额外信息请求可能会因shell输出污染而失败。 现在，该代理使用不带登录 shell 的用户会话，以确保标准输出（stdout）干净，从而能够从无 root 权限的 Podman 容器中可靠地收集数据。
• 此前，在 java -version 执行检查以及连接 JVM 时，环境变量可能会干扰正常运行。 现在，这些操作是在经过清理的环境中进行的，从而确保 JVM 的检测和附加更加可靠。

• instana-agent-open-telemetry-base 2.2.5
• instana-agent-otel-sensor-sdk 1.1.18
• instana-agent-open-telemetry-service 1.1.13
• agent-util 1.0.15
• agent-jvm-handling 1.0.29
• 代理 1.1.761
• agent-backend 1.0.28
• agent-backend-api 1.0.13
• agent-backend-util 1.0.13
• agent-configuration-integration-vault 1.0.11
• agent-grpc 1.0.13
• agent-grpc-channel-cache 1.0.13
• agent-http 1.0.13
• agent-jaeger-tracer 1.0.13
• agent-memory 1.0.13
• agent-netty-allocator 1.0.13
• agent-netty-allocator-api 1.0.13
• agent-process-handling-api 1.0.13
• agent-self-profiling 1.0.13
• agent-sensor 1.0.13
• agent-socket-server-api 1.0.13
• agent-task-orchestrator 1.0.13
• agent-zipkin-tracer 1.0.13

• agent 1.1.760: 修复了传感器心跳转换的时机问题。
• agent-process-handling 1.0.32: 修复了容器检测和命名空间处理方面的问题。

• 此前，尽管这些传感器本应每秒提供一次数据， pollRate 但在将心跳信号转换为 NO_CHANGE 结果之前，仍存在10秒的延迟。 这种延迟导致在传感器出现延迟时，特殊的心跳检测替代方案无法正常工作。 现在， pollRate 1 传感器的转换阈值已降至 3 秒，这确保了更及时的数据处理，并能正确处理存在延迟的传感器。
• 此前，在混合容器运行时环境中，容器 ID 检测可能会产生误报，尤其是在 Containerd 检测逻辑错误地将 CRI-O 容器识别出来时。 现在，容器检测功能采用了显式验证检查和针对特定运行时的模式（包括改进的 Podman libpod作用域检测），从而确保在 Docker、Containerd、 Podman 和 CRI-O 等环境中都能准确识别容器。
• 此前，由于用户命名空间的差异，代理无法与 Podman 容器内的进程（尤其是无root权限的容器）进行正常交互。 此问题导致在连接这些容器内的 JVM 时出现权限错误并导致操作失败。 现在，该代理能够智能地检测命名空间关系，并采用适当的机制加入目标命名空间，从而确保在 Podman 环境中实现可靠的 JVM 连接和监控。

• agent-internal-api 1.0.18
• agent-jvm-handling 1.0.28
• agent-runtime 1.0.16
• agent-runtime-api 1.0.13

• agent-process-handling 1.0.31: 增强了 Podman POD 容器的检测功能。

此前，针对 Podman POD 容器的容器 ID 检测功能并不完善。 现在，检测功能已得到增强，能够准确识别POD容器，从而提升了容器的可视性和监控准确性。

sensor-api 1.2.170

• 代理 1.1.759: 该软件包已更新，以修复. 中队列参数的使用问题 SensorTicker.sendResultChunk。
• agent-jvm-handling 1.0.27: 该软件包已更新，可在外部连接时清理 Java 环境变量，以防止发生内存不足（OOM）错误。
• agent-process-handling 1.0.30: 此软件包新增了以下更改：
  • 修复容器 ID 检测功能，以排除容器环境中的 conmon 进程。
  • 将进程指标收集切换为一种更快且更节省资源的方法，该功能现已默认启用。
• agent-runtime 1.0.15: 该软件包已更新，通过在启动时仅检查一次文件夹 /proc 来优化性能。
• agent-task-orchestrator 1.0.7: 该软件包已更新，通过 Netty 优化 DefaultThreadWatcher 中的 HashedWheelTimer ，以减少内存分配和垃圾回收开销。
• agent-open-telemetry-http 1.1.14: 已更新该软件包，移除了针对被忽略的 PID 查询的不必要信息日志。

• 该 agent-process-handling 软件包现在支持在运行 InstanaPCP 的 Windows 系统上，采用一种更快且更节省资源的进程指标收集方法。

  客户无需配置环境变量，即可享受资源消耗降低和响应速度提升带来的好处。

• 此前，在 中队列参数 SensorTicker.sendResultChunk 的使用存在错误。 这可能会导致队列数据处理不准确。 此问题现已修复，确保队列管理正确且可靠。
• 此前，在外部连接时， Java 环境变量并未被清理，这可能导致内存泄漏和潜在的内存不足（OOM）错误。 通过正确清理这些变量，该问题现已修复，从而提高了在 JVM 挂载过程中的稳定性。
• 此前，容器 ID 检测功能错误地将容器环境中的 conmon 进程纳入其中。 这可能会导致容器归属信息出现误导。 此问题现已通过排除常见进程得到解决，从而确保了容器的准确检测。
• 此前，代理在启动过程中多次检查该 /proc 文件夹，造成了不必要的开销。 此问题现已修复，通过仅进行一次检查，从而缩短了启动时间并提高了效率。
• 此前， DefaultThreadWatcher 的内存分配量更大，垃圾回收开销也更高。 此问题现已通过使用 Netty HashedWheelTimer, 得到解决，该方案在高负载下既能减少内存占用，又能提升性能。
• 此前，在 OpenTelemetry HTTP 组件中，针对被忽略的 PID 查找会生成不必要的日志。 此问题现已通过移除这些日志得到解决，从而使日志更加简洁，减少了冗余信息。

• agent 1.1.758: 添加了一个用于处理配置文件更改的新选项。
• agent-process-handling 1.0.29: 此软件包新增了以下更改：
  • 通过优化存在 /proc 性检查，降低了进程抽象中的内存占用。
  • 通过使用 SIGAR，改进了在 AIX 上对进程启动时间的检测。
• agent-runtime 1.0.14: 增加了对 Linux 路径中 是否 /proc 存在的检测支持。
• agent-runtime-api 1.0.12: 用于说明是否可以通过其 API/proc 访问。

• 该 agent 软件包引入了一个新的配置选项，用于控制如何检测配置文件的更改。 您可以通过环境变量启用此功能 INSTANA_WATCH_CONFIG_CHANGES_WITH_HASH_POLLER （默认值： false；若将其设置为 true ，则使用基于哈希的轮询，而非 inotify）。
• 和 agent-runtimeagent-runtime-api 软件包可改进 Linux 的进程检测功能：
  • 运行时现在会检测 Linux 路径中是否 /proc 存在该文件。
  • API 现已通过该 isProcPresent 方法公开了此信息。

• 此前，该进程在检查存在 /proc 性时会消耗更多的内存。 通过优化这些检查，该问题现已得到解决。
• 此前， AIX 上对进程启动时间的检测不够准确。 该问题现已通过使用SIGAR进行检测得到解决。

• agent-init 1.0.8: 在 AIX 上默认启用了直接内存使用。
• 代理程序 1.1.757: 改进了 ps 探测机制，确保父进程信息始终可用。
• agent-jvm-handling 1.0.26: 更新了对在 Podman 容器内使用 switchUser. 访问 JVM 附件的支持。
• agent-netty-allocator 1.0.2: 改进了在禁用直接内存时的日志记录功能。
• agent-process-handling 1.0.28: 更新了对 Podman 中使用 的 switchUser 进程 nsenter的支持。
• netty 4.1.125: 已更新以修复 HTTP 编解码器中的一个安全问题。

该 agent-init 软件包默认情况下支持在 AIX 系统上直接使用内存。 可以通过环境变量将其关闭 INSTANA_AIX_NETTY_SET_UNSAFE （默认值： false；设置为 true 可禁用直接内存）。

• 此前，执行 的 AgentSupportTask 进程在 ps 某些情况下可能会省略父进程 ID（PPID）。 该问题现已通过在启动时检测可用 ps 选项并选择一个能可靠包含 PPID（以及在可能的情况下包含进程树）的选项来解决。
• 此前，该 agent-jvm-handling 软件包可能无法附加到在 Podman 容器内运行的JVM上。 此问题现已通过在相关操作中 switchUser 使用 得到解决。
• 此前，当禁用直接内存时，该 agent-netty-allocator 捆绑包无法被识别。 此问题现已通过添加一条信息级日志来指示当前状态而得到解决。
• 此前，该 agent-process-handling 软件包在依赖于 的 nsenterPodman 进程中无法正确 switchUser 应用。 此问题现已通过在 switchUser 中实现 --setuid 和 得到 --setgid 解决，因此用户所做的更改将在执行过程中正确应用。
• 该 netty 软件包中的 HTTP 编解码器（ CVE-2025-58056 ）存在一个漏洞。 此问题现已通过更新至修补版本得到解决。

• agent-backend 1.0.8: 此软件包新增了以下更改：
  • 新增了对配置后端读取超时设置的支持。
  • 通过将空闲状态检查推迟到 TLS 建立之后，改进了连接处理机制。

该包 agent-backend 现在支持通过环境变量配置后端读取 INSTANA_BACKEND_READ_TIMEOUT_SECONDS 超时（默认值为 10；此后的 10 值将被忽略）。

此前，在 TLS 握手过程中，连接可能会过早重新建立。 现在，通过仅在 SSL 连接完全建立后才初始化空闲状态处理程序，可以避免这种情况。

• sensor-api 1.2.169: 针对进程输出处理进行了以下改进：
  • 引入了一种构建器模式，用于创建 OsProcessOutput 具有可配置选项的对象。
  • 在.中添加了可配置的队列 StreamingOsProcessOutput容量和批处理大小。
  • 为 StreamingOsProcessOutput. 添加了一个可靠的 onClose 回调函数。
• agent 1.1.756: 改进了网络绑定操作的日志记录。
• agent-cri-client 1.0.6: 现在会同时捕获容器状态 imageId 中的 imageRef 和。
• agent-jvm-handling 1.0.25: 已应用以下内部重构：
  • 已更新为使用 MavenArtifact 代替 AbstractMavenArtifact。
  • 这取决于 AbstractMavenArtifactAPI 来自 sensor-api。
  • 删除了已废弃的 ByteBuddyToolsJar.java.
• agent-process-handling 1.0.27: 已添加以下增强功能：
  • 为网络接口绑定添加了信息级日志记录。
  • 改进了 CRI- containerd 格式的容器 ID 检测功能。
  • 为无根 Podman 容器提供更好的IP地址解析。
  • 借助. AgentSupportTask，改进了工艺监控决策的追踪。
  • 重构了 Windows 服务监听器，并改进了生命周期管理。
• agent-util 1.0.14: 已添加以下更改：
  • 已弃用 AbstractMavenArtifact ，建议改用 API 版本。
  • 添加了一个重载方法，用于在路径 getNestedValue 不存在时 null 返回。
  • 在.中引入了一个更灵活 ValueFinder的可选链生成器。
• agent-open-telemetry-service 1.1.12: 通过自动排序优化了属性的处理。
• agent-open-telemetry-grpc 1.1.13: 已更新，现支持通过配置或环境变量禁用 PID 查找功能。
• agent-open-telemetry-http 1.1.13: 已更新，现支持通过配置或环境变量禁用 PID 查找功能。

• 该 sensor-api 软件包对进程输出处理进行了多项改进：
  • 引入了一个支持可配置选项的 OsProcessOutput 构建器模式。
  • 在 StreamingOsProcessOutput. 中添加了可配置的队列容量和批处理大小。
  • 为 StreamingOsProcessOutput...提供一个可靠的 onClose 回调函数。
• 该 agent 软件包现在会记录更多关于网络绑定操作的详细信息，从而有助于更好地排查绑定问题。
• 该 agent-cri-client 软件包现在在检查容器状态时会 imageRef 同时收集 imageId 和 ，从而提供完整的镜像元数据。
• 该 agent-jvm-handling 软件包已进行重构，具体更改如下：
  • 已从 迁移 AbstractMavenArtifact 至新的 MavenArtifact API。
  • 现在使用 AbstractMavenArtifact 来自 sensor-api 而不是其自身的副本。
  • 删除了已过时的 ByteBuddyToolsJar.java 文件。
• 该 agent-process-handling 软件包提升了可观测性并增强了对容器的支持：
  • 在网络接口绑定过程中记录信息。
  • 增强了对 CRI- containerd 格式的容器 ID 检测功能。
  • 改善了在无根 Podman 环境中的IP解析功能。
  • Tracks 通过. AgentSupportTask 更透明地追踪处理监控决策。
  • 为 Windows 服务提供更可靠的生命周期管理。
• 该 agent-util 软件包提供了多项增强功能：
  • 该 getNestedValue 方法的新重载，若未找到路径则 null 返回。
  • 为实现更复杂的值解析 ValueFinder 逻辑，向 添加了一个条件可选链构建器。
  • 该类现已 AbstractMavenArtifact 弃用，建议改用 API 版本。
• 该包 agent-open-telemetry-service 现在会使用 自动对属性进行排序，从而 TreeMap提高了属性处理的性能和一致性。
• 现在，和 agent-open-telemetry-http 软件包支持配置 agent-open-telemetry-grpc PID 查找功能。 PID 查找功能默认处于启用状态，但可以通过环境变量 INSTANA_AGENT_OTEL_GRPC_PID_LOOKUP （默认值： true；设置为 false 以禁用）或 INSTANA_AGENT_OTEL_HTTP_PID_LOOKUP （默认值： true；设置为 false 以禁用）将其禁用。 此外，也可以通过以下 configuration.yaml 方式禁用 PID 查找：
  • com.instana.plugin.opentelemetry -> grpc -> pid_lookup .
  • com.instana.plugin.opentelemetry -> http -> pid_lookup .

agent-process-handling 1.0.26: 该软件包已更新，为在 ContainerD 容器中基于 CRI- API 的进程执行添加了缺失的套接字。

此前，在 ContainerD 容器中基于 CRI- API 的进程执行会因缺少必需的套接字而失败。 通过添加缺失的套接字，该问题现已修复。

• sensor-api 1.2.168: 该软件包已更新，现可处理心跳检测中传感器结果为空的情况。
• 代理 1.1.755: 此软件包中添加了以下更改：
  • 已移除内部逻辑， DefaultNetworkInterfaceSupport 改为使用 ， BindAddressProvider 而非在内部提供可绑定接口的列表。
  • 注解式日志记录已更新，现使用支持包管理的日志器，而非 agent-util.
• agent-api 1.0.6: 该软件包已更新，新增 BindAddressProvider 了一个接口，用于返回可绑定接口的列表。
• agent-cgroup 1.0.7: 该软件包已更新，现使用支持软件包的日志记录器，而非 agent-util.
• agent-cri-client 1.0.5: 该软件包已更新，现在会在启动时检查默认的 containerD/run/containerd/containerd.sock 套接字。
• agent-grpc-channel-cache 1.0.3: 该包已更新，现使用支持包功能的日志记录器，而非 agent-util.
• agent-internal-api 1.0.17: 该包已更新，新增 ProcessInterestHandler 了一个方法，用于为绑定到某个进程的特定接口注册监听。
• agent-jvm-handling 1.0.24: 此软件包新增了以下更改：
  • 将其识别 jstart.exe 为潜在的 JVM。
  • 注解式日志记录已更新，现使用支持包管理的日志器，而非 agent-util.
• agent-process-handling 1.0.25: 此软件包新增了以下更改：
  • 外部 PID 超时已延长至 2 秒。
  • 添加了一个用于外部 PID n 查询的标志，以减少解析 DNS 条目的工作量。
  • 当代理在 POD 中运行时，或通过环境变量启用时，将 criClient 使用 containerD。
  • Podman 主机接口检测功能已得到改进。
  • 新增了多个 BindAddressProvider 实现。
  • 注解式日志记录已更新，现使用支持包管理的日志器，而非 agent-util.
• agent-runtime 1.0.13: 该软件包已更新，现使用支持软件包的日志记录器，而非 agent-util.
• agent-support-karaf 1.0.1: 该软件包已更新，现使用支持软件包的日志记录器，而非 agent-util.
• agent-task-orchestrator 1.0.6: 该软件包已更新，现使用支持软件包的日志记录器，而非 agent-util.
• agent-util 1.0.13: 该软件包已更新，现使用支持软件包的日志记录器，而非 agent-util.
• agent-open-telemetry-base 2.2.5: 该软件包已更新，若属性列表中包含 entityId ，则将其 cluster.uid 用作。
• agent-open-telemetry-grpc 1.1.12: 此软件包新增了以下更改：
  • 允许通过环境变量禁用 PID 查找。
  • 注解式日志记录已更新，现使用支持包管理的日志器，而非 agent-util.
• agent-open-telemetry-http 1.1.12: 此软件包新增了以下更改：
  • 允许通过环境变量禁用 PID 查找。
  • 注解式日志记录已更新，现使用支持包管理的日志器，而非 agent-util.

• 该 sensor-api 软件包现已支持将“sense”结果中的空值作为心跳信号进行处理。
• 该包 agent-api 引入了一个 BindAddressProvider 接口，用于返回一个可绑定接口的列表。
• 现在， agent-cri-client 该程序会在启动时检查默认的 containerD/run/containerd/containerd.sock 套接字。
• 该 agent-internal-api 扩展在 ProcessInterestHandler 原有功能的基础上，增加了对绑定到进程的接口的注册支持。
• 该 agent-process-handling 软件包将外部 PID 的超时时间延长至 2 秒，并添加了该 n 标志以缓解 DNS 解析问题。
• 该 agent-process-handling 软件包现已通过 CRI 客户端支持 containerD。 您可以通过环境变量启用或禁用 INSTANA_USE_CONTAINERD_CRI_CLIENT 此行为（默认： true 在 POD 中运行时）。
• 该 agent-process-handling 软件包引入了多个新的 BindAddressProvider 实现：
  • AgentPublicIpBindAddressProvider : 将代理的公共 IP 地址作为可绑定接口暴露出来。
  • ContainerBridgeBindAddressProvider : 将容器桥接网络作为可绑定接口暴露出来。
  • ProcessInterestBindAddressProvider : 将进程特有的网络需求作为可绑定接口进行暴露。
• 该 agent-open-telemetry-grpc 软件包现在支持通过环境变量禁用 PID INSTANA_AGENT_OTEL_GRPC_PID_LOOKUP 查找（默认值为 true，设置为 false 即可禁用）。
• 该 agent-open-telemetry-http 软件包现在支持通过环境变量禁用 PID INSTANA_AGENT_OTEL_HTTP_PID_LOOKUP 查找（默认值为 true，设置为 false 即可禁用）。

• 此前，基于注解的日志记录使用的是通用的 agent-util logger。 此问题现已通过更新所有受影响的包（agent, agent-cgroup, agent-grpc-channel-cache, agent-jvm-handling agent-process-handling,, agent-runtime, agent-support-karaf agent-task-orchestrator, agent-util, agent-open-telemetry-grpc,, agent-open-telemetry-http）并改用支持包的日志记录器来解决。
• 此前，由于超时时间过短或 DNS 解析问题，外部PID查询会失败。 该问题现已通过延长超时时间并添加 标志来缓解 DNSn 的解析问题而得到解决。
• 此前，Podman 容器无法解析主机接口。 此问题现已通过将 host.containers.internal 用作可靠的主机接口目标得到解决。

• sensor-api 1.2.167: 该软件包已更新，允许全局访问 cgroup 数据中的 RSS 计数。
• agent 1.1.754: 该软件包已更新，以改进对 Metadata API 响应的处理。
• agent-cgroup 1.0.6: 该软件包已更新，可正确处理 cgroups 的内存缓存和 RSS 计算。
• agent-jvm-handling 1.0.23: 该软件包已更新，以支持 Java 25 的追踪功能。
• agent-process-handling 1.0.23: 此软件包新增了以下更改：
  • 该软件包已更新，现支持自定义 RKE2 路径。
  • 新增了一项用于遍历父进程查找的服务。
• agent-process-handling 1.0.24: 该软件包已更新，为父进程查找功能添加了循环检测。
• agent-socket-server 1.0.8: 此软件包新增了以下更改：
  • 已添加对父频道的回调。
  • 改进了线程命名，以便更好地进行故障诊断。
• agent-socket-server-api 1.0.5: 该软件包已更新，为父频道添加了回调功能。
• agent-open-telemetry-service 1.1.11: 该软件包已更新，将 Object 转为字符串的内存分配仅保留在调试日志记录场景中。
• agent-open-telemetry-http 1.1.11: 此软件包新增了以下更改：
  • 连接跟踪逻辑已添加到父处理程序中。
  • 在通道初始化之前，已将 PID 查找功能添加到父处理程序中。
  • 最大通道数可以进行限制。

• cgroup 解析器现在通过 total_rsscgroupv1 和 提供 RSS anoncgroupv2 数据。
• 该 agent-jvm-handling 软件包现已支持 Java 25的跟踪功能，并更新了 javaagent-loader ( 1.3.71 )、 instrumentation-boot ( 1.1.32 ) 和 instrumentation-shared ( 1.0.1467 )。
• 新增了一项用于遍历父进程的服务。 该服务用于各种容器实现，以识别类型或 containerId。
• OpenTelemetry HTTP 组件现在支持通过环境变量配置最大并发 INSTANA_AGENT_OTEL_HTTP_MAX_CHANNELS 活动通道数（默认值为 1000）。

• 此前，元数据 API 的解析器并未对错误字符串进行检查。 此问题现已通过检查错误响应并限制代理 UniqueId 的允许字符串来解决。
• 此前，当进程未以 0 结束时，查找父进程可能会导致错误 OutOfMemory 。 该问题现已修复，具体做法是追踪已访问的进程 ID，并在检测到循环时停止。
• 此前，当代理接收的请求过多时， OpenTelemetry HTTP 组件会引发错误 OutOfMemory 。 该问题现已通过限制同时活动的频道数量得到解决。 此外，耗时的 PID 查询操作被移至父级处理程序中。

agent-process-handling 1.0.21: 在 sshdv1.2.32 版本发布后，进程监控问题已修复。

此前，只有当进程 sshd 名称以 结尾 sshd时，才会将其添加到内部列表中，但这在较新的 RHEL 环境中是不正确的。 该问题现已修复，具体方法是检查该 sshd 内容在可执行文件中出现的次数，并在计数超过1次时予以允许。

• 已将代理 1.1.753:pax_url_mvn_leak 的监控问题添加到此包中。
• agent-netty-allocator 1.0.1: 此软件包新增了以下更改：
  • 已添加支持按通道后退保护的分配器，该分配器具有共享计数器和后退配置。
  • 添加 DefaultFlowControlManager 了一个 A 来跟踪每个通道的“许可”，并在缓冲区处理中数量超过最大 autoRead 并发数时暂停。
• agent-netty-allocator-api 1.0.1: 该服务已扩展为支持按通道分配的分配器。
• agent-process-handling 1.0.21:sshd 进程监控已放宽。
• agent-runtime 1.0.12: 该软件包已扩展，用于读取 double 配置值。
• agent-runtime-api 1.0.11: 该软件包已扩展，用于读取 double 配置值。
• agent-socket-server 1.0.7: 该软件包已进行扩展，以使用新的流控制管理器来限制并发读取。

• 新增了一项服务，用于控制并发读取的最大数量。 您可以通过 环境变量 INSTANA_INGRESS_CONCURRENCY 来控制并发数（默认值为 4）。
• 您可以通过以下环境变量对 Netty 的输入进行微调：
  • INSTANA_NETTY_INBOUND_FACTOR （默认值为 0.6 ）：一个介于0和1之间的数值，用于控制可用于入站连接的直接内存所占的比例。
  • INSTANA_NETTY_OUTBOUND_FACTOR （默认值为 0.9 ）：一个介于0和1之间的数值，用于控制可用于出站传输的直接内存所占的比例；出站因子始终大于入站因子。
  • INSTANA_NETTY_INBOUND_SOFT_FACTOR （默认值为 0.8 ）：一个介于0和1之间的数值，用于控制用于软退避的直接内存所占的比例。
  • INSTANA_NETTY_SOFT_TIMEOUT_SECONDS （默认值为 2）：一个介于 0 和无限制之间的数值，用于控制软退避所用的秒数，超过该时间后，内存将始终被分配。
  • INSTANA_NETTY_DIRECT_MEMORY_TIMEOUT_SECONDS （默认值为 30）：一个介于 0 和无限制之间的数值，用于控制硬退避的持续时间（以秒为单位），超过该时间后将抛出异常并丢弃当前消息。
• 读取配置值的服务可以读取类型为. double的值。

• 此前，该 pax-url 组件中的一个泄漏导致了 OutOfMemory 错误。 现在，如果检测到此问题， Instana 将显示一个名为 pax_url_mvn_leak 的监控问题。 您可以通过重新安装代理来解决此问题。
• 此前，入站流量可能会导致发往后端的出站流量不足。 该问题现已通过将并发读取流的数量限制为 4 个得到解决。 此外，当输出端无法及时卸载数据时，输入端还会通过降低传入数据的速率来应对背压。
• 此前，该 sshd 进程仅在位于默认位置时才被允许 /usr/sbin/sshd运行。 此问题现已通过放宽查找条件（即检查进程名称是否以 sshd. 结尾）得到解决。

• agent-process-handling 1.0.20: 为容器内进程 ID 查询添加了一个结束原因。 此外，当 /status 文件内容为空时，会添加一次重试。
• agent-runtime 1.0.11: 该服务现已扩展，为指数退避处理程序提供了结束原因。
• agent-runtime-api 1.0.10: 该服务现已扩展，为指数退避处理程序提供了结束原因。

处理指数退避的服务现在会在标记为完成时记录结束原因。

此前，在读取该 /status 文件时发生了竞争条件，导致无法读取容器内的 PID。 此问题现已修复，当文件内容为空时，代理会重新尝试读取该 /status 文件。 成功和错误情况已添加到 “收集支持信息 ”中。

• agent-jvm-handling 1.0.22: 在 Windows 上的所有已知临时目录中添加了一个监视器。
• agent-process-handling 1.0.19: 已为容器内的 PID 添加了退避策略，相关信息会在代理仪表板上的 “收集支持信息 ”中显示。
• agent-runtime 1.0.10: 实现了一项服务，用于提供指数退避处理程序。
• agent-runtime-api 1.0.9: 实现了一项服务，用于提供指数退避处理程序。

新增了一项支持指数退避的服务。

• 此前，当 Java 进程未正常关闭时，与 Java 传感器相关的文件会堆积在用户的临时目录中。 该问题现已修复，具体做法是检查 Windows 目录下所有已知的临时目录中是否存在 Java 传感器文件，并在 Java 进程停止时将其删除。
• 此前，在将 PID 与追踪器发送的公告消息中报告的 PID 进行比较时，会发生错误 NullPointerException 。 此问题现已得到修正。 该代理在进行比较之前，总会先检查是否存在空值。 此外，还添加了一种回退策略，用于通过 /status 或 /sched 文件查找容器中的 PID。 “收集支持信息 ”中已添加了尝试次数以及容器内 PID 查找的当前状态。

• sensor-api 1.2.166: 本次发布包含以下更改：
  • 新增了一项服务，用于查询代理的默认临时目录。
  • 新增了一项服务，用于压缩将要转发至后端的数据。
  • 进程信息已扩展，包含报告的 PID 和进程类型。
  • 直接使用 Sigar 已被弃用，仅允许通过辅助函数进行使用。
• 代理 1.1.752: 当 inotify 处理程序用尽时，配置更改中会添加一个备用方案，并进行手动检查。
• agent-cgroup 1.0.5: 通过检查进程的已知类型来提升查找速度。
• agent-jvm-handling 1.0.21: 本次发布包含以下更改：
  • 通过检查进程的已知类型，可以提高查找速度。
  • javaagent‑loader 已更新至 1.3.70 版本。 当 的权限更新 /tmp/.instana 失败时，日志级别 INFO 现已降至。 此外，当 /tmp/.com_ibm_tools_attach 访问路径为 而非 /proc/<pid>/tmp/.com_ibm_tools_attach时， J9-based 附件的文件夹查找功能已得到增强。
• agent-process-handling 1.0.18: 本次发布包含以下更改：
  • 通过检查进程的已知类型，可以提高查找速度。
  • 从进程的角度来看，报告的 PID 现已对容器和主机进程可见。
  • PID 现已作为追踪器发送的公告消息的一部分进行验证。
  • 现在可以将文件复制到无根 Podman 容器内的文件夹中。
  • 直接访问Sigar的功能现已取消。 在关机之前，会增加一个等待时间，以便 Sigar 阻止访问。
• agent-process-handling-api 1.0.5: 由于已迁移至传感器 API ，因此“进程类型”的内部服务已被废弃。
• agent-runtime 1.0.9: 已实现一个用于文件和文件访问的服务，以便更轻松地进行测试。
• agent-runtime-api 1.0.8: 实现了一个用于文件和文件访问的服务，以便更轻松地进行测试。

进程现在报告其从自身视角看到的 PID。 由于 PID 命名空间不同，在主机上运行的进程与在容器中运行的进程所显示的信息可能有所不同。

• 此前，如果 inotify 进程句柄用尽，则不会监视配置文件。 现在，该问题已通过定期读取配置文件的元数据，并在元数据发生变化时更新配置来解决。
• 此前，在发布追踪器时会检查多个进程。 该问题现已通过将进程列表限定为仅包含报告的 PID 相同的进程来解决。
• 此前，记录 javaagent-loader 的更改始终 /tmp/.instana 处于 WARN 级别。 此问题现已修复，现在仅当文件夹权限与预期级别不符时，才会记录 WARN 级别的日志。
• 此前，当 /proc/<pid>/tmp/.com_ibm_tools_attach 不可达时，无法 javaagent-loader 将其附加到 J9 的 JVM 上。 此问题现已通过检查文件夹是否 /tmp/.com_ibm_tools_attach 可达来解决。
• 此前，当您将文件复制到无根 Podman 容器内的某个文件夹时，系统会生成一个名称随机的文件。 现在，通过先将文件复制到主机 /tmp 上的一个中间文件夹中并保留原文件名，该问题已得到解决。

• 代理 1.1.751: 实现了用于查看配置文件更改的服务。
• agent-internal-api 1.0.16: 添加了用于查看配置文件更改的服务。
• agent-process-handling 1.0.16: 本次发布包含以下更改：
  • 默认情况下缓存容器元数据
  • InstanaPCP 已更新至 1.3.74: 移除了 环境变量的 INSTANA_LOG_LEVEL 设置
  • 新增了忽略非容器 cgroups 的功能
  • 使用已知的套接字进行 ContainerD 信息查询
  • 将选择性监控扩展至使用 Kubernetes 命名空间

• 当 NAMESPACES_DETAILS_PATH 存在时，选择性监视现已支持 Kubernetes 命名空间。 操作员会设置此环境变量，其中包含一个 YAML 文件的位置。
  • 设置该环境变量后，代理会使用标签 instana-workload-monitoring 为每个命名空间缓存内容。
  • 将计算以下值： <absent>, true, false, apm, 以及 infra。
  • 如果 INSTANA_SELECTIVE_MONITORING 设置为 DEFAULT 或为空，则代理将以正常模式运行。 所有带有 的命名 instana-workload-monitoring=false 空间将被忽略。
  • 如果 INSTANA_SELECTIVE_MONITORING 将 设置为 OPT_IN，则代理将处于选择性监视模式。 该代理仅监控位于某个命名空间中，且名称包含 instana-workload-monitoring=true、 instana-workload-monitoring=apm 或 的进程 instana-workload-monitoring=infra。 所有带有 的 instana-workload-monitoring=false 进程将被忽略。
• 新增了一个内部服务，用于监控配置文件的变更，并在发生变更时发出通知。 该服务利用调度程序来减少总线程数。

• 此前，仅缓存成功的容器元数据。 此问题现已修复，且容器元数据查询失败的情况已被缓存。
• 此前，诸如 /init.scope 和 /mde等 cgroups 被认定为潜在的容器。 在添加了已知非容器 cgroup 名称的列表后，此问题现已修复。
• 此前，当主机上存在多个套接字时， ContainerD 的查找会失败。 此问题现已通过使用分配给 ContainerD 进程的套接字得到解决。

• 代理程序 1.1.750: 在文件 configuration.yaml 中检测到 non-UTF-8 字符。
• agent-cgroup 1.0.4: 在查询 cgroup 数据时检查是否存在正在运行的进程。
• agent-jvm-handling 1.0.20: 忽略 db2fmp 进程。
• agent-process-handling 1.0.15: 准备 Kubernetes 标签缓存。
• agent-util 1.0.12: 添加了一个用于检测非 UTF-8 字符的辅助函数。
• agent-open-telemetry-grpc 1.1.11: ExecutionPipeline 用于 OTel gRPC 的跟踪信息。
• agent-open-telemetry-http 1.1.10: 优化 HTTP 管道。

• 缓存以下容器类型的 Kubernetes 标签，以支持选择性监控： ContainerD, CRI-O、 Docker 以及 Podman
• 使用以下方法统计 OTel gRPC 中的任务 ExecutionPipeline

• 此前，如果文件中包含 non-UTF-8 字符，系统在读取该 configuration.yaml 文件时可能会失败。 此问题现已通过检查 non-UTF-8 字符得到解决。
• 此前，系统在读取容器指标的 cgroup 数据时，可能会显示错误的数据。 该问题现已通过检查该 cgroup 是否仍有任何进程处于活动状态来解决。
• 此前， OTel HTTP 的连接会被永久缓存。 此问题现已通过从内部缓存中移除已关闭的连接得到解决。
• 此前， OTel HTTP 连接可能会导致线程池过载。 此问题现已通过仅评估已建立的连接得到解决。

• agent 1.1.749: OpenTelemetry HTTP 以及 gRPC 组件是通过环境配置启用的。
• agent-backend 1.0.7: 已添加后端通信的可配置压缩级别。
• agent-jvm-handling 1.0.19: 调整了日志级别同步的时机。
• agent-runtime 1.0.8: 现已公开 Integer 和 Boolean 的环境查找方法。
• agent-runtime-api 1.0.7: 已添加用于环境查询的 API 方法。
• 采用 ExecutionPipeline agent-socket-server 1.0.6: 用于连接，以及 HTTP。
• 引入了 ThreadWatcher agent-task-orchestrator 1.0.5: 用于监控卡住的线程。
• 已添加 agent-task-orchestrator-api 1.0.2: ThreadWatcher 以及 ExecutionPipeline 任务封装器。
• agent-util 1.0.11: 已添加嵌套配置查找、异常感知 callable 以及 runnable 类型功能。
• agent-open-telemetry-base 2.2.4: 已添加对 span-links 的支持。
• agent-open-telemetry-service 1.1.8: 已添加对 span-links 的支持。
• 已添加 agent-open-telemetry-grpc 1.1.10:ExecutionPipeline ，用于 OTel gRPC 以及可配置端口。
• 已添加 agent-open-telemetry-http 1.1.9:ExecutionPipeline ，用于 OTel HTTP 以及可配置端口。

• 现在，您可以通过设置 INSTANA_AGENT_OTEL_HTTP 和 INSTANA_AGENT_OTEL_GRPC 环境变量（默认值为 null）来启用 OpenTelemetry、 HTTP 和 gRPC 组件。
• 现在，您可以通过 INSTANA_BACKEND_DEFLATE_LEVEL 变量来配置默认的压缩级别（0–9）（默认值为 null）。
• 整数和布尔型设置（支持空值回退）现可通过新的 runtime 和 runtime-api 方法从代理环境获取。
• 该代理现在在套接字服务器中同时 ExecutionPipeline 使用 JVM 连接和 HTTP 端点的处理。
• 这个新内置的辅助程序 ThreadWatcher 用于监控卡住的线程。 （默认值为 60 秒。 您可以通过环境变量 INSTANA_THREAD_WATCHER_TIMEOUT_SECONDS 来配置此项。
• 现在，任务已通过 orchestrator- API 接口，集成了预/后钩子、线程监视、池统计信息以及任务监控功能。
• 该代理现在会查询嵌套的配置值，并通过 callables runnables 和 中的新辅助方法抛出受控 util 异常。
• 已为 OpenTelemetry 基础包和服务包均添加了对Span-links的支持。
• OTel gRPC 此外， HTTP 组件现已支持通过 ExecutionPipeline.实现死锁线程检测和任务计数。 您可以通过使用 INSTANA_AGENT_OTEL_GRPC_PORT 和 INSTANA_AGENT_OTEL_HTTP_PORT 环境变量（默认值为 null）或修改 文件 configuration.yaml 来覆盖其默认端口。 如需了解更多信息，请参阅 OpenTelemetry 配置

此前，与 JVM 的日志级别同步会立即开始，这导致了内部测试验证中的竞争条件。 此问题现已通过将日志级别同步的开始时间延迟一分钟来解决。

• agent-netty-allocator-api 1.0.0: 此软件包添加了一项服务，用于提供一个全局的 ByteBuffer 分配器，该分配器支持基于超时的查找。
• agent-netty-allocator 1.0.0: 此软件包实现了一项服务，用于提供一个基于超时查找的全局 ByteBuffer 分配器。
• agent-backend 1.0.6: 该软件包现在使用基于全局超时的分配器，以确保数据能上报至后端。
• agent-jvm-handling 1.0.18: 此软件包新增了以下更改：
  • javaagent‑loader 已更新至 1.3.69 版本。 内存中的 ClassLoader 在重启时会正确释放其内部状态。 预 javaagent-loader 加载 ManagementFactory 以避免启动延迟。
• agent-socket-server 1.0.5: 此软件包新增了以下更改：
  • 该软件包已更新，现使用全局分配器来处理 ByteBuffers。
  • 该软件包现在限制了单个 ChannelInitializer 的内部使用。

• 此前，当您重新加载内存中的 ClassLoader, 时，存储的类会被移除，这导致在重新加载传感器后出现定义缺失的情况。 此问题现已通过将类持有数据结构保存在全局内存表示中得到解决。
• 此前，当启动 Spring -Boot Java 代理时，如果 ManagementFactory 未初始化， javaagent-loader 线程会被阻塞。 此问题现已通过在启动任何传感器代理之前 javaagent-loader预加载 ManagementFactory 默认值得到解决。
• 此前，当后端连接被重置时，直接内存守护进程会处于一种不一致且不支持多线程的状态，这会导致转发指标或跟踪信息的线程挂起。 该问题现已通过引入具有内置超时功能的全局共享 ByteBuffer 分配器得到解决。

• agent-jvm-handling 1.0.17: 此软件包新增了以下更改：
  • javaagent‑loader 已更新至 1.3.68 版本。 当堆内存上限小于您配置的阈值时，内存中的 ClassLoader 功能现已禁用，并回退到基于文件的附件。
  • 该代理现在会在 Windows 系统上阻止 kill -3 该调用。

现在，您可以通过 环境变量 INSTANA_AGENT_LOADER_MIN_IN_MEMORY_HEAP_MEGABYTES （默认值为 100 MB）为内存中类加载器配置最小堆阈值，该功能由升级后的 javaagent‑loader1.3.68 启用。 请确保在目标 JVM 中设置了该环境变量。

• 此前，当您在堆内存有限的 JVM 上使用内存中的 ClassLoader 时，会出现 OutOfMemory 错误。 该问题现已通过以下方式解决：当最大堆内存低于配置阈值（默认值为 100 MB）时，禁用内存中的 ClassLoader ，并回退到基于文件的附件。
• 此前，代理程序执行了一条针对 Unix 的 kill -3命令，但在 Windows 系统上执行失败。 该问题现已通过在 Windows 系统上禁用该 kill -3 调用得到解决。

• 代理 1.1.748: 此软件包中添加了以下更改：
  • 在收集支持信息时，任务 ps 中的敏感数据现已隐藏。
  • “Support Information”压缩包开头的斜杠现已删除。
• agent-jvm-handling 1.0.16: 此软件包新增了以下更改：
  • 已添加对 Java 24的支持，用于跟踪。
  • 现在，对使用自定义 Java 可执行文件或附加目录的 J9 JVM的检测功能已得到改进。
  • 该软件包已更新，以在 Unix 系统上禁用基于Byte Buddy的附件功能，前提是 /tmp 该分区已通过挂载命令 noexec挂载。
• agent-process-handling 1.0.14: 该软件包现在会检查容器中的元数据是否为空，并返回一个空映射，而不是解析无效数据。
• agent-runtime-api 1.0.6: 此软件包新增了以下更改：
  • 该软件包已更新，新增了一项服务，可在运行时加载任何类。
  • 该软件包已更新，以在基于 Unix 的系统上提供一项用于检查挂载选项的服务。
• agent-runtime 1.0.7: 此软件包新增了以下更改：
  • 该软件包已更新，以实现“加载任意类”服务。
  • 该软件包已更新，以实现针对 Unix 的挂载选项检查服务。
• agent-socket-server-api 1.0.4: 该软件包已更新，新增了一项服务，用于启动和停止基于 Netty 的套接字服务器。
• agent-socket-server 1.0.4: 该软件包已更新，以实现 Netty 中的 socket-server 启动和停止服务。
• agent-task-orchestrator 1.0.4: 调度器现已作为原型对外提供，这样每个消费者都能获得自己的实例，而线程则保持全局共享。
• sensor-api 1.2.163: 此软件包新增了以下更改：
  • 添加了一个流式进程输出辅助程序。
  • 为 IBM i 添加了 JVM 的作业名称查找支持。
• agent-open-telemetry-grpc 1.1.7: 现在使用 socket-server API 服务来启动和停止 OTel gRPC 套接字服务器。
• agent-open-telemetry-http 1.1.6: 现在使用 socket-server API 服务来启动和停止 OTel HTTP 套接字服务器。
• agent-ibmi-handler 1.0.2: 该软件包已更新，现在可在 IBM i 上获取完整的作业名称，而此前仅显示 PID。

• 该 agent-jvm-handling 软件包现已支持 Java 24的跟踪功能，并更新了 javaagent-loader ( 1.3.67 )、 instrumentation-boot ( 1.1.31 ) 和 instrumentation-shared ( 1.0.146 )。
• 新增了一个运行时服务，用于检查基于 Unix 的系统上的挂载选项。
• 现已提供一个专用的套接字服务器服务 API ，用于启动和停止基于 Netty 的套接字服务器。
• 任务协调器的调度器现已作为原型提供，它为每个消费者分配独立的实例，同时使用共享的全局线程池。
• 传感器 API 现已在 IBM i 上新增了“流式处理输出”辅助工具和 JVM 任务名称查询功能。

• 此前，敏感字段可能会在 process-listing (ps) 任务的输出中暴露，并被包含在支持包中。 此问题现已修复，在收集支持信息时会隐藏所有敏感数据。
• 此前，支持信息 ZIP 压缩包的文件名开头带有斜杠，这导致无法在 Windows 上解压文件。 此问题现已通过删除开头的斜杠得到解决。
• 此前，在追踪父进程链时，确定应忽略哪些 JVM 可能会导致陷入无限循环。 此问题现已通过打破循环查找循环得到解决。
• 此前，运行在 J9 JVM上且使用了自定义可执行文件或附加目录的应用程序无法被正确检测到。 通过增强 J9 的检测逻辑以识别自定义路径，该问题现已修复。
• 此前，在挂载了 /tmp 的 Unixnoexec 主机上，Byte Buddy 插件会失败，导致跟踪配置无法正常工作。 该问题现已通过检测 noexec 并 /tmp 回退到基于 JDK 的附加处理机制得到解决。
• 此前，如果容器元数据为空，代理会尝试解析无效数据并返回错误。 此问题现已修复：系统会检查元数据是否为空，并返回一个空映射，而非解析无效数据。
• 此前，调度程序的所有消费者都共享同一个实例，这导致当其中一个消费者停止运行时，新任务会被阻塞。 此问题现已通过将调度器（Scheduler）作为原型暴露出来得以解决，这样每个消费者都能获得自己的实例。
• 此前，关闭 Otel gRPC 套接字服务器可能会触发竞争条件，导致终止操作无限期阻塞。 该问题现已通过使用新的 socket-server API 服务来协调关机过程得以解决，这确保了系统能够稳定且无死锁地终止运行。
• 此前，关闭 Otel HTTP 套接字服务器可能会触发竞争条件，导致终止操作无限期阻塞。 该问题现已通过使用新的 socket-server API 服务来协调关机过程得以解决，这确保了系统能够稳定且无死锁地终止运行。
• 在之前的 IBM i 中，仅显示数字进程ID，而非完整的作业名称。 此问题现已修复，系统会获取并显示完整的作业名称。

• agent-cri-client 1.0.4: 此软件包已更新，用于捕获并记录在激活. 过程中发生的 CriClient异常。
• agent-grpc-channel-cache 1.0.2: 此软件包已更新，用于捕获并记录在创建通道缓存过程中发生的异常。

此前，在激活 CriClient 和通道缓存期间发生的异常未被捕获，这导致启动过程中出现未处理的错误。 该问题现已通过在这些组件激活过程中捕获并记录异常得到解决。

• agent-support-karaf 1.0.0: 此软件包包含所有与 Karaf 相关的支持数据集。 此外，此套装还增加了以下功能：
  • 新增了一项支持任务，用于收集包树依赖项。
  • 新增了一项支持任务，用于收集包头信息。
• agent-cgroup 1.0.3: 此软件包新增了以下更改：
  • 该程序包现在会等待进程收集完成，然后再执行更新，以防止 CRI-O 传感器停止运行。
  • 现在，查询容器和进程时不再依赖选择性监控。
  • 现在，通过在 cgroup 数据初始化过程中将负值设置为 0，启动时的内存和 CPU 数据突增现象已得到缓解。
  • 只有当主机运行在 Linux 上且该 /proc 文件夹存在时，才会启动 cgroup 检测。
  • 现在，内存 CGroupV2 使用量按 file + 计算 anon。
• agent-cri-client 1.0.3: 此软件包新增了以下更改：
  • 现在会在客户端初始化时进行版本检查，以便预加载必要的类。
  • 该软件包现已包含 io.perfmark ，以避免额外导入外部文件。
• agent-internal-api 1.0.15: 每个进程都会添加一个 APITempDir 参数，用于查询 Windows 上的附件。
• agent-jvm-handling 1.0.14: 此软件包新增了以下更改：
  • 当用户不是管理员或服务账户时， Windows 中的附件功能现在使用每个进程的目录 TEMP ，而不是全局目录。
  • 现在，您可以通过环境变量来控制 INSTANA_SOCKET_CONNECTION_TIMEOUTJVM 连接的超时设置。 默认值为 45，单位为秒。
• agent-open-telemetry-grpc 1.1.6: 为端口绑定失败添加了重试机制。
• agent-open-telemetry-http 1.1.5: 为端口绑定失败添加了重试机制。
• agent-process-handling 1.0.13: 此软件包新增了以下更改：
  • InstanaPCP 已更新至 1.3.73:。现在无需将进程名称更改为 processName_pid 格式，即可收集进程指标。
  • 在查询容器特定值时，环境变量映射的空情况现已得到正确处理。
  • 新增了在进行更新前等待第一个进程集合完成的功能。
  • 新增了无需选择性监控即可查询进程的功能。
• agent-process-handling-api 1.0.4: 此软件包新增了以下更改：
  • 已添加用于等待首次进程收集的接口。
  • 已添加用于查询未被选择性监控的进程的接口。
• agent-runtime 1.0.6: ReentrantLock 现已取代同步机制，用于 map、list 和 string 的内部化处理。
• agent-socket-server 1.0.3: 针对端口绑定失败的情况，已添加重试机制。

• 新增了一个专门用于收集Karaf相关支持数据的包。 该新 agent-support-karaf 包还新增了用于收集包树依赖关系和头文件信息的辅助任务。
• 该 agent-jvm-handling 软件包现在支持通过环境变量 INSTANA_SOCKET_CONNECTION_TIMEOUT 配置 JVM 连接的超时时间（默认值为45秒）。

• 此前，由于进程收集延迟， CRI-O 传感器在更新过程中停止工作。 此问题现已修复，具体做法是在进行更新之前，确保该进程集合已完全完成。
• 此前，如果在 CRI-O 容器启动后立即停止，升级过程中会发生异常。 此问题现已通过在客户端初始化时进行版本检查并预加载必要类来解决。
• 此前，采用选择性监控的方式有时会导致容器和进程的数据收集不完整。 该问题现已通过查询所有容器和进程得到解决，不再仅依赖于选择性监控。
• 此前，在 cgroup 数据启动过程中处理负值会导致内存和 CPU 使用率出现突增。 此问题现已通过将所有负值归零来解决。
• 此前，曾在非 Linux 系统以及缺少正确 /proc 目录的系统上尝试检测cgroup，这导致了错误。 该问题现已通过将 cgroup 检测范围限制为具有有效 Linux/proc 文件夹的主机来解决。
• 此前，对 的内存 CGroupV2 使用量计算不准确。 此问题现已修复，通过将内存使用量正确计算为 和 anon 内存 file 的总和。
• 此前， Windows JVM 附件功能无论用户权限如何，均使用同一个全局 TEMP 目录，这导致了冲突并造成附件发送失败。 此问题现已修复，具体做法是确保挂载过程使用用户的目录 TEMP 。
• 此前， JVM 连接没有超时控制机制，这有时会导致连接问题。 此问题现已通过添加一个环境变量得到解决，您可以使用该变量来配置 JVM 的连接超时设置。
• 此前，若未能为入站通信绑定端口，系统不会触发任何重试操作，从而导致连接问题。 此问题现已通过为端口绑定失败实施重试机制得到解决。
• 此前，在进行容器特定查询时 null ，环境变量映射中的值可能会导致错误。 此问题现已通过添加对空值情况的正确处理得到解决。

• 代理 1.1.746: 现在， Log4j2 模式会在启动时更新。
• 代理 cgroup 1.0.2: 通过使用容器中任何可用的进程，现已修复了 cgroup 数据查找问题。
• 代理进程处理 1.0.12: 此软件包已添加以下更新：
  • PID 1 现已被正确识别为主机上的进程，而非容器进程。
  • 已添加空值检查，以解决在 ContainerD 过程中因命名空间为空而引发的 NullPointerException 错误。
  • 在收集支持信息时，会为进程对象提供额外的调试信息。
• agent util 1.0.10: 为带注解的方法添加了一个跟踪日志器。

• 代理框架现已支持基于方法的跟踪日志记录。 尽管该功能可通过框架实现，但目前必须为每个方法添加注解才能启用跟踪日志记录。 该功能的全面支持计划在未来版本中推出。
• 现在， Log4j2 模板会在启动时自动更新，通过使用该模板，其中将包含 | %replace{%X{method}}{^(.+)$}{$1 | }方法信息。
• 在收集支持信息期间，现已提供针对进程的增强型调试日志记录功能。 现在，每种进程类型都会提供详细的内部调试数据，以方便故障排除和分析。

• 此前，PID 1 被误识别为容器进程。 此问题现已修复，系统已正确将 PID 1 识别为主进程。
• 此前，在容器化工作负载上，追踪器公告流程会失败。 此问题现已修复，具体措施包括放宽对 ContainerD 进程的容器环境查找限制，并正确将 PID 1 作为主机进程进行处理。
• 此前，当命名空间为空时， ContainerD 进程中会发生错误 NullPointerException 。 此问题现已通过添加空值检查得到解决。
• 此前，cgroup 数据查询未能正确利用容器内的可用进程。 现在，通过在容器内使用任何进程进行 cgroup 数据查询，该问题已得到解决。

• 代理 grpc 1.0.17: 现已导出额外的 io.grpc 组件（io.grpc.util 和 io.grpc.inprocess），以增强代理的通信能力。 此外，起始等级下调至70级。
• 代理可选 API 1.0.8: 此软件包已更新，可按预定义的顺序执行配置步骤。
• 代理 1.1.745: 此软件包已更新，现可通过环境变量（使用 agent_env）和配置文件（使用 agent_file）从代理读取配置，并整合来自多个同名传感器及 entityId的传感器数据。
• agent cri client 1.0.2: 此软件包已更新，以确保与 agent grpc 1.0.17 软件包更新兼容。
• 代理 JVM 处理 1.0.13:。此软件包已更新，在检查 J9 JVM 是否包含 com.ibm.tools.attach.directory 启动参数时，会评估环境变量 (IBM_JAVA_OPTIONS, JAVA_TOOL_OPTIONS, 和 _JAVA_OPTIONS)，并将 attach-tools 更新至版本 1.17.2 ，以正确处理显式目录定义。
• 代理进程处理 1.0.10: 此软件包新增了以下更改：
  • 已为容器环境变量（支持 Podman、 Docker 和 CRI-O ）添加了选择性监控功能，这使代理能够决定是否对某个进程进行监控或忽略该进程。
  • “jail toot” 进程的处理仅限于 Linux 系统。
  • 通过将具有相同值的进程中的字符串、参数和环境变量进行内部化处理，从而减少了进程的内存占用。
  • 已修复在将文件复制到具有严格 umask 设置的无根目录 Podman 容器时出现的文件权限问题。
  • 已启用 CriClient 原生功能，该功能由环境变量控制 INSTANA_USE_CRI_CLIENT。
• 代理进程处理 1.0.11: 此软件包已更新，在执行进程调用时将始终使用可变环境映射。
• 代理运行时 API 1.0.5: 已添加指向内部列表和映射的接口。
• 代理运行时 1.0.5: 已实现列表和映射的内存池化。
• agent util 1.0.9: 添加了两个辅助方法，用于处理和列出文件权限，以及遍历 iterate 一组 Optional 供应商对象。

• 现已导出更多 gRPC 组件，以扩展代理的通信功能。
• 代理配置步骤将按照预定义的顺序依次执行，以优化配置流程。
• 代理现在可以在代理上下文中同时替换环境变量和文件中的配置。
• 自动合并来自名称相同且扩展名为 entityId. 的数据源的传感器数据。
• 该代理现在为容器环境提供选择性监控。
• 默认 CriClient 情况下启用内部运行时，确保与现代容器运行时无缝集成。

• 此前，当环境变量（IBM_JAVA_OPTIONS, JAVA_TOOL_OPTIONS, 或 _JAVA_OPTIONS）中的任何一个显式定义了 com.ibm.tools.attach.directory 时， JVM 的附加过程在 J9 JVM 上会失败。 该问题现已通过评估这些环境变量，并更新 attach-tools（ v1.17.2 ）以正确处理显式目录定义的方式得到解决。
• 此前，当主机上存在大量具有相同参数和环境变量的进程时，代理程序会因内存不足而崩溃。 此问题现已通过将字符串、参数和环境变量进行内存缓冲来解决，从而减少了内存占用。
• 此前，在严格的 umask 设置下，将文件复制到无 root 权限的 Podman 容器时，曾出现文件权限问题。 通过在复制中间文件之前对其设置文件权限，该问题现已得到解决。
• 此前，在 Red Hat OpenShift Container Platform 4.18 环境中，当 crun 是默认容器运行时，代理默认不会使用 CriClient 内部功能。 此问题现已通过将缺失的 INSTANA_USE_CRI_CLIENT 变量视为 true 来解决，从而确保与新的容器运行时默认设置兼容。
• 此前， Solaris 上的监狱根目录查找问题导致所有进程都被错误地识别为监狱根目录。 该问题现已通过将监狱根进程的处理范围仅限于 Linux 系统来修复。

• 代理程序 1.1.744: javaagent-loader 已更新至版本 1.3.66。 此外， instrumentation‑shared 已更新至 1.0.145 版本，新增了在仪器化过程中忽略特定包的功能。
• agent internal API 1.0.14: 新增了一种查询基于进程的传感器所有已知进程 ID（PID）的方法。
• agent‑cgroup 1.0.1: 该软件包已更新，现仅在 Linux 系统上执行 cgroup 版本检查。
• agent‑jvm‑handling 1.0.12: 当 /tmp 不可用时，监控问题 jvm_tmp_not_availableagent_tmp_directory_missing 将更新为。 此外，该软件包已更新，现支持对基于Jail的root JVM进行持续 /tmp 可用性监控。
• agent‑process‑handling 1.0.9: 该软件包已更新，新增了以下更改：
  • 符号链接检查期间的异常日志级别已降至 DEBUG.
  • 基于事件的处理机制取代了基于定时器的做法，用于更新基于 Garden 的容器的iptables。
  • 已修复在 Windows 上对不规范路径进行规范化处理时出现的解析问题。

• 新增了一种方法，用于查询基于进程的传感器所关联的所有已知进程 ID（PID）。 这种新方法改善了流程的追踪和监控。
• 在基于 Garden 的容器中，进程处理包现已改用基于事件的更新机制，取代了此前基于定时器的更新方式来更新iptables。

• 此前，cgroup 软件包会在非 Linux 系统上执行不必要的 cgroup 版本检查。 该问题现已通过将版本检查范围限定为 Linux 环境而得到解决。
• 此前，cgroup 软件包中的内存解析过程添加了错误的限制。 此问题现已通过添加两个新的辅助函数 和 parseMemoryDataCgroupV2 来读取正确的 parseMemoryDataCgroupV1 内存文件而得到解决。
• 此前， JVM 处理包曾报告过一个 jvm_tmp_not_available 监控问题：当基于jail根目录的JVM无法访问该 /tmp 目录时，该问题便会出现。 该问题现已通过更新监控问题至 agent_tmp_directory_missing 并添加对监狱根 JVM 的持续监控支持而得到解决。
• 此前，在 Linux 上的符号链接检查中发现的异常会被以高详细度级别记录，这导致日志过于冗长。 此问题现已通过将日志级别降至 DEBUG. 解决。
• 此前，在 Windows 上，处理包的过程在规范化无效路径时遇到了问题。 该问题现已通过改进 Windows 路径规范化的逻辑得到解决。

• 代理 1.1.743: javaagent-loader 已更新为 1.3.65。 此外， instrumentation-shared 已更新至 1.0.144 ，以修复仪器日志中的内存泄漏问题。
• 已为代理后端 1.0.5: 添加了对 capabilities 端点的处理。
• 代理 JVM 处理 1.0.11: 已添加对 JVM 监狱根目录的支持。 此外，该软件包现在支持在 JVM 无法使用 /tmp 时 jvm_tmp_not_available 进行监控。
• 代理进程处理 1.0.8: 已添加对进程使用 jail 根目录的支持。 此外，该软件包现已支持在 z/OS 上为 WebSphere 获取环境变量。
• 代理进程处理 API 1.0.3: 该软件包已更新，在内部 API 层面上增加了对监狱化根进程的支持。
• agent util 1.0.8: 该软件包已更新，新增了用于 FilePermissions 的辅助程序。
• 代理 grpc 1.0.16: 已从包中移除了 gRPC 服务器。
• 代理程序已启用遥测服务 1.1.5:。该软件包已更新，现 MachineId 使用 OpenTelemetry 实体与主机实体建立关联。
• 代理打开遥测 GRPC 1.1.5: 已将 gRPC 服务器添加到包中。

• 已为 JVM 和进程添加了对沙箱根权限的支持。
• 在代理后端中，对功能端点的处理得到了增强。
• OpenTelemetry 通过使用……将主机和 OpenTelemetryMachineId实体关联起来，从而提升了集成效果。

• 此前，仪器日志曾出现内存泄漏问题。 此问题现已通过将 instrumentation-shared 文件更新至 版本得到 1.0.144解决。
• 此前，即使不需要 gRPC 服务器，它也会作为该 agent grpc 软件包的一部分启动。 该问题现已通过将 gRPC 服务器从 迁移至 agent grpc bundle 包中 agent open telemetry grpc 得到解决。

• grpc core 1.0.15: 此软件包将 protobuf-java 更新至版本 4.29.3 ， protobuf-java-util 更新至版本 4.29.3 ，以及 proto-common-google-common-protos 更新至版本 2.50.1。
• 代理进程处理 1.0.7: 此软件包添加了用于在 Tanzu 集群上识别 ctr 位置的逻辑。

此前，Tanzu Clusters 上 ctr 的位置未被正确识别，这导致了容器操作出现问题。 通过添加逻辑以准确检测此类环境中的位置 ctr ，该问题现已得到解决。

• cgroup 代理 1.0.0: 此软件包解析控制组（cgroup）数据，可作为容器指标的服务使用。
• agent cri client 1.0.0: 此软件包与容器运行时接口（CRI） API gRPC 端点进行交互。 这些交互功能包括列出容器、读取容器状态、获取镜像状态以及在容器内执行命令。
• 代理 GRPC 通道缓存 API 1.0.0: 此软件包通过 ManagedChannels 提供对 Unix 域套接字端点的访问。
• 代理 GRPC 通道缓存 1.0.0: 此软件包提供了一种缓存机制，用于通过 ManagedChannels 访问 Unix 域的套接字。

• 代理后端 1.0.4: 在从后端接收的 JSON 数据中，为该 messageId 字段添加了空值检查。
• 代理 JVM 处理 1.0.10: 已为 JVM 的附件添加了一个新进程。 UnifiedProcess
• 处理 API 的代理进程 1.0.2: 已添加用于检索具有扩展功能 UnifiedProcessBuilder 的方法。
• 代理进程处理 1.0.6: 此软件包已更新，以增强文件权限设置，以便在无root权限的 Podman 环境中复制临时文件。 该 podman info 命令现用于查找单个用户的 Podman 套接字。 此外，还增加了以下更改：
  • CRI 流程现通过使用新的 UnifiedProcess 抽象层来处理，这使得能够支持 CrioProcess.
  • CrioUtil 现在已扩展，在配置后 CriClient 可与 配合使用。
  • 已添加环境变量 (默认值： INSTANA_USE_CRI_CLIENTCriClient false) 以启用。
• 代理工具 1.0.7: 该软件包已更新，新增了以下组件：
  • 用于抛出异常的函数的辅助工具
  • 一个用于管理期货的工具
  • 一个用于停止 ThreadPools 的辅助工具。此外， LinuxProcFileParser 来自进程处理包的功能已迁移至此包。
• 代理 1.1.742: 该软件包已更新，通过让实体在数据为空时保持活动状态来改进实体管理，从而防止它们被标记为离线。 通过返回长度为零的字节数组，改进了对空文件的处理。 此外，添加公共 IP 网关监听器的流程已修改为同步模式，而非异步模式。

• 添加此 UnifiedProcess 抽象层旨在为管理常规进程和 CRI 进程提供扩展功能。
• CriClient 并添加了相关配置，以便与 CRI API gRPC 端点实现无缝交互。
• 添加此 agent cgroup 软件包旨在增强容器指标管理功能。
• 该 agent util 软件包现已提供了更完善的资源和线程管理功能。

• 此前，后端中的某些实体因数据缺失而被标记为离线状态。 此问题现已通过让实体在数据为空时保持存活来解决。
• 此前，代理在处理空文件时会出现意外行为。 此问题现已修复，当遇到空文件时，系统会返回一个长度为零的字节数组。
• 此前，添加公共 IP 网关兴趣的异步处理过程曾导致延迟。 通过将该操作改为同步方式，此问题现已修复。
• 此前，在无根权限的 Podman 环境中，由于相关 umask 设置的原因，即使临时文件已设置了正确的权限，仍会被覆盖。 该问题现已通过在创建临时文件后显式设置文件权限得到解决。

• 代理 JVM 处理 1.0.9: 该软件包已更新，以改进在无法使用 JVM 连接时的日志记录功能。
• 代理进程处理 1.0.5: 已更新该软件包，以修复 ContainerD 实例设置了错误套接字的问题。 此外，该代理现在会忽略 z/OS 上的控制区域。 将文件复制到 Podman 容器中的功能已得到改进。
• 代理套接字服务器 1.0.2: 已更新该软件包，以修复 JVM 连接中的竞争条件。
• 代理程序 1.1.741: 该软件包已更新，当代理程序使用与 Java 不兼容的版本时，会触发监控事件。

Instana 代理已停止对 Java 8的支持。 您必须使用 Java 11。 当您使用 Java 8启动新安装的代理时，该代理现在会显示一个监控事件。 此监控事件仅在您安装或使用自己的 JVM 时才适用。 基于容器或包的代理已使用 Java 11。

• 此前，在无根 Podman 环境中，由于代理未为临时文件定义权限集，导致将文件复制到目标容器时可能会失败。 此问题现已修复，临时文件将以 rwxr-xr-x. 开头创建。
• 此前，当存在多个套接字时，代理无法为 ContainerD 实例设置任何套接字信息。 此问题现已修复，代理会为 ContainerD 实例设置正确的套接字信息。
• 此前，该代理在 JVM 连接上存在竞态条件，即使连接在内部已被标记为已关闭，它仍会保持该连接处于打开状态。 只有在重启代理后，错误的连接才被移除。 此问题现已修复，代理服务器能正确关闭异常连接。