Operations | Monitoring | ITSM | DevOps | Cloud

Grafana v7.0 is coming soon! Here’s another sneak peek of one of its features: the inspect drawer. The inspect drawer is a feature that every panel will support, including internal as well as external community plugins. In this new drawer, you will be able to view the raw data in a table format, apply some predefined transformations, and download as CSV. “Download as CSV” previously only existed as a custom feature for the Graph & Table panel.

Many Grafana users export images of their dashboard panels. This feature powers the ability to receive alerts with a rendered image of the panel attached, which is valuable for quickly spotting if something is about to go sideways in production. Since Grafana v2.0, when support for server-side rendering of dashboard panels as images was introduced, PhantomJS has served as the built-in image renderer that enables this feature.

There are instances in life when isolation is actually welcome. One of those instances pertains to the I in the acronym ACID, which outlines the key properties necessary to maintain the integrity of transactions in a database. The time series database (TSDB) embedded in the Prometheus server has the C (consistency), the D (durability), and – somewhat debatable – the A (atomicity). But up until and including Prometheus v2.16, it did not have the I (isolation).

The Grafana and Metrictank/Graphite teams have been hard at work to deliver an exciting new feature for the upcoming Grafana v7.0 release: a rollup indicator and series lineage metadata breakdown for Metrictank. This blog will cover the new functionality around Metrictank metadata, the rollup indicator, and the lineage visualization coming in 7.0.

Grafana v7.0 is coming next month! Here’s a sneak peek of one of its features: the query history in Explore. Query history lets you view the history of your querying. All queries that have been starred in the Query history tab are displayed in the Starred tab. This allows you to access your favorite queries faster and to reuse these queries without typing them from scratch.

Since the beginning of the Cortex project, there was a flaw with the ingester service responsible for storing the incoming series data in memory for a while before writing it to a long-term storage backend. If any ingester happened to crash, it would lose all the data that it was holding.