Kubernetes 2.0 Agents

New Features

Support for HPE Kubernetes Service (HKS)

OpsRamp now supports HPE Kubernetes Service (HKS) as a distribution type within the Kubernetes 2.0 integration. You can select HKS during integration setup to enable seamless discovery and monitoring of HKS-based clusters.

When you select the HKS distribution type, the integration automatically configures the required etcd certificate host paths and enables etcd metrics collection giving you full visibility into the availability, performance, and telemetry (metrics, events, and logs) of your HKS environments.

See the Kubernetes 2.0 Installation document for more information.

Enhancements

Kubernetes Annotation-based Auto discovery for Workload Monitoring

The OpsRamp Kubernetes 2.0 Agent now supports annotation-based auto discovery and configuration for workload monitoring. You can express monitoring intent directly in your workload manifests (such as Pods or Deployments) using standard annotations, allowing the Agent to automatically discover and scrape metrics for applications like Redis, Kafka, NGINX, and Prometheus.

By moving monitoring configuration to the workload level, you can manage observability requirements alongside your application code in GitOps workflows, reducing reliance on centralized ConfigMap management and speeding up time-to-observe for new services.

See the Annotation-Based Auto Monitoring document for more information.

Independent Configuration for Kubernetes Events

Introduced independent configuration capabilities for Kubernetes events, allowing you to define separate filter criteria for logs and alerts. This enhancement decouples the event processing pipeline, enabling you to export a broad set of events as logs for comprehensive visibility while simultaneously applying narrow, specific filters for alerts to minimize noise.

You can now apply distinct settings for namespaces, event types, and involved objects (reasons) within new logs_config_override and alerts_config_override blocks in your configuration. This flexibility helps you optimize log ingestion costs by targeting specific namespaces for logging while maintaining cluster-wide alerting, or by mapping different severity levels to logs versus alerts. The system automatically detects these overrides and maintains full backward compatibility for existing configurations.

See the Kube Events document for more information.

Exclusion-Based Filters for Kubernetes Event Configuration

Kubernetes event configuration now supports exclusion-based filtering, giving you more granular control over event collection. Instead of maintaining extensive inclusion lists, you can simply define namespaces and event reasons to exclude filtering out noisy or low-value data while keeping event monitoring focused on critical activity, with less overhead when new Kubernetes resources or event reasons are introduced.

Key capabilities include:

• Namespace Exclusion: You can now specify a list of namespaces to ignore, enabling you to monitor all namespaces except for specific ones like kube-system or kube-public.
• Event Reason Exclusion: You can exclude specific event reasons (such as Evicted or BackOff) for different object types, preventing high-frequency noise from flooding your event stream.
• Optimized Defaults: Several high-volume, low-signal event reasons - including Killing and BackOff (Pod), NodeReady, and Starting (Node), and SuccessfulCreate and SuccessfulDelete have been removed from the default inclusion lists to improve out-of-the-box signal quality.

See the Kube Events document for more information.

Multiline Log Grouping for Kubernetes Logs

The Kubernetes 2.0 Agent now supports multiline log grouping, enabling you to consolidate fragmented log entries into single, coherent records.

You can define custom rules to automatically recombine complex logs such as Java stack traces, Python tracebacks, and multi-line JSON objects, ensuring they are reported in the correct order. This gives you better visibility and easier troubleshooting by presenting related log lines as a single entry within the platform.

See the Multiline Log document for more information.

Enhanced Kubernetes 2.0 Logging Capabilities

Kubernetes 2.0 logging now offers more flexible, granular control over how logs are enriched, classified, and secured.

• Custom Attribute Injection: Add custom Kubernetes attributes (such as container.image.name) to pod logs via the opsramp-logs-user-config ConfigMap, with automatic deduplication against default attributes.
• Improved Log Level Classification: Log level detection has been upgraded to support klog prefix detection (I/E/W/F/D), word-boundary keyword scanning across 12 severity levels, and stdout/stderr stream-based fallback with a nil guard to safely handle missing message bodies.
• Expanded Masking Modes: The masking feature now supports four modes per rule; replace, partial, hash, and redact_key — giving you fine-grained control over how sensitive data is handled.

See the Log Management document for more information.

Deprecated Discovery of Pod Annotations

The Kubernetes 2.0 Agent no longer discovers Pod annotations or sends them as custom attributes to the SaaS platform. This prevents sensitive or customer-specific data stored in pod annotations from being inadvertently collected or transmitted, helping you maintain enterprise privacy and data governance standards.

