Operations | Monitoring | ITSM | DevOps | Cloud

Logz.io has pressed hard to align our tracing and metrics analytics capabilities over the past year. And as our technology advances, so does our service. We are announcing Multiple Tracing Accounts with Logz.io Distributed Tracing, aligning it with our logging and metrics tools. Complementing multiple data sources for metrics and logs, Logz users can segment their data according to sources and teams for better organization.

Since the OpenTelemetry Tracing Specification reached 1.0.0 — guaranteeing long-term stability for the tracing portion of the OpenTelemetry clients, the community has been busy working to get the SDKs and APIs for popular programming language ready to be GA. Next in our ‘Getting Started with OpenTelemetry’ Series, we’ll walk you through instrumenting a Python application and install both the OpenTelemetry API and SDK.

Exemplars are a hot topic in observability recently, and for good reason. Similarly to how Prometheus disrupted the cost structure of storing metrics at scale beginning in 2012 and for real in 2015, and how Grafana Loki disrupted the cost structure of storing logs at scale in 2018, exemplars are doing the same to traces. To understand why, let’s look at both the history of observability in the cloud native ecosystem, and what optimizations exemplars enable.

The current landscape of what our customers are dealing with in monitoring and observability can be a bit of a mess. For one thing, there are varying expectations and implementations when it comes to observability data. For another, most customers have to lean on a hodgepodge of tools that might blend open source and proprietary, require extensive onboarding as team members have to learn which tools are used for what, and have a steep learning curve in general.

Recently we announced in our blog post, "The OpenTelemetry Tracing Specification Reaches 1.0.0!," that OpenTelemetry tracing specifications reached v1.0.0 — offering long-term stability guarantees for the tracing portion of the OpenTelemetry clients. Today we’re excited to share that the first of the language-specific APIs and SDKs have reached v1.0.0 starting with OpenTelemetry Java and OpenTelemetry .NET.

Cloud-native and serverless come hand in hand. One of the initial motivations to move business workflows to the cloud was related to cutting costs related to provisioning infrastructure and elasticity that on-demand allocation of resources is offering.

Last year, we released native tracing for AWS Lambda through Datadog APM to provide deep visibility into serverless functions and surface performance issues such as cold starts and errors, without any added latency. But Lambda functions are only one piece of the puzzle in a rapidly growing serverless ecosystem, which includes message queues, data streams, notification services, and more.

It’s been almost a year since I shared some thoughts about distributed tracing adoption strategies on this blog. We have discussed how different approaches between log vendors and application performance management (APM) vendors exist in the market and how important that is to allow users to analyze the data, including custom telemetry, the way they want.