Hi, I’m Owen, one of the Loki maintainers, and I’m putting proverbial pen to paper to convince you why Loki is important. And this isn’t because it scales (it does) or because I work at Grafana Labs (I do). It’s because of the oft-overlooked and underrepresented organizational benefits. Organizational benefits?! What is this, some sort of cult? Why are you avoiding the technicals? Whoa, whoa, whoa. Now, hold on. The technicals are still valid.

Hi, everyone! In honor of bingeing every season of Community over the last few weeks, Eldin and Christine have been inspired to rebrand ourselves as none other than our other favorite dynamic duo, Troy and Abed! Yet, instead of singing “Troy and Abed in the morning,” we are back to write about some useful improvements we’ve made to our Enterprise Dynatrace plugin.

A few weeks ago, I teamed up with Bartek Plotka, a principal software engineer at Red Hat, for a deep-dive session on Prometheus at KubeCon + CloudNativeCon EU. We covered a lot of topics, with highlights that included scaling Prometheus, remote-write and metadata. We ended the talk with a quick demo on how to import data from CSV files into Prometheus. I want to use this blog post to provide more insight into the state of backfill in Prometheus.

Before Prometheus, the closest thing to a common standard for metrics was Simple Network Management Protocol (SNMP), the internet standard protocol for collecting and organizing information and monitoring networks. Front and center in SNMP is ASN1, which lacks modern design and comes with trade-offs that made sense in the past but not so much today. Aside from that, many of the existing protocols were chatty and slow as well as proprietary, very hard to implement, or both.

A few months ago, I wrote an in-depth article describing how labels work in Loki. Here, I’m consolidating that information into a more digestible “cheat sheet.” There are some big differences in how Loki works compared to other logging systems which require a different way of thinking. This is my attempt to convey those differences as well as map out our thought process behind them. As a Loki user or operator, your goal should be to use the fewest labels possible to store your logs.

One thing we believe at Grafana Labs is that your data should be presented in a way that makes sense to you. Since the release of Grafana v7.0, we’ve seen a lot more developers taking advantage of the new plugins platform, which helps them build high-quality custom plugins faster than ever.

Every Grafana user is a dashboard designer. The Grafana community gladly shares their dashboards, so there’s tons of inspiration available. Chances are you’ve downloaded some community dashboards and tweaked them in search of patterns that work for you. But if you haven’t found them, you’re not alone! In my Aug. 27 webinar, “A beginner’s guide to dashboard design,” I’ll cover the basics of good dashboard design.

It’s only four months ago that I blogged about histograms in Prometheus. Back then, I teased my talk planned for (virtual) KubeCon Europe 2020. On Aug. 20, the talk finally happened. It completed the trilogy of histogram talks also mentioned in my previous blog post. Here is the recommended viewing order.

I’m pleased to report that today, the Cortex project advanced from sandbox to incubation within the Cloud Native Computing Foundation after a vote from CNCF’s Technical Oversight Committee (TOC). The TOC’s decision is a signal that Cortex has stepped up in maturity, attracting not just innovators but also early adopters among enterprises. To achieve incubation, CNCF projects undergo due diligence and have to demonstrate a healthy level of adoption and community activity.

Yesterday at KubeCon + CloudNativeCon EU, Grafana Labs software engineer Marco Pracucci, a Cortex and Thanos maintainer, teamed up with Thor Hansen, a software engineer at Hashicorp, to give a presentation called “Scaling Prometheus: How we got some Thanos into Cortex.” In their talk, the pair discussed a new storage engine they have built into Cortex, how it can reduce the Cortex operational cost without compromising scalability and performance, and lessons learned from running Cortex at s