Operations | Monitoring | ITSM | DevOps | Cloud

We are back with a simplified configuration for another critical open-source component, Zookeeper. Monitoring Zookeeper applications helps to ensure that the data sets are distributed as expected across the cluster. Although Zookeeper is considered to be very resilient to network mishaps, monitoring is inevitable. To do so, we’ll set up monitoring using the Zookeeper receiver from OpenTelemetry.

We’re excited to announce that we’ve recently added Varnish monitoring support for Google Cloud Platform. You can check it out here! Below are steps to get up and running quickly with observIQ’s Google Cloud Platform integrations, and monitor metrics and logs from Varnish in your Google Cloud Platform.

We are constantly working on contributing monitoring support for various sources, the latest in that line is support for Cassandra monitoring using the OpenTelemetry collector. 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.

We are constantly working on contributing monitoring support for various sources, the latest in that line is support for Tomcat monitoring using the JMX Receiver in the OpenTelemetry collector. If you are as excited as we are, take a look at the details of this support in OpenTelemetry’s repo. You can utilize this receiver in conjunction with any OTel collector: including the OpenTelemetry Collector and observIQ’s distribution of the collector.

In this post, we will address the common monitoring use case of filtering metrics within the observIQ OpenTelemetry (OTEL) collector. Whether the metrics are deemed unnecessary, or they are filtered for security concerns, the process is fairly straightforward. For our sample environment, we will use MySQL on Red Hat Enterprise Linux 8. The destination exporter will be to Google Cloud Operations, but the process is exporter agnostic.

We’re pleased to announce the beta release of BindPlane OP (Observability Pipeline), the first open source observability pipeline built specifically for OpenTelemetry. When we launched BindPlane in 2018, we set out to build a best-in-class observability management platform.

Some popular monitoring tools in the market can complicate and create blind spots in your Elasticsearch monitoring. That’s why we made monitoring Elasticsearch simple, straightforward and actionable. Read along as we dive into the steps to monitor Elasticsearch using observIQ’s distribution of the OpenTelemetry collector. To monitor Elasticsearch we will configure two OpenTelemetry receivers, the elasticsearch receiver and the JVM receiver.

We’re excited to announce that we’ve recently contributed Active Directory Domain Services (abbreviated Active Directory DS) monitoring support to the OpenTelemetry collector. You can check it out here! You can utilize this receiver in conjunction with any OTel collector: including the contrib collector, the observIQ’s distribution of the collector, as well as Google’s Ops Agent, as a few examples.

MongoDB is a document-oriented and cross-platform database that maintains its documents in the binary encoded JSON format. Mongo’s replication capabilities and horizontal capability using sharding make MongoDB highly available. An effective monitoring solution can make it easier for you to identify issues with MongoDB such as resource availability, execution slowdowns, and scalability. observIQ recently built and contributed a MongoDB metric receiver to the OpenTelemetry contrib repo.