I’m excited to share that today, we’re making Helios available to all developers around the world for free. Helios is a developer platform that helps increase dev velocity and productivity when building cloud-native applications. Over the past few months we’ve worked closely with dozens of private beta users to build a product that we believe will make a difference.

In distributed application environments, to solve problems in code you need to be able to connect the dots between all the different places where your code runs, including frameworks like Databricks and Apache Airflow. The Databricks pipeline may be one of the most crucial places where your code runs, but the visibility you’re getting there is limited.

In this guide, we’ll set up an OpenTelemetry Collector that collects logs and sends them to Grafana Loki running in Grafana Cloud. We will consider two examples for sending logs to Loki via OpenTelemetry Collector. The first one shows how to collect container logs with a Fluent Forward receiver. The second one shows how to collect system logs with a Filelog receiver.

This article was published in The New Stack. For most developers, software development means there is an API for almost everything, hardware is provisioned via the cloud and the core focus is on building only the features most crucial to your business. Of course, all these integrations and modern distributed architectures create their own set of problems. Having full insight into your application has become even more important and is now commonly known as observability.

Testing today’s environments is more challenging than it was a few years ago. The transition to distributed environments has created complexity, overhead, and friction when writing and running new backend tests. These tests require a lot of preparation, infrastructure building, and maintenance since many services communicate asynchronously and they often miss exceptions that are thrown on the “deeper layer” of the system architecture and it’s hard to make it testable.

Monitoring and observability have increased with software applications moving from monolithic to distributed microservice architectures. While observability and application monitoring share similar definitions, they also have some differences. The purpose of both monitoring and observability is to find issues in an application. However, monitoring aims to capture already known issues and display them on a dashboard to understand their root cause and the time they occurred.

The scope of the OpenTelemetry project encompasses how telemetry data is collected, processed, and transmitted. The OpenTelemetry project is not involved with how the data is stored, displayed, or used beyond the collection and transmission phases. The OpenTelemetry Collector is an application written in Go.

For this post, we’ll use a small Flask app that allows users to input a city name and they receive the current weather information for that city. We’ll make an API call to openweathermap.org to get the weather information for the city.

Within the technology stack used by developers today you would be hard-pressed not to find products and features that save time. Time-saving tools are crucial for developers because we look for ways to deliver production-ready code faster to keep up with the demands of our users and customers. We want to be able to identify, reproduce, and fix issues – fast.

Snapshot of the content that AppDynamics’ OpenTelemetry experts, Erwan Paccard and Severin Neumann find valuable.

At Mezmo, we see a massive opportunity to reduce Mean Time to Detection (MTTD) and Mean Time to Resolution (MTTR) by making log data more valuable and actionable. Today, we’re thrilled to announce the release of the Mezmo Exporter for OpenTelemetry- the first step in our continued work with the project to further simplify the ingestion of log data and make that data more actionable with enrichment of key OpenTelemetry attributes.

Frontend technologies typically talk to several services in your backend, and those services talk to other services. At the root of every issue is a single event that causes a domino effect. A domino effect that impacts every operation from the first experience on the frontend to the backend API call. Sentry can show you how these exceptions and latency issues impact every one of your services. For example, take the ever common and seemingly simple to resolve 500 - Internal Server Error.