You can now monitor Jetty for free using top of the line open source monitoring tools in OpenTelemetry. If you are as excited as we are, take a look at the details of this support in OpenTelemetry’s repo. The best part is that this receiver works with any OpenTelemetry collector: including the OpenTelemetry Collector and observIQ’s distribution of the collector. Jetty uses the JMX receiver.

In this part 1 of a blog series on serverless monitoring, we will learn how to run the observIQ Distro For OpenTelemetry Collector, referred to as “oiq-otel-collector”, in Google Cloud Run. There are many reasons that someone may want to run monitoring in a serverless state. In our example, we will be monitoring MongoDB Atlas, a cloud hosted version of MongoDB.

Observability is a mindset that lets you use data to answer questions about business processes. In short, collecting as much data as possible from the components of your business — including applications and key business metrics — then using an AI-powered tool to help consolidate and make sense of this huge volume of data gives you observability into your business. Having observability for your business and applications lets you make smarter decisions, faster.

Log tracking, trace log, or logging traces… Although these three terms are easy to interchange (the wordplay certainly doesn’t help!), compare tracing vs. logging, and you’ll find they are quite distinct. Logs, traces, and metrics are the three pillars of observability, and they all work together to measure application performance effectively. Let’s first understand what logging is.

With the introduction of container orchestration frameworks like Kubernetes, the adoption of cloud-native technologies, and the transition to microservices architectures, engineering organizations were empowered to build scalable and complex applications. DevOps engineers have had an indispensable role in this revolution, enabling and supporting these processes.

If you've stumbled (or purposefully landed) on this blog post, chances are you are new to—or diving deeper—into the observability space, o11y for short. Suffice it to say, you’re not in Kansas anymore. Honeycomb in a lot of ways can serve as a yellow brick road into o11y, and this article should serve as an introduction into how Honeycomb facilitates implementing o11y into applications and distributed services.

Tracing, or more specifically distributed tracing or distributed request tracing, is the ability to follow a request through a system, joining the dots between all the individual system calls required to service a particular request. Although tracing logs have been around for some time, the trend toward distributed architectures, microservices, and containerization has elevated it from nice-to-have status to an essential piece of the observability puzzle.

We are back with a simplified configuration for another critical open-source component, Hadoop. Monitoring Hadoop applications helps to ensure that the data sets are distributed as expected across the cluster. Although Hadoop is considered to be very resilient to network mishaps, monitoring Hadoop clusters is inevitable. Hadoop is monitored using the JMX receiver. The configuration detailed in this post uses observIQ’s distribution of the OpenTelemetry collector.

If you use Windows, you want to monitor Windows Events. With our latest contribution to the observIQ OpenTelemetry Collector, you can easily monitor Windows Events with OpenTelemetry. You can utilize this receiver in conjunction with any OTel collector: including the OpenTelemetry Collector and observIQ’s distribution of the collector. Below are steps to get up and running quickly with observIQ’s distribution, and shipping Windows Event logs to a popular backend: Google Cloud Ops.

Earlier this year Gartner published a report discussing OpenTelemetry and its place in enhancing Application Performance Monitoring (APM).