Operations | Monitoring | ITSM | DevOps | Cloud

This article was originally published in The New Stack and is reposted here with permission. They require different approaches for storage and querying, making it a challenge to use a single solution. But InfluxDB is working to consolidate them into one. Time series data has unique characteristics that distinguish it from other types of data. But even within the scope of time series data, there are different types of data that require different workloads.

Here at InfluxData, we recently announced InfluxDB 3.0, which expands the number of use cases that are feasible with InfluxDB. One of the primary benefits of the new storage engine that powers InfluxDB 3.0 is its ability to store traces, metrics, events, and logs in a single database. Each of these types of time series data has unique workloads, which leaves some unanswered questions. For example: Luckily this is where our work within OpenTelemetry comes into play.

To get visibility into highly distributed applications, organizations often use various tracing tools that are best suited to each individual service owner’s specifications. However, when a request travels between services that have been instrumented with different tools, the trace data may be formatted differently, resulting in broken traces.

Parsing logs with regex is a valuable technique for extracting essential information from large volumes of log data. By employing this method, one can effectively identify patterns, errors, and other key insights, ultimately streamlining log analysis and enhancing system performance.

Grafana Tempo 2.1 is out and comes with a host of TraceQL improvements. Tempo 2.1 comes with some nice incremental improvements to TraceQL and likely some breaking changes. There’s a section down below about those, too.

As the amount of telemetry being collected continues to grow exponentially, businesses are continuously seeking cost-effective ways to monitor and analyze their systems. Data collection and monitoring can be expensive, especially when dealing with large volumes of logs. One approach to maintaining visibility while reducing the amount of data collected is through creating log-based metrics.

OpenTelemetry is enabling a revolution in how Observability data is collected and transmitted. See our What Is OpenTelemetry post on why this is an important inflection point in the Observability space. In this post, we’ll walk through how to configure the OpenTelemetry Gems within a Rails app.

OpenTelemetry was launched in May 2019, as a merger of the OpenCensus and OpenTracing projects. The open-source, vendor-neutral project resides within the Cloud Native Computing Foundation (CNCF), which virtually ensures its longevity and widespread adoption. In fact, OpenTelemetry has gained significant traction in recent years, with support from many major cloud providers and the tech industry.