The following changes have been made to the Kubex in this release:

• Updated AI Analysis Details Tab—The following changes have been made to this tab:
• Two new columns, "Additional CPU Waste ($/month)" and "Additional Memory Waste ($/month)" have been added to help you eliminate wasted resources.
• Two new system views, "Additional CPU Waste" and "Additional Memory Waste" have been added.
• The system views, "Realizable CPU Savings" and "Realizable Memory Savings" have been renamed to "Immediate CPU Savings" and "Immediate Memory Savings".
• The columns "Realizable CPU Savings" and "Realizable Memory Savings" have also been renamed to "Immediate CPU Savings" and "Immediate Memory Savings".
• The Default view has been updated to sort by Total Waste in descending order. This column is also pinned to the left side of the table so you can easily see the column on which the table is sorted.
• Updated Overall Spend Chart —The unit cost values for CPU and memory have been added, for your information. By default, the unit costs are $20/core, $5/GB. The cost per core and per GB of memory is configurable. Contact [email protected] for details.
• Hyperlinks added to the Optimization Breakdown CPU and Memory Bars —Six click-through links have been added to the CPU and memory badges. Clicking the badge opens the relevant view on the AI Analysis Details tab.
• Using Working Set Memory—The following updates have been made to utilize working set memory metrics:
• A new chart, Working Set Memory Utilization (%) has been added to the Utilization Charts section of the Nodes tab.
• When calculating node memory saturation, Working Set Memory is now used.
• The Overview tab has been updated to add charts for Memory (RSS) Utilization and Memory (Working Set Memory). The popup charts views have also been updated to add these memory metrics as configuration options.
• The Metrics Viewer has been updated to add "Memory (RSS) Utilization" and "Memory (Working Set Memory)" as configuration options.

Refer to the Kubex documentation for details.

The following changes have been made to Kubex in this release:

• New Breakdown Tab—The Breakdown chart has been removed from the Summary tab to its own tab. It shows how your environment is performing in terms of risk due to under-provisioned resources and wasted resources due to over-provisioning.
• Updated Container Summary Page—The Container Summary page has been redesigned to improve usability.
• Updated Order of Container Tabs—The new Summary tab is now the start page. The order of the other tabs has changed to improve usability: Summary, Breakdown, Histogram, AI Analysis Details and Policies.
• Realizable CPU and Memory Savings-New columns have been added to the AI Analysis Details page to show CPU and memory savings and stranded resources. Two new views have also been added, allowing you to focus on these potential savings.
• Average Number of Containers—The method used to determine the average number of containers has been updated in this release. The value is displayed in the "No. Of Containers" column in the AI Analysis Details tab.

Updated Column Values—The way the following values are calculated has also been updated to use the new Average Number of Containers and the Uptime:

Total Surplus CPU Request Total Surplus Memory Request

Savings per container ($/month) Total Savings ($/month)

Previously, the cost values are based on the last known number of containers and uptime is not used.

Refer to the Kubex documentation for details.

See 2.10.0 March 5, 2025 for the list of resolved defects.

The following changes have been made to the Kubex in this release:

• Policies Tab—A new tab has been added that displays the policies that have been applied to your container analyses.
• A flyout pane displays the details of the key policy settings.
• The flyout pane is also displayed when you click the policy hyperlink in the AI Analysis Details tab.

• Container Policy data is no longer available in the Densify Console

• Node Group Overview—When a single node group is selected in the tree viewer you now see a node group overview page. This page contains node group utilization details as well as utilization charts. You can open a modal view of each chart to review specific details of the node group's utilization.

Overview pages are now provided for a single node and a single node group.

• Node Group Modal Views—Modal views and all of the associated features are now available for node groups.
• Side Navigation Bar—The side bar has been updated to improve usability.

Refer to the Kubex documentation for details.

The options under the Kubernetes menu, in the Densify Console have all been removed, with the exception of the link to open Kubex.

The corresponding content has been removed from the Densify online help i.e. Analysis, Data, Details, Policies tabs.

Your container analysis results and policy settings are all displayed in the Kubex interface. Refer to the Kubex documentation for details.

The following changes have been made to the license compliance reports: 

• The license compliance report has been updated to include Azure VM Scale Set license counts.
• VM Scale Set singletons will be counted like Azure VMs.
• Standard VM Scale Set, where max size ≠ 1 will be counted using the new, average size method used for AWS ASGs.
• The logic used to determine the license count for scale sets has been updated as follows:
• Currently, 1 ASG uses 4 licenses in the report. In this release the average size of each scale set will be used to determine the license count. The average size of each scale set will be summed and used to determine the license count.
• The existing method (i.e. 1 ASG=4 licenses) will be retained for existing customers. On upgrade, the method of counting licenses will not change.
• New users with both ASGs and VM Scale Sets will use the new method.
• The following changes have been made for containers:
• Currently, for containers there are 2 methods for determining the license count: 1 license per N containers or 1 license per licensed node core. In this release a third option has been added: 1 license per N pods. The number of pods is configurable, and the default value is set to 5 pods.

The existing methods will be retained for existing customers. New customers will use the new method. On upgrade, the method of counting licenses will not change.

Additionally, the license compliance report has been updated to add a rolling 30-day average to show license usage trends.

In this license report you cannot correct the historical licensing data because the required historical data is not retained. After upgrading to v2.9.0 the licensing counts will be corrected and stored accordingly.

See License Compliance Report for details of the updated logic.

See 2.9.0 February 28, 2025 for the list of resolved defects.

The following changes have been made to the Kubex in this release:

• Connections Status—A new Connections status page provides details of all your container data collection. Visibility of the time and date of the last collection, for each cluster allows you to troubleshoot data collection issues immediately.
• Node Tree Viewer—The tree viewer has been added for node group navigation. You cannot create views and filters from the tree viewer.
• Node Groups Summary Bar—A summary bar has been added to the Node Groups page. The number of clusters, node groups and average number of nodes provide a high-level summary of the scope of systems included in the displayed report. The summary data is based on your selection in the tree viewer.
• Node Groups Days of Data—The number of days of data that have been used for the analysis is listed both in the breadcrumbs at the top of the page and as a footnote at the bottom of page.
• Node Overview—When a single node is selected in the tree viewer you now see a node overview page. This page contains significant node utilization details as well at utilization charts.
• Node Modal Views—Modal views and all of the associated features are now available for nodes.
• Deep Links—You can navigate through the tree view and then send a link of the specific node or container to another Kubex user. When the user accesses the link, they are taken to the same location in their UI with the selected container or node details displayed.
• Updated Buttons—The Histogram page has been updated to add icons to each button. These buttons are used to configure the content of the histograms.

Refer to the Kubex documentation for details.

• Clear Filter—An option has been added to all table views that allow you to clear all filters.
• Saving Tree Views—The workflow for saving customized tree views has been streamlined.
• Added Hyperlinks— Links have been added from a container’s modal overview and chart views on the AI Analysis Details page to that container’s Overview and Metrics Viewer pages.
• Modal Chart Views—The full set of chart features has been added to the Node utilization charts.

Refer to the Kubex documentation for details.

Densify user management now provides automated provisioning of user accounts when using Azure AD integrations. Once OpenID has been enabled users can login directly and do not need to be manually added to Densify.

User groups must be configured in Azure AD and users need to be added to one or more of DENSIFY_USER, DENSIFY_USER_ADMIN or DENSIFY_AUDIT_ADMIN groups, in Azure AD. Additionally, the API permissions for the Densify web application need to be updated to add "GroupMember.Read.All".

The deprecated API should be removed from your configuration and the Azure Active Directory Graph User.Read permission can be revoked. Refer to https://techcommunity.microsoft.com/blog/microsoft-entra-blog/june-2024-update-on-azure-ad-graph-api-retirement/4094534

Densify's Azure AD solution has also been updated to use the Azure API call https://graph.microsoft.com/.default. Previously, the API, https://graph.windows.net/User.Read was used and this API has now been deprecated.

See Configuring External User Authentication for details of configuring Open ID and External User Authentication Example Configuration for Azure Active Directory for specific details of Azure AD configuration.

This user automated provisioning model is not currently supported for Okta, Google nor Ping.

The public cloud metadata catalogs have been updated to ensure Densify recommendations are based on the latest vendor pricing:

• You can now access the Kubex Console from the Kubernetes menu in the Densify Console
• The container tree viewer now allows you to create views and filters and save them for public or private use.
• The workload charts, when expanded (modal view) now show the ML model (i.e. the representative day on which the predictive analytics are based), historical quartiles and historical, 5-min interval data.
• New histogram badges have been added that indicate issues in the selected scope of systems. You can click on the hyperlinked title to open a specific view in the AI Analysis Details tab, that shows only the relevant containers.
• You can now access the Container metrics viewer. The same functionality is also available using the Utilization Charts on the AI Analysis Details tab.
• You can now create customized views and send the resulting link to other Kubex users.
• In tabular views, you can now group results by selected columns. Your selections define the structure of selected tabular reports.
• Pivot table functionality is now available on all tabular views.

The following changes have been made in the Analysis Console and the Densify Console to facilitate user management:

• Changes to user management now allow Open ID users to create, edit or delete user accounts through the Densify Console. Previously, once Open ID was enabled, the user management features in the Densify Console were not accessible. With this update, even with Open ID enabled, users with the appropriate role can now create, edit or delete user accounts.
• A new user role, SaaS_Audit_Admin has been added and the permissions for all 3 roles have been adjusted as follows:
• SaaS_User—Users with this role can no longer create, edit or delete cloud audits.

Note:  Users with only the SaaS_User role will lose the ability to manage Cloud Connections after upgrading to 2.7.0.

• SaaS_User_Admin—Users with this role can no longer create, edit or delete cloud audits. Users do not need both SaaS_User.
• SaaS_Audit_Admin—Users with this role can create, edit or delete cloud audits, but cannot manage user accounts.

After upgrading to this version, users with the SaaS_User and SaaS_User_Admin role need the new role added, if they manage cloud connections. See Managing Densify User Accounts

When creating connections from the from pre-data landing page, only users with the SaaS_Audit_Admin role can create cloud connections. See Densify Console Landing Page.

• The Report Designer role has been removed from the user management dialog box in the Densify Console.
• Additional logging has been added to the standard, web log, that now reports on all user activities such as:

Adding or deleting user roles Changing passwords Changing configuration settings

Creating, editing and deleting user accounts Creating, editing and deleting cloud connections Logging in/out

Although logging has been added to the web log, you will need to request the log data from [email protected].

The following updates have been made on the container pages:

• Relearning Workload Patterns for Containers—When analyzing container environments, workload history will now be retained for systems that have had request/limit values changed. i.e. there is no longer a relearning workoad period, for Containers after a change in CPU/memory request/limit values.

The attribute, "ConfigLastChanged" is still updated with the date on which, a limit or request value is modified and is reported on Kubernetes Container Optimization Details page. Reviewing Cloud Recommendations

• Publish all Representative Workloads—The workload charts, "Memory (Working Set) Utilization" and "Memory (Working Set) Utilization - Container Average" are now always shown on the lower pane of the Kubernetes Container Optimization Details page. Previously, these charts had to be enabled using a policy setting.

Note:  If Memory (Working Set) Utilization has not been enabled, the working set metrics are not used in the analysis

See Optimizing Your Containers - Details Tab.

The result of the Effort Estimate calculation for systems where the current instance type is the same as the recommended instance type and the analysis_score = 0, has been updated to return "None" rather than "Impossible". This now aligns with the value shown in the UI. See Densify API New Features.

The public cloud metadata catalogs have been updated to ensure Densify recommendations are based on the latest vendor pricing and instance availability across regions:

The list of minimum required permissions has been updated to remove the following AWS permissions:

• elasticache:DescribeCacheClusters
• elasticache:DescribeReplicationGroups
• elasticache:ListTagsForResource

See Creating an IAM Policy with Minimum Permissions for the CloudWatch Data Collection for the complete list of required permissions.

See 2.7.0 December 18, 2024 for the list of resolved defects.

You can access the new console from your existing instance using:

https://<customer name>.densify.com\kubex

Externally authenticated, OpenID-enabled customers can use:

https://<customer name>.densify.com:8443/kubex

See the new Kubex website for a product demonstration or to start a free trial.

• A new Node Group Health page has been added to report on the node groups that are hosting your container environments. See Node Group Health Tab.
• A new Node Group Capacity page has been added to report on the node groups' available capacity. See Node Group Capacity Tab.
• A new Nodes page provides utilization details of the individual nodes in a selected node group. You can access this page using the hyperlink on the Node Group Health page. See Nodes Tab.

The main menu located at the top of the Densify Console has been updated as follows:

• "Containers" has been renamed to "Kubernetes". Clicking this item opens the menu to show the 3 new options.
• Containers—This page contains the existing Summary, Data and Policies tabs. See Optimizing Your Containers.
• Node Groups—This new page contains the Health tab that displays node group details, as outlined above. A Capacity tab provides details of available node group capacity and optimization recommendations for the number and type of nodes.
• Add Kubernetes Cluster—Directs you to Densify's [Github repository] for details on deploying the data forwarder. The online help still provides details of prerequisites for deploying the data forwarder. See Container Data Collection Prerequisites.

The following pages have been updated as follows:

• Details Tab—A Node Group column has been added that indicates the node group associated with the selected container. See Optimizing Your Containers - Details Tab
• Data tab—The following columns have been added to the:
• Container Manifests with Restarts - Last Day;
• Container Manifests with Memory Limit Events - Last Day

See Optimizing Your Containers - Data Tab.

Densify has updated the method used to link containers to their infrastructure. In this release ASGs and VM Scale Sets to are matched to their node groups using attributes populated by the cloud providers and collected container data.

The following changes are a result of this new process:

• The following columns have been updated, on the ASG and VM Scale Set pages:
• "Kubernetes Cluster" has been renamed to "Kubernetes Cluster (from AWS)" for ASGs and "Kubernetes Cluster (from Azure)" for VM Scale Sets.
• "Kubernetes Cluster (from Forwarder)" has been added to both pages.
• "K8s Node Group" has been added to both pages.
• "ECS/EKS Reference" has been renamed to "ECS Reference" for ASGs, only.

See Reviewing the ASG Optimization Opportunity Report Columns. and Working with Virtual Machine Scale Sets

• For current Azure instances, any existing parent-child relationship with the resource group, has been removed. This change is necessary to establish a direct link between each VM Scale Set and one or more Azure node pools, ensuring accurate analysis and reporting.
• This process is now the default, but k8slinker is still supported and can be used for AWS only.

• Linking of ASG and VM Scale Set to node groups. These additional permissions are only required if you need to discover the transient node instances for ASGs or VM Scale Sets. In this context, transient indicates the parent nodes or node groups are not part of a Prometheus cluster. Contact [email protected] for details.

The following permissions are required:

• Microsoft.Insights/eventtypes/values/read—This Azure permission allows Densify to access event type values related to monitoring and insights.

See Microsoft Azure Data Collection Prerequisites for a Service Principal.

• autoscaling:DescribeScalingActivities—This AWS permission is required to collect the details of ASG scaling activities.
• Provide more accurate cost estimates using customer-specific discounted pricing. Contact [email protected] for details of configuring this features. The following permission is required:
• ce:GetCostAndUsage

See Creating an IAM Policy with Minimum Permissions for the CloudWatch Data Collection for the complete list of required permissions.

The CloudFormation template has been updated to add the 2 AWS permissions, listed above. The link to get the updated template is has also been updated to remove the version number: https://densify-cf-template.s3.us-east-2.amazonaws.com/Densify_CloudFormation.yml

The version number is available inside the .YML file.

See AWS Data Collection Using a CloudFormation Template for details on using the CloudFormation template to automate AWS data collection.

A new table filter allows you to create more complex filters on the following pages:

See Using the Table Filter .

A visual navigation tool has been added to more easily navigate the Densify Console. The "breadcrumbs" are located in the upper left corner of all pages and can be used to go back to previous pages. Do not use the browser's Back button for navigation within Densify. You will be logged out of your session. See Common UI Features for details.

The following pages have been renamed to streamline the breadcrumbs navigation path:

Table: Updated Page/Dashboard Names

Previous Name	New Name
Optimization Overview	Public Cloud Overview
Public Cloud Optimization for AWS	AWS Optimization
EC2 Instance Optimization Details	EC2 Instance Optimization
RDS Instance Optimization Details	RDS Optimization
Public Cloud Optimization for Azure	Azure Optimization
Instance Optimization Details (drill down from Azure VM summary)	VM Instance Optimization
Public Cloud Optimization for GCP	GCP Optimization
Instance Optimization Details (drill down from GCP summary)	GCP Instance Optimization
ASG Optimization Details	AWS Optimization
VM Scale Sets Optimization Details	Azure Optimization
Containers	Containers Overview
Kubernetes Container Optimization Details	Containers Optimization
Optimization Policies	Policies

The metrics viewer has been updated to show node metrics. A hyperlink from the Nodes page opens the metrics viewer with the selected node displayed. See Using the Metrics Viewer for Nodes.

A new workload type, "cpu_utilization_max" has been added. It stores the maximum CPU utilization in 5-minute intervals for both AWS and Azure instances. By default, averaged samples in the 5-minute interval are used to generate the quartiles. This workload enables the calculation of the quartiles using the raw, peak CPU metrics that are collected from the Azure and AWS APIs.