By removing the automatic collection of these user-controlled metadata fields, you benefit from a more secure and compliant monitoring environment. Annotations needed for internal system functionality such as PCAI and Dynamo CRDs continue to be supported, so operational stability is unaffected.

See the Deprecation document for more information.

Bug Fixes

• Resolved an issue where the masking processor always applied masking to the log body, regardless of the configured attribute_type. Masking is now correctly limited to the specified attribute type. Log body content is masked only when no attribute_type is defined, preventing unintended data modification and preserving log body integrity for attribute-scoped masking rules.

VM Agent

New Features

Support for Alibaba Cloud Linux

OpsRamp Agents can now be deployed and upgraded on Alibaba Cloud Linux. This enables you to deploy and upgrade OpsRamp Agents on Alibaba Cloud ECS and EMR cluster nodes, for seamless resource monitoring and management. With the latest Agent version, resource reconciliation and correlation are more accurate, eliminating duplicate resource entries and ensuring consistent visibility across your Alibaba Cloud environment.

See the Deployment on Linux Distributions document for more information.

Enhancements

Persistent Agent Logging Levels During Upgrades

Agent logging levels are now preserved across agent upgrades. Previously, upgrading the agent could reset the configured logging level to the default setting, which could interrupt troubleshooting and make it difficult to investigate intermittent connectivity or performance issues.

With this enhancement, if you configure Debug or Trace logging for troubleshooting, the selected logging level remains active after the agent upgrade. You no longer need to manually reconfigure the logging level after each upgrade, ensuring consistent diagnostic logging across agent versions.

Automatic Patch Retry for Failed Patch Operations

OpsRamp Agents now automatically retry failed patch operations up to two times when failures occur during patch download or installation. Retries are performed immediately by the agent to improve patch success rates without requiring manual intervention.

To minimize alert noise, you will receive a single notification only after the patch succeeds, or all retry attempts are exhausted, not one per failed attempt. Patch reports also now include detailed audit information, such as failure reasons and retry counts, making it easier to troubleshoot failed operations and track patch compliance across your environment.

See the Patch Managament document for more information.

Bug Fixes

• Fixed an issue where the OpsRamp Agent could not be installed or run on Oracle Linux servers using non-root user accounts. The Agent now installs and runs successfully in environments where root access is restricted.
• Fixed an issue where Linux virtual machines were incorrectly identified as KVM hosts, causing unintended resource deletions in VMware environments. The agent now correctly filters discovery data.
• Fixed resource deletion and inconsistent Agent status that occurred when installing the OpsRamp Agent on hosts already managed by the HPE VM Essentials integration.
• Fixed an issue where system.memory.cache.utilization reporting incorrect values on Linux devices, which triggered false critical alerts. The Agent now defaults to 0% for invalid memory readings.
• Fixed incorrect metric parsing for filesystem names containing spaces, which caused false alerts and inaccurate disk capacity reporting. Disk monitoring now correctly handles spaces in mount and disk names.
• Fixed an issue where large metric payloads in high-scale environments were dropped or silently lost due to size limits and processing conflicts. Metric chunking is now applied automatically, ensuring high-cardinality metrics are delivered reliably to the platform without data loss.
• Fixed an issue where KVM discovery was unexpectedly initiated on Linux virtual machines after upgrading to OpsRamp Agent v20.0.0. The fix deploys an Agent script to remove the obsolete MTKVM discovery payload, preventing unintended KVM detection and improving discovery reliability.
• Fixed an issue where installed patch information was not reported on Windows because the fetchInstalledPatches.ps1 script generated invalid XML for certain ClientApplicationID values. The script now normalizes these values before generating XML.
• Fixed an issue in Remote Script Executor (RSE) templates where timed-out PowerShell scripts left orphaned child processes running on monitored servers. The Agent now uses recursive process termination to ensure that the primary script and all associated child processes are terminated when a timeout occurs.
• Fixed an issue where the Agent incorrectly reported the patch installation status as Download Complete when no patches were missing, ensuring accurate patch progress and installation status reporting.
• Fixed an issue where the Windows Agent reported incorrect CPU utilization values due to precision loss, when converting CPU time values to integers, causing false spikes at low load levels. The Agent now retains full floating-point precision for CPU calculations, ensuring accurate CPU load reporting.