Today, we are excited to announce that the MySQL integration has received an important update, which includes a new pre-built MySQL logs dashboard and the Grafana Agent configuration to view and collect MySQL server logs. The integration is already available in Grafana Cloud, our platform that brings together all your metrics, logs, and traces with Grafana for full-stack observability.
Today, we are thrilled to share that the macOS integration has finally arrived for Grafana Cloud! Thanks to the joint efforts of Grafana Labs’ multiple teams, you can monitor your Mac and gather and visualize metrics and logs with ease. The integration is available in Grafana Cloud, our platform that brings together all your metrics, logs, and traces with Grafana for full-stack observability.
The new Sqlyze data source plugin (in beta) allows you to connect your Grafana instance to all your favorite SQL databases, many NoSQL databases, and many other non-SQL data sources — from document databases, to ERP systems, to even Slack. You don’t have to know the native query syntax for these data sources; you can just use SQL. The Sqlyze plugin uses ODBC at its core. Hundreds of ODBC drivers are available for various databases/data sources.
We are pleased to announce that an upgraded version of the Linux Node integration is available in Grafana Cloud, including the capability to visualize logs that are correlated with previously existing metrics. It also includes a new pre-configured dashboard based on the USE method, which focuses on showing resources utilization, saturation, and errors.
What’s the saddest log line in the multiverse? A log line without context. That’s according to Grafana Labs software engineer and Grafana Loki tech lead Ed Welch, who joined Grafana Labs VP of Culture Matt Toback and Engineering Director Mat Ryer for the latest episode of “Grafana’s Big Tent," our new podcast about people, community, tech, and tools around observability.
Over the past year, Grafana Labs has grown from 300 to 700 Grafanistas. Moving forward, we expect to continue to maintain a high rate of change, and to sustain that, we need to ensure there is flexibility in how our teams* are set up. The majority of our Engineering squads have changed in size and structure — and the same goes for the Grafana Observability team, where I work.
For this edition of my ongoing Grafana Loki how-to series, I wanted to offer up some helpful — and perhaps surprising — facts about using LogQL, Loki’s query language. In case you’re new to Grafana Loki, it’s a log aggregation system created in 2018, and the Loki team has worked with the community ever since to introduce new features and make it easier to deploy.
Greetings friends, one and all! Over here on the Field Engineering team, we’re often asked about tracing. Two questions that come up frequently: Do I need to sample my traces? and How do I sample my traces? The folks asking are usually using tracing stores where it’s simply not possible to store all of the traces being generated. Those are great questions and the answers depend on a few different factors.
OpenTelemetry is a set of APIs, SDKs, tooling, and integrations that are designed for the creation and management of telemetry data such as traces, metrics, and logs. One of the main components of OpenTelemetry, or OTel for short, is the OpenTelemetry Collector. The OpenTelemetry Collector, or Otel Collector, is a vendor-agnostic proxy that can receive, process, and export telemetry data.
The recent release of Grafana 8.5 marks the start of enabling the jump from traces directly to Splunk logs. It’s a big leap that now allows you to draw a straight line between your traces — whether they are coming from Tempo, Zipkin, or Jaeger — to even more third-party logging data, all from the comfort of your traces view. Previously, the Grafana trace to logs enablement included only Loki logs.
