As we continue adding to our growing catalog of more than 100 plugins for Grafana, we have been focused on developing data sources for Grafana that are more purpose-built for the respective technologies. One example has been the recent update to our core Prometheus data source. We have deprecated AWS authentication from the original Prometheus data source, and we created a new dedicated Amazon Managed Service for Prometheus plugin that will specifically cater to the AWS use case.

Grafana Alloy 1.3 is here! First introduced earlier this year, Alloy is our open source distribution of the OpenTelemetry Collector. It has native pipelines for OpenTelemetry and Prometheus telemetry formats, and it uses the same components, code, and concepts that were previously introduced in Grafana Agent Flow. This new release introduces live debugging, enhancing debugging capabilities across key components, which are the building blocks of Alloy.

Grafana began as an open and composable platform for data visualization. Today, Grafana has evolved into an all-in-one observability platform, providing everything from infrastructure and application performance monitoring to load testing and incident response. As organizations extend their use of Grafana, efficient and secure authentication and authorization is essential.

In the previous blog post in this two-part series, we discussed the critical signals you need to monitor in your Kubernetes environment to ensure optimal resource provisioning. These signals include high CPU and memory utilization, frequent pod evictions, slow application performance, and other indicators that your resources are over- or under-provisioned. Monitoring these signals is essential for maintaining an efficient, cost-effective, and environmentally sustainable Kubernetes environment.

Organizations that run Kubernetes clusters in cloud native environments should do so in a way that’s both operationally efficient and cost effective. However, many organizations don’t prioritize cost optimization until it becomes a pressing need. This may be due to a directive from senior leadership, a significant scale-up or migration of Kubernetes clusters, or an unexpected surge in the cloud bill.