You have always been able to use the Ternary API to generate and manage long-lived API keys for your automation use cases. We have heard that viewing and managing API keys at an organization level can be difficult without a global view. Today, we are happy to release an API key management feature inside the Ternary UI. You will find the new API Keys feature in Settings. 

You can create and delete any number of keys in your Ternary tenant. We still set a maximum key age to 90-days. We do allow you to create a shorter duration. When you create a new key, we give you the opportunity to copy the new key one time. We cannot recover the key. As always, we welcome your feedback!

We have some exciting changes coming to the Ternary Home page over the next couple of months. We want to provide you with more flexibility in building your own Home visualizations by surfacing data in reports and graphs that makes the most sense to you. You may have noticed a couple new updates to the Home page: We have renamed the Home graph (Cost Explorer) to Home Classic and introduced a new button to change your Home page to the new Home Enhanced experience.

Selecting the new Home Enhanced experience automatically displays a pre-built Default Dashboard.

You can toggle back to the Home Classic to compare the enhanced and classic experience. In future iterations, you will be able to select a dashboard you built as your default Home dashboard. We will eventually sunset the Classic Home experience, but want you to have plenty of time to experiment with the new Home Enhanced feature.

Without proper visibility, tracking and gaining deep insight into your cloud database cost and usage can be challenging particularly for organizations with dozens or hundreds of instances. Today, we are excited to take our first step in helping you achieve deeper insight into your GCP Cloud SQL costs across multiple cost (project, database engine, region) and usage (CPU, memory, storage and network) dimensions. Our Cloud SQL visibility also helps you quickly determine how well your Cloud SQL commitments are performing and wether it makes sense to cover any of your on-demand spend with new or additional commitments.

You can find the new Cloud SQL feature under Insights along with Compute, Kubernetes, and Storage. No action is required on your part to start using this feature today. If you have Cloud SQL usage, Ternary will automatically surface your cost and usage. 

Today, we are making it easier to quickly add filters to your reports simply by clicking the grouping within a report. In my simple report example, I grouped spend by category and service description without any filters.

Suppose I am interested in exploring spend associated with Compute Engine, I could manually add a filter to my report or, with this new enhancement, click Compute Engine in the Stacked Area graph. And now I have two new filter automatically added to my report. If I want to return to my original report, simply remove the filters. Also, with this enhancement, there is a new Stacked Area chart type, which I used in my examples. 

We love that customers are creating all sorts of interesting reports and dashboards using the Ternary Reporting Engine. Many reports are aligned by function (finance, technology, or product), by business line, or a vast collection of random reports to answer very specific discovery questions. Before today, finding a report in your report library was a bit, well, frustrating and time consuming. We heard you. Now, when you open a report, we have provided you with two search options: search by report name or search by creator. Just start typing in either box and Ternary will immediately start paring down the list. We hope you find this enhancement valuable and are able to answer questions faster.

We have heard it can be confusing when filtering optimization recommendations only to find what you thought should be in the results seems to have disappeared or is no longer in the state you had left the recommendation. We believe strongly that taking action, such as implementing a recommendation, and the outcomes of those actions should be easy to surface and share within your teams and across the organization. With today's enhancement, you can quickly filter by open and closed recommendations in combination with the status (new, accepted, implemented, etc). Now, if you wanted to know which recommendations are closed and implemented, you could generate a quick list and watch Ternary calculate the savings of implemented recommendations and celebrate the wins.

We wanted you to know we just released an enhancement to our Scoped Views feature that now allows you to create targeted Scoped Views for your Kubernetes (K8s) workloads. Building on our Kubernetes Container and Node label feature, you can now incorporate your rich labeling scheme in defining and deploying Scoped Views. Taking a look at a specific K8s Container Scoped View example, start by creating an organization or personal scoped view (Scoped Views feature) and selecting either Kube Container or Kube Nodes dataset and the container or node labels to include in your view.

In my simple K8s Scoped View, I added the container label podname.

I can now use my persistent K8s Container Scoped View in the Reporting Engine for both reports and dashboards to quickly visualize container resource metrics and costs associated with my podname.

Scoped Views for your K8s environment helps segment the data to quickly visualize and understand the behavior and costs associated with a defined collection of containers and nodes. Enjoy!

In case you missed it, we recently released an enhancement to Kubernetes reporting that will allow you to easily visualize cost and usage data across your Kubernetes environment. We heard from many of you this is critical to understanding and attributing opportunities for operational efficiency to your dev teams. Building a Kubernetes Pod label report in Ternary is quick and easy. After Ternary has ingested your Kubernetes Pod labels, you can build rich cost and usage reports in the Ternary Reporting Engine. You will first select 'Kubernetes Container' as your source data (Ternary only surfaces pod-level Kubernetes labels) and an appropriate metric. I selected 'requestCPUcost' as the metric in my sample report below. Now, with Kubernetes Pod labels, I can choose a Pod label to group and filter my report results. I chose 'my.k8s.pod-label/application' to group my results by an application ID value associated with my pods.

As you can see, there are many pod application labels in my report results. I may want to focus on a particular set of applications and apply a filter to my 'application' pod label. To begin ingesting your Kubernetes Pod labels, take a look at our setup guide. 

We all know the many benefits of cloud: flexibility, agility, fast experimentation, but with it comes complexity and headaches in making sense of the never ending stream of cost and usage data. Ternary's reporting engine reduces complexity allowing you to quickly build reports and dashboards across a collection of cost metrics, dimensions and filters. Even the best reports can surface a significant amount of results making the visualization busy and difficult to tease out the report's theme. Today, we are making it easier to quickly limit report results using common Top-N collections, in other words, show you the top 5 or 20 results and let you decide if you need to see more or all results. In the simple report below, the engine returned dozens of projects and, with it, a lot of noise.

Now, using the new Top-N dropdown, you can quickly filter the top 5 results to begin to understand what's happening with these projects. If you choose, show all results, then your filtered results are then easily exportable in the table returned below the graph. 

Today, we're excited to announce an extension of the Ternary Reporting Engine that now gives you the power to query the data sourced from your Kubernetes clusters in any way that you would like.

The data we're making available falls into two major categories:

Kubernetes Containers - CPU and Memory Request and Utilization Data from the applications and workloads you run inside your clusters. Think Pods, Deployments, ReplicaSets and DaemonSets. Use this to make sure your Kubernetes Containers are using what they're requesting and to motivate rightsizing at the application level.

Kubernetes Nodes - CPU and Memory Capacity and Utilization Data from the Nodes that make up your Kubernetes Clusters. Use this to make sure your Kubernetes Clusters are appropriately sized for the applications scheduled to them and to motivate rightsizing at the cluster level.

In each data source, cost, usage, and waste metrics are made available for you to analyze this from every perspective possible. Billing is the default data source to visualize all cloud usage and costs. To begin using Kubernetes Data in Reporting Engine, simply choose the Kubernetes Container or Kubernetes Node option in the new Data Source dropdown when creating a Report. 

Then, choose the appropriate filters, groupings and measures corresponding to what you'd like to discover. We allow you to filter and group on clusters and namespaces. Choose the measures you'd like to chart, such as cost or CPU/memory usage/wastage and you are done. In this example, I am interested in exploring container cores requested and the associated core cost for all projects (I may decide to add a filter to drill down on a few specific projects)

Save your report and add it to a dashboard and build a collection of Kubernetes reports.

You can view a complete list of our container and node metric definitions here. We hope that this feature helps you better understand your Kubernetes clusters and workloads.