A new version of Loki was released back in November, and I’m here to talk about one of its most exciting features. Loki 2.4 finally removed the requirement that all data must be ingested in timestamp-ascending order. Instead, Loki now allows out of order logs up to a configurable validity window (more to come on that). In this post, I’ll walk through what all this means and why we’re thrilled about it.

Back in May, we announced the Kubernetes integration to help users easily monitor and alert on core Kubernetes cluster metrics using the Grafana Agent, our lightweight observability data collector optimized for sending metric, log, and trace data to Grafana Cloud. The integration allows Grafana Cloud users to monitor and alert on Kubernetes cluster metrics. Since the original release, we’ve added new features and enhancements to help our users go even further.

Grafana 8.3 is here! This is an exciting release for Grafana Labs. This release includes the new Candlestick panel, a new visualization suggestions engine, support for AWS Metrics Insights and, for our Grafana Enterprise users, recorded queries. Get 8.3 You can get started with Grafana in minutes with Grafana Cloud. Here’s a closer look at the important new features in 8.3.

Performance testing is an essential component of building fast and reliable web services. Until recently, this testing typically happened later in the development process and was often performed by a separate team or even a third party. But speed is the competitive advantage for companies, and prioritizing testing during the development process can speed time to market for new applications.

When you’re a sports betting technology company and you realize your in-house, on-prem Graphite solution for monitoring metrics is no longer a sure-thing, what do you do? That was the dilemma at Kambi, a quickly growing business – with a passion for using open source technology – that has about 500 different micro services in production and around 200,000 incoming metrics messages per second.

While there is a lot of focus on the three pillars of observability to provide insight into application performance in production, load testing is the other side of the observability story. By using the open source load testing tool k6 — which Grafana Labs acquired earlier this year — developers can simulate real-world traffic to test the reliability and performance of software changes and new features, not to mention flag performance issues before impacting end users.

As the number of connected gadgets in our homes, offices, and industrial networks continues to grow exponentially, keeping IoT devices secure has become a vital part of our everyday lives. However, our webcams, printers, and smart plugs often lack security features due to their fast time to market, making them particularly vulnerable to attack. And because security metrics themselves can be tricky to assess, tracking IoT device security is increasingly a challenge.

It’s one thing to set up an observability strategy. But what’s it like to introduce and scale observability effectively across an organization? In a wide-ranging conversation at ObservabilityCON 2021, three technical pros from Snyk, TripAdvisor, and Citibank joined Grafana Labs VP Global Solutions Engineering Steve Mayzak and — with more than 75 years experience between them — they shared the triumphs and turbulence in their respective observability journeys.

Back in May, we announced the Kubernetes integration to help users easily monitor and alert on core Kubernetes cluster metrics using the Grafana Agent, our lightweight observability data collector optimized for sending metric, log, and trace data to Grafana Cloud. Since then, we’ve made some improvements to help our customers go even further.

With the recent release of Loki 2.4 and Grafana Enterprise Logs 1.2, we’re excited to introduce a new deployment architecture. Previously, if you wanted to scale a Loki installation, your options were: 1) run multiple instances of a single binary (not recommended!), or 2) run Loki as microservices. The first option was easy, but it led to brittle environments where a heavy query load could take down data ingestion and problems were often difficult to debug.