Operations | Monitoring | ITSM | DevOps | Cloud

One of the most powerful features of Grafana is the ability to unify and derive value from your data, regardless of where that data lives. This is because we’re fully committed to making Grafana an open, composable, and extensible observability platform for our more than 20 million users worldwide. But how exactly do we deliver on that promise of openness and extensibility? Grafana data source plugins play a big role.

Are you using the Azure metrics exporter to ship telemetry data to Grafana Cloud? Are you overwhelmed with the amount of configuration and complexity necessary to avoid being rate limited? Well, did you know that with Grafana Alloy, our distribution of the OpenTelemetry Collector with built-in Prometheus pipelines and support for metrics, logs, traces, and profiles, you can now: Let’s look at how these two features can reduce the complexity of your Alloy configuration.

AWS is an essential part of many organizations’ tech stacks today, which is why we continue to make it easier to observe your environment in Grafana Cloud. We recently launched AWS Observability, a fully managed application for visualizing and alerting on dozens of AWS offerings. And with our latest update, we’re making it cheaper and simpler to ingest and query your AWS logs.

At Grafana Labs, we’re committed to helping teams dramatically improve how they manage and respond to incidents. Through Grafana Incident Response & Management (IRM), we provide tools to empower teams, streamline processes, and enhance the effectiveness of incident management strategies—and we’re constantly looking for ways to make our solution even better.

Recently, an incorrect security report was published, claiming that there’s a SQL injection attack in Grafana. As we have communicated to the security researcher, this report is wrong. Authenticated users in Grafana have the same permissions as the user configured for the underlying data source.

Editor’s note: This blog post is the second in a series of posts about organizing your performance testing suite with Grafana k6. If you haven’t already, be sure to check out the first post in the series, which explores how to implement reusable test patterns and other best practices within your testing suite.

Here at Grafana Labs, we have a long-standing commitment to helping our users understand how their applications and services behave from an external point of view. This critical practice — known as synthetic monitoring — has been a key focus of ours for nearly a decade. Back in 2015, we released worldPing, our first product to help measure the user experience and improve website performance.

In 2017, we open sourced Grafana k6 and made its first beta available to everyone. This wasn’t our first rodeo — k6 marked the third load testing tool our team had developed over a decade. We had recognized the gaps in existing solutions, as well as the barriers that were hindering adoption in the developer community. The plan was simple yet ambitious: let’s build a tool developers actually enjoy using and that helps engineering teams build more reliable software.

Sometimes, the little things can make a big difference. We’ve added a new feature in Grafana Incident & Response Management (IRM) that lets you sync your Google Calendar out-of-office events with Grafana OnCall.

When deploying an application using Kubernetes, you get used to all your resources being manageable by describing them to the Kubernetes API. Whether it’s deployments, secrets, configurations, or entire machines, everything exists as code somewhere. Introducing a cloud service into such an environment often means introducing additional ways to configure it, which can become cumbersome, given the rising number of cloud services modern applications depend on.