A new policy setting, "CPU Metric for Analysis" has been added to both the AWS Cloud Optimization and Azure Cloud Optimization packages. This new setting allows you to use the new metric in the optimization analysis for EC2 and Azure VMs only. AWS ASGs, RDS, Azure VM Scale Sets and GCP instances are not impacted. Contact [email protected] for details.

The metrics viewer has been updated to add this new metric for AWS EC2 and Azure VMs only. See Using the Metrics Viewer.

The following updates have been made to the Densify UI to enhance usability.

• Copy Text of Hyperlinks—You can now copy and paste the text of hyperlinks that are displayed on the various dashboards and pages. Previously these hyperlinks, typically, system ID information, could not be copied.
• Updated Workoad Charts—The workload charts displayed on the Details pages have been updated as follows:
• The selected entity's details are displayed in a single line across the top of the lower pane.
• The tabs, Approval and Edit System attributes have been removed from the AWS > RDS tab. The functionality has been deprecated and tabs have now removed from the lower pane.
• The system name and the title, "Workload Chart" have been removed. This information was redundant.
• The label, "Avg" has been changed to "Average" for all charts.

These changes have been applied to all public cloud and container reports that display workload charts, as well as the charts shown in the Impact Analysis and Recommendation Report (User Interface, PDF and those generated using the API).

• Accessing the Metrics Viewer—The lower pane of the Details pages for public cloud and containers has been modified to move the icons for the Catalog Map, the Metrics Viewer and the Impact Analysis and Recommendation Report, for increased visibility. Larger icons with links are now displayed on the left side of the lower pane.

Both of the above-listed updates have been made on the following pages:

ASG Details EC2 Instance Optimization Details RDS Instance Optimization Details

Azure Instance Optimization Details GCP Instance Optimization Details Kubernetes Container Optimization Details

• Updated Filename Format for Downloaded Files—The format of the date information that is appended to downloaded files has been updated to use the date format of your browser's locale settings. See Browser Requirements.

The public cloud metadata catalogs have been updated to ensure Densify recommendations are based on the latest vendor pricing and instance availability across regions:

Updated Cloud Environment Filter—The DCE Cloud Environment filter has been updated to was updated to exclude GCP MIG instances. ASG and VM Scale Set instances are already excluded, and GCP MIGs also need to be excluded. The MIG instances have the “auto scaling group” attribute set on the parent and children:

The last filter condition has been changed to add "vmm type not equal to gcp".

If you have customized the DCE Cloud Environment filter directly, your changes will be overwritten during upgrade. Contact [email protected] for details on migrating your filter.

See 2.6.0 September 27, 2024 for the list of resolved defects.

The following updates have been made in this release:

• Optimization Policies Tab—This tab has been added to the Kubernetes optimization dashboard. The page lists available container policies and details of each policy's settings including the default and the current value. See Policies Tab
• Deprecated Tabs—The Clusters and Namespaces tabs and content have been deprecated from the Kubernetes Container Optimization. The hyperlinks have been removed from the summary page but values continue to be reported.
• Container Details Page—The following changes have been made on the Details tab:
• The values in the Container Name column now contain a hyperlink that opens the corresponding metrics viewer.
• Added a new column, "Policy" with a hyperlink that opens the corresponding policy on the Policies tab.
• Three new columns have been added to report on restarts and memory events: Restarts - Last Day, Restarts, Memory Limit Event.
• Thirteen of the 27 columns have been hidden on this page to improve readability of the report. You can add/remove columns to the default view to customize the report for your use.
• The lower tab has been renamed to Predicted Utilization from Resource Utilization Metrics: Containers.
• Columns have been re-ordered to show information about the CPU, then Memory to more easily compare data.
• Renamed Workload Charts—In the lower pane of the Details tab the charts have been renamed to be more descriptive.
• The table design, for both the upper and lower panes has been modernized.

See Optimizing Your Containers - Details Tab.

• Container Data Tab—The following changes have been made on the Data tab:
• Nine of the 21 columns have been hidden on this page to improve readability of the report. You can add/remove columns to the default view to customize the report for your use. See Data Controls.
• The table design for both the upper and lower panes has been modernized.

The following additional container metrics are now collected:

• Container metrics are now collected as both:
• Avg—The average of all containers belonging to the same pod owner;
• Max—The “busiest” container of all containers belonging to the same pod owner.

This does not include current size and Horizontal Pod Autoscaler (HPA) metrics.

• Container Restarts are collected and summed by the data forwarder, to provide the total number of container restarts in the period.
• The metric, cpu_throttled_periods_percent is collected as both:
• Avg—The average time that the CPU was under pressure for all containers belonging to the same pod owner;
• Max—The most throttled container of all containers belonging to the same pod owner.
• The metric, cpu_throttled_seconds is collected and summed by the data forwarder, to provide the total time during which the CPU is throttled, in the period. This value is informational only.
• Container CPU and memory limits and requests are stored as hourly time series data instead of just the last known value:

CPU Request (mcores) - Current CPU Request (mcores) - Recommended CPU Limit (mcores) - Current CPU Limit (mcores) - Recommended

Memory Request (MB) - Current Memory Request (MB) - Recommended Memory Limit (MB) - Current Memory Limit (MB) - Recommended Disk I/O - Busiest Container (KBytes/s)

• New container metrics—The following container metrics are now collected and shown on the Details tab:
• Restarts - Last Day—The total number of restarts for yesterday.
• Restarts - Last 7 Days—The total number of restarts for the past 7 days.
• Memory Limit Event—A flag that indicate if a memory limit event occurred in the past 7 days. A memory event is defined as "memory working set" utilization exceeding a defined memory limit, indicating a potential out of memory (OOM) container kill.

See Optimizing Your Containers - Details Tab.

The following node-level metrics are now collected:

 
• The following metric for Kubernetes Nodes are stored as hourly time series data:

CPU Request (mcores) CPU Limit (mcores)

Memory Request (MB) Memory Limit (MB) # of Pods

See Optimizing Your Containers - Details Tab.

The metrics viewer has been updated to show container CPU and memory request/limit data as well as the number of container restarts. The metrics viewer allows you to view the raw utilization data stored in Densify’s time series database and used by Densify’s analytics.

.

Access the metrics viewer from the Kubernetes Container Optimization Details page.

See Using the Metrics Viewer for Containers for details.

The data retention period for container, cluster and node metrics data has been updated from 30 to 95 days. With this change additional container data will be available for the metrics viewer for containers.

In this release Densify supports collection of GPU data on EC2 instances with NVIDIA® GPUs.

• GPU Data Collection—You must enable data collection of the required metrics.
• Linux Servers—You need to modify the CloudWatch agent configuration file. For detailed information, see: https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Agent-NVIDIA-GPU.html
• Window Servers—Configure and use Amazon Custom CloudWatch Metrics. See https://repost.aws/questions/QUcyzZfm3UR96Qj8JiadlCAA/how-to-monitor-and-collect-gpu-metrics-for-windows-ec2-instances-using-amazon-cloudwatch

Alternatively, you can use a third party tool such as Telegraf.

• The following GPU metrics are required:
• utilization_gpu (metric name: nvidia_smi_utilization_gpu)
• utilization_memory (nvidia_smi_utilization_memory
• memory_used (nvidia_smi_memory_used)

See AWS Data Collection Prerequisites for an IAM Role (CloudWatch only).

• Metrics Viewer—The following new workloads, based on the above metrics are now available in the metrics viewer:
• GPU Utilization (%)—The GPU's utilization in percent.
• GPU Memory Utilization (%)—The GPU's memory utilization, as a percent of the total available memory.
• GPU Memory Utilization (MB)—The GPU's actual memory utilization.

See Using the Metrics Viewer.

The design of the Densify Console user interface has been modernized to improve usability. The changes have been made to all cloud and container pages that contain tabular reports.

The following changes have been made in the Public Cloud Instance Details report:

• The column, "%CPU Usage (High)" has been renamed to "CPU Usage (%)" for all cloud providers.
• The columns, "%CPU Usage (Low)" and "Active Memory Usage (%)" have been deleted from the public cloud optimization details page for all cloud providers.

The public cloud metadata catalogs have been updated to ensure Densify recommendations are based on the latest vendor pricing and instance availability across regions:

See 2.5.0 August 14, 2024 for the list of resolved defects.

In this release Densify now analyzes your Azure Virtual Machine Scale Sets (VM Scale Set) and generates recommendations for the optimal instance type and minimum and maximum size settings. The following changes have been made for this feature:

• Data Collection—The following permissions must be added to collect the data required for the VM Scale Set optimization analysis:
• Microsoft.Network/networkInterfaces/read—This permission allows Densify to collect the enableAcceleratedNetworking property of the VM's network interface, to ensure the quality of sizing recommendations.
• Microsoft.Insights/AutoscaleSettings/Read—This permission is required to collect the details of scaling configuration for Azure VM Scale Sets.

See Microsoft Azure Data Collection Prerequisites for a Service Principal.

• VM Scale Set Analysis —The following changes and additions have been made to analyze VM Scale Set data:
• When working with VM Scale Set, changes to the child instance types may result in inconsistent recommendations because they are based on historical workload data collected prior to the change. Invalidating the workload that was collected before the changes, removes the data from consideration, when generating recommendations.

The VM Scale Set appears in the UI with Optimization Type of "Just Right", until the required data has been collected.

See Reviewing Cloud Recommendations for details.

Contact [email protected] for details on tagging your VM Scale Set instances to enable the feature, relearning workload patterns.

• Viewing VM Scale Set Analysis Results—The following changes and additions have been made to view the analysis results in the Densify Console:
• The Optimization Overview page has been updated to add VM Scale Sets to the Microsoft Azure section of the Total No. of Services block. See Viewing the Optimization Overview Report
• A new VM Scale Set tab has been added to the Public Cloud Optimization for Azure page.
• VM Scale Sets configured with maximum group size = 1 are only included in the Virtual Machine tab in the optimization opportunity report.
• VM Scale Sets configured with maximum group size > 1 are included in the VM Scale Sets tab's optimization opportunity report.

See Working with Virtual Machine Scale Sets.

• In this release, the Catalog Map, the Metrics Viewer and the Impact Analysis and Recommendation Report are not available for VM Scale Set. See Table: Feature Support for VM Scale Set  for details.

The following updates have been made to the ASG Instance Optimization Details dashboard:

• The CPU and memory details for both current and recommended instance types have been added to the ASG Instance Optimization Details dashboard. The following columns are hidden by default and can be enabled for viewing. See Reviewing the ASG Optimization Opportunity Report Columns.

Current CPU Recommended CPU Current CPU Benchmark

Current Memory Recommended Memory Current Memory Benchmark

These same columns are included on the VM Scale Set Optimization Details dashboard. See Working with Virtual Machine Scale Sets for details.

• The option to review details of ASG in-service instance has been deprecated in this release. The In Service Instance column has been removed from the ASG Instance Optimization Details dashboard. The Details drill down page was previously removed in v2.1.

The summary table for the catalog map has been expanded to show details of the rules that were used to determine the value of each instance type. See Using the Catalog Map for details.

The catalog map is not currently available for AWS ASGs, Azure VM Scale Sets or GCP cloud instances.

The following updates have been made to features in the Densify API:

• Support for Azure Virtual Machine Scale Sets—The Azure \results endpoint has been updated to return details of analyzed VM Scale Set.
• For VM Scale Sets with maximum size=1 returned fields are the same as other VMs, but with 'serviceType' set to "VM Scale set". i.e.
• All other returned elements are similar to those for a virtual machine service (i.e. min/max group size values are not returned).
• The Impact Analysis and Recommendation Report report is not currently available for VM Scale Sets with maximum size >1.
• In the Densify UI, these VM Scale Sets appear on the VM tab.
• ASG Scaling Policies—The AWS \results endpoint has been updated to return the "scalingPolicies" field in the API \results when analyzing ASGs with maximum size >1.  See Analysis: AWS Recommendations..
• Azure Region Details—The Azure \results endpoint has been updated to return the "region" field for all supported instance types, including VM Scale Set. 
• Webhook Updates—The /webhook/analysis resource has been updated to support AWS ASGs and Azure VMs including VM Scale Set. See Analysis: Webhook.
• For Terminate recommendations the \results endpoint for all cloud providers has been updated to show scalingPolicies = “Terminate”, instead of displaying “-“. The character, “-“ is still used in the Densify Console pages to indicate the scalingPolicies value when Optimization Type=Terminate'.

The guest filter has been updated to remove the "Approval Setting" filter. The "Owner" filter has been moved from the More Filters dropdown menu to replace the "Approval Setting".

VM Scale Set are now included in counts, depending on the filter settings on the pages, that support the guest filter and page context.

See Using the Guest Filter for details.

When determining the scaling policy for both ASGs and VM Scale Set the logic has been updated to consider changes to the minimum and maximum group size. See the following topics for details:

• Working with Auto Scaling Groups.
• Working with Virtual Machine Scale Sets.

The public cloud metadata catalogs have been updated to ensure Densify recommendations are based on the latest vendor pricing, features and instance availability across regions:

See 2.4.0 June 5, 2024 for the list of issues resolved in this release.

In addition to the current and optimal instance types, you can now select a third instance type, in the Catalog Map's summary table. Clicking on any tile on the grid shows its details and you can compare the selected instance type to the current and optimal instance types.

Use the mouse or arrow keys to select another tile or press Esc to cancel the selection of the third instance type. See Using the Catalog Map for details.

The catalog map is not currently available for AWS ASGs or GCP cloud instances.

The ECS pages used to review the details of your services have been deprecated from the Densify Console in this release:

• The ECS option has been removed from the Containers dropdown menu.
• The ECS Summary tab and Data tab have been removed.

ECS data is still collected and analyzed, if required. ECS recommendations will be generated and provided in the existing ECS analysis extract reports. Contact your Account Manager for details.

Additionally, ECS details, if available are used for Densify's ECS-aware, ASG analysis. See ECS Reference

The public cloud metadata catalogs have been updated to ensure Densify recommendations are based on the latest vendor pricing, features and instance availability across regions:

You now have the option to select "container_memory_working_set_bytes" in addition to "container_memory_usage_bytes" or "container_memory_rss" for container data collection. This new metric allows you to determine how aggressively you want to optimize your container memory allocations, when analyzing your Kubernetes environments.

The corresponding workload charts have been added to the Containers - Details Tab. See Optimizing Your Containers - Details Tab

These updates are currently available in the beta version of Container Data Forwarder v4.0.

Contact [email protected] for details on selecting memory utilization for your container data collection.

In this release Densify provides a new feature that allows you to analyze all available recommendation options. The catalog map provides a grid view of all possible instance types with a score that corresponds to how well your workload would fit on each instance type in the cloud provider's catalog. You can provide cost tolerance options to filter the content of the grid.

Access the catalog map from the following Instance Optimization Details pages:

The catalog map is not currently available for AWS ASGs or GCP cloud instances. See Using the Catalog Map for details.

The following changes have been made to the Densify API to expand the functionality of the catalog map:

• New Governance API Endpoint—The endpoint, /systems/<id>/analysis-details provides a list of suitable instance types for a specified workload, in addition to the optimal instance type.
• Spend and Effort Tolerance—Specify cost and effort limits to customize the list of possible targets to better suit your requirements.
• Additional Parameters for Governance API—Eight new properties are returned that provide details of each instance type: cpuModel, numCpus, memory, generation, catalogCost, predictedUptime, percentOptimalCost and effort Estimate.
• Strict Instance Type Naming Conventions—To support platform-specific automation tools, where strict naming conventions are required, when supplying an instance type, Azure's exact instance type naming convention is now maintained. Exact instance type names can be obtained using the /systems/<id>/analysis-details endpoint.

See Systems: Analysis Details.

After a configuration change is detected, recommended request and limit values for both CPU and memory will be populated with the current CPU and memory request and limit values.

In v2.0 when a container instance had any of its request or limit values changed, on the next day in the Densify UI you saw the Optimization Type set to "Just Right" and since the required data had not been accumulated, Densify showed no data available, on the Resource Utilization Metrics tab in the lower pane. See Relearning Workload Patterns and Optimizing Your Containers - Details Tab

With the addition of the catalog map, navigation to the Impact Analysis and Recommendation ReportImpact Analysis and Recommendation Report has been updated. The hyperlink in the Instance Optimization Details > System column now opens the new Analysis Details page.

Open the Impact Analysis and Recommendation Report using the new links in the lower pane of the Instance Optimization Details page. See the following topics:

• Reviewing Specific Instance Details.
• Understanding the Instance Optimization Details for RDS.
• Working with Auto Scaling Groups

Densify will no longer display reports for AWS Spot instances. Spot instances are no longer included in the aggregate report on the Optimization Overview dashboard and the following tabs and reports have been removed:

• Optimization Overview—The Spot Instance hyperlink has been removed.
• Public Cloud Optimization for AWS—The Spot Instance tab has been removed.
• The Spot Instance Optimization Details dashboard has been removed.

The option to review details of ASG in-service instance has been deprecated in this release:

• The hyperlink has been removed from the In Service Instance column. This column is hidden by default. You can enable it for display, as required.
• The ASG In Service Instance Details page has been removed.

The public cloud metadata catalogs have been updated to ensure Densify recommendations are based on the latest vendor pricing, features and instance availability across regions:

Densify discontinued support of all versions of Safari on December 31, 2023. See Browser Requirements for a list of supported browser versions.

See 2.1.0 February 7, 2024 for the list of resolved defects.

The new metrics viewer allows you to view various workload metrics, stored in Densify’s time series database, over a defined time period. You can be confident in implementing recommendations with instant access to the raw utilization data that feeds Densify’s analytics.

Access the metrics viewer from the following Instance Optimization Details:

See Using the Metrics Viewer for details.

The new software resource optimization analysis allows you to better match your application workloads to the optimal infrastructure based on the identified software components and the acceleration features of the target hardware. Once software on the source instance has been identified, Densify’s analysis now considers new rules, that understand what CPU acceleration features improve the performance of that software, when recommending the optimal instance type. The quality of the automated software identification is also considered when making the recommendation.

The public cloud metadata updates now include the catalog details that reflect the accelerator features on the latest instance type for all cloud providers.

See Understanding Software Resource Optimization. Contact [email protected] for details and to enable this feature.

In this release, this version of Densify 2022 is officially branded as Densify. Logos throughout the product and on the Densify website have been updated.

The public cloud metadata catalogs have been updated to ensure Densify recommendations are based on the latest vendor pricing and instance availability across regions:

The following changes have been made to the Densify Console user interface:

• The Profile and Settings dialog box has been updated to show the Densify version and version number. See Common UI Features for details.
• The Running Totals bar located at the top of the Instance Optimization Details pages has been updated with the label "Services" replacing, "Instances".
• In the lower pane of all the Instance Optimization Details pages, the tab "Resource Utilization Metric: Cloud" has been renamed to "Predicted Utilization".
• A new column, System ID, has been added to the Public Cloud Optimization for AWS Auto Scaling Group page. The column is hidden by default. See Working with Auto Scaling Groups
• The following changes have been made to the workload charts on both the Kubernetes and ECS Optimization Details pages:
• The label on the Y-axis now shows the units of measure only. The system's display name has been removed from the axis label to improve readability.
• The display name for container-specific workload charts have been updated for clarity.

Table: Container Workload Chart Names

Previous Chart Name	New Chart Name
Prometheus - Actual Memory Utilization	Actual Memory Utilization - Container Average
Prometheus - CPU Utilization in mCores	CPU Utilization in mCores - Container Average
Prometheus - Raw Disk Utilization	Disk I/O - Container Average
Prometheus - Raw Mem Utilization	Memory Utilization - Container Average

• The order in which the workload charts are displayed in the lower pane of the Kubernetes Container Optimization Details page has been updated as follows:

CPU Utilization in mCores CPU Utilization - Container Average Memory Utilization Memory Utilization - Container Average Restarts

In Service Instances Disk I/O Actual Memory Utilization Actual Memory Utilization - Container Average

See Reviewing the Predicted Utilization Charts

[CRB-53922] In v1.0.3 the feature, Relearning Workload Patterns After Instance Resizing was introduced. In this release the logic has been updated to display the date of the instance change more accurately.

Since loading of data always occurs after midnight, the attributes, "Instance Type Updated On" and "Container Configuration Updated On" will always be assigned and set one day after the actual instance change. In this release the value of the attributes will be set to the previous day's date (i.e. date - 1). See Relearning Workload Patterns

See 2.0.0 November 1, 2023 for the list of resolved defects.

To improve the identification of a container's parent node, the provider_id has been introduced as a third identification component. Currently, nodes are identified using cluster_name and node_name.

The provider_id is optional and will be used only if required. In Kubernetes clusters without aprovider_id, node identification will continue to rely on cluster_name and node_name, ensuring that node IDs remain unchanged.

Specifically, for EKS and OKE clusters, existing node IDs will change and as a result, node history will be lost since these nodes will receive new IDs.

The data forwarder's configmap.yaml file has been updated. The setting, node_group_list has been updated to add label_karpenter_sh_nodepool. When enabled, Karpenter NodeGroups are discovered and created in Densify.

See Resolved and Known Issues for the list of resolved defects.

The following container metrics are now collected:

• max_cpu_throttling_percent—The Linux kernel allocates "CPU periods" (default = 100 milliseconds) to both processes and containers. The percentage is the number of throttled periods out of the total number of 100-ms periods. This value is a percentage of periods that were throttled vs those that were requested. This provides a more accurate indication of resouce limitations.

For example if the pod was throttled for 8 seconds out of the 5 minutes, this would be 2.7%, but if the CPU was not actually requested for the full 5 minutes, then the 2.7% is not an accurate representation of the state of the container. If the pod was throttled for 8 seconds, and it's request was less that than the 300 seconds the throttled percentage is higher.

• avg_cpu_throttling_percent—Indicates the average percentage of the number of 100-ms periods that a container is throttled in terms of CPU usage.

The average and maximum values are collected since the container is likely aggegated. Metrics are aggregated at the highest level of the pod owner. For a deployment of one pod in one container the average and maximum will be the same. If it is a deployment of 10 pods then the average and maximum will not be the same.

• sum_cpu_throttling_seconds—Aggregates the total time during which throttling has been applied.
• Container Events—These are not metrics that are collected at 5-minute intervals, but are individual events and the time that the event occurred or was detected. In this version of the data forwarder "process exit" is now collected. The exit code and whether or not this is the main process (i.e. PID #1 using a true/false flag) of the container is collected and stored. In this version process exit will be false only when PID #1 exits with code 137 which corresponds to an OOM kill. In all other cases, process exit will be true.

CPU and memory request and limit values at the top of the hour are already collected and stored as attributes, once per day. In this release the data forwarder collects the following metrics at 5-minute intervals:

• CPU Limit—The defined CPU allocation limit for the container.
• Memory Limit—The defined memory allocation limit for the container.
• CPU Request—The defined CPU allocation requested for the container.
• Memory Request—The defined memory allocation requested for the container.

You must have Densify v2.5, to see these new metrics in the Container Details report and metrics viewer. See Optimizing Your Containers - Details Tab and Using the Metrics Viewer for Containers.

Densify currently sets configuration attributes with both the node-level and container-level CPU, memory request and limit values from the top of the hour. This provides a point in time data point that allows you to see how a node’s request and limit values move during the day.

In this release the data forwarder collects the following metrics at 5-minute intervals:

• CPU Limit)—The defined CPU allocation limit for the node.
• Memory Limit—The defined memory allocation limit for the node.
• CPU Request—The defined CPU allocation requested for the node.
• Memory Request—The defined memory allocation requested for the node.
• Pod Count—The number of pods running on the selected node.

If values have not been specified this will be indicated.

The following node events are collected at 5-minute intervals:

• oom_kill_events—The number of kill events that happened on the node in a 5-minute interval;
• cpu_throttling_events—The number of CPU throttling events that happened on the node in a 5-minute interval;

The following metrics are calculated from the raw data:

• cpu_reservation_percent—The percentage of the node's total CPU resources that are reserved or guaranteed for workloads, containers, or virtual machines.
• memory_reservation_percent—The percentage of the node's total memory resources that are reserved or guaranteed for workloads, containers, or virtual machines.

The following configuration details are now collected and stored in attributes:

• provider_ID—The provider_id is available as a Prometheus label of kube_node_info metric which is extracted to its own column in the k8s_node_v0 postgres table. The relevant node data is then used to facilitate link the Kubernetes node to a cloud instance. This linking will be done in postgres, as will the determination of the relationship between cloud instance and ASGs or VM Scale Sets.
• k8s_version—The Kubernetes version of the node is collected and stored in the attribute, k8s_node.

This value is collected for each node and for the cluster. This is currently informational only and is not used not used in the analysis.

The features allowing you to view node details will be provided in Densify v2.6.

The Kubernetes version of the cluster is collected and stored in the attribute, k8s_cluster. This is the version of the control plane/API server. It can be higher than those of the nodes in cases where the control plane was upgraded and the nodes have not yet been updated. This is used when determining OOM kills for Kubernetes versions older than 1.28.

Containers will now be linked to their node group using a provider ID that is populated by each public cloud provider's Kubernetes offerings (i.e. EKS, AKS and GKE). The provider_id attribute is passed to the kubelet.

The provider_id is available as a Prometheus label of kube_node_info metric which is extracted to its own column in the k8s_node_v0 postgres table. The relevant node data is then used to facilitate linking the Kubernetes node to a cloud instance. This will be done in postgres, as will the relationship between cloud instance and ASGs or VM Scale Sets.

See 4.1.0 - September 19, 2024 for the list of resolved defects.

In addition to Prometheus, third party observability platforms are supported. Commercially-available observability platforms do not need to reside within a cluster and can be used to monitor multi-cluster environments. The observability platform must support the Prometheus API and one of the following authentication mechanisms:

• HTTP basic authentication—Supported by Prometheus and is required by some commercial observability platforms, i.e. Grafana Cloud;
• Bearer token—Required by OpenShift Monitoring and some commercial observability platforms, i.e. Azure Monitor;
• AWS SigV4—Required by Amazon Managed Service for Prometheus.

If you are using Amazon Managed Service for Prometheus (AMP), an AWS role is required to associate the Kubernetes service account with Densify for the purpose of container data collection. The additional required annotations can be added to your Helm charts.

The following Prometheus dependencies are applicable:

• AWS Managed Prometheus data ingestion requires Prometheus v2.26.0 or higher.
• Starting with version 16.0, the Prometheus chart requires Helm 3.7 or higher, to install successfully.

The following commercial observability platforms are supported:

• Amazon Managed Service for Prometheus (AMP)—Refer to the AWS website for details on AMP. Densify requires a specially configured role. See Container Data Collection Using Amazon Managed Prometheus for configuration examples.
• Azure Monitor Managed Service for Prometheus (AzMP)—Refer to the Azure website for details.Densify automates the process of acquring and get and refreshing secruity tokens. See Container Data Collection Using Azure Managed Service for Prometheus for a configuration example.
• Grafana Cloud—See Container Data Collection using Basic Authentication for a configuration example.

The following self-hosted OSS solutions are supported:

Version 4 collects data from external Prometheus servers. In this use case Prometheus runs outside the Kubernetes cluster, in which the data collection runs.

Since Prometheus can now be run externally, you can now run a single job to collect data for multiple Kubernetes clusters from a single Prometheus server/observability platform. Using Prometheus labels, the job determines which data belongs to which cluster.

You now have the option to select "container_memory_working_set_bytes" in addition to "container_memory_usage_bytes" or "container_memory_rss" for container data collection. This new metric allows you to determine how aggressively you want to optimize your container memory allocations, when analyzing your Kubernetes environments.

Using the metrics, "container_memory_rss" and "container_memory_working_set_bytes" provides more aggressive recommendations that allow you to reclaim more memory. Using "container_memory_usage_bytes" and "container_memory_rss" provide recommendations that will not result in downsizing recommendations that may lead to out-of-memory (OOM) issues.

The corresponding workload charts were added to the Containers - Details Tab in v2.2.0. See Optimizing Your Containers - Details Tab

Contact [email protected] for details on selecting memory utilization for your container data collection.

The following updates and bug fixes were made in this release:

• HTTP retries have been added to the calls to the Prometheus API. This handles observability platform rate limiting.
• The data forwarder now handles the relabel configs of Node Exporter.
• Outdated Node Exporter metrics have been addressed.
• Utilizes improved Horizontal Pod Autoscaler metrics (autoscaling v2).
• The data forwarder has been upgraded to Go 1.22,
• Updated examples for both single and multiple cluster configurations are provided in the new [Github repository].

See 4.0.0 - May 28, 2024 for the list of resolved defects.

Densify will discontinue support of Container Data Forwarder versions 3.x.x on June 30, 2024. Contact [email protected] for details on migrating to Densify's current version of the Container Data Forwarder.