Monitoring and Observability (Enter Mezmo)
Tags: kubernetes, devops, programming, cloud
Published: 2024-05-29 20:11:14

Monitoring and observability have been around for years, it’s nothing new. However, one thing many engineers still have an issue with is implementing monitoring and observability the right way. Between various logs, traces, metrics, alerts, and overall data that’s consumed by application stacks, there’s a lot of data to be combed through and consumed.

In this blog post, you’ll learn about how to manage the capability with Mezmo.

## What Is Monitoring And Observability

The best way to think about the differentiation is:

- Monitoring: See the data
- Observability: Do something with the data

Monitoring is all about seeing data, alerting on data, and having the ability to view graphs. It’s the big screens in the NOC (if those still exist) and the graphs you see on various monitoring tools to see how application stacks and infrastructure is performing.

Observability on the other hand is doing something with the data. Whether it’s traces (app end-to-end health), logs (output from infrastructure or apps), or metrics (performance, workloads, etc.), engineers can take the data and perform action on it. For example, let’s say a log states that there’s a failure and it’s a known failure. An engineer can write some observability automation to kick off when the specific log comes into the monitoring and observability platform.

## Where Does Mezmo Fit In

Mezmo is enterprise-grade OTel (OpenTelemetry).

In the previous section, it was made clear that there are a lot of “endpoints” for monitoring and observability. Logs, traces, and metrics contain a lot of information. The problem is that because of all of that information, it’s hard to go through.

Instead, that data needs a central location to be stored and a central place where it can be sent from.

Mezmo gives you a one-stop-shop location to ingest all of the observability data and have it sent out to wherever it needs to go. Perhaps it’s a log aggregator or maybe it’s a SIEM solution. In any case, the observability data is consumed and put into one location to be used later by the tools that need to extract that data (SIEM, log aggregator, etc.) and perform an action on it.


![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/27ed4ue31z6ms6a16ciy.png)


Source: https://www.mezmo.com/

## Install And Configure Mezmo On Kubernetes

Now that you know the “how” and “why” behind monitoring and observability, let’s learn how to deploy Mezmo.

First, sign up for Mezmo (you can get started for free).

https://www.mezmo.com/sign-up-pipeline-today


![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/c0uo78bp36zq79ljfwet.png)


Next, use the OTel Helm Chart to install it on your Kubernetes cluster.


![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/j459k3fjqshw8tefg5z2.png)



Run the Helm Chart.


![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/1yk7j02j6ae54d1hin28.png)



You should now see the Helm Chart deployed.

```jsx
helm list -n mezmo
NAME                    NAMESPACE       REVISION        UPDATED                                 STATUS          CHART                           APP VERSION
mezmo-otel-collector    mezmo           1               2024-05-29 16:05:37.006154 -0400 EDT    deployed        opentelemetry-collector-0.92.0  0.101.0
```

Within the Mezmo UI (it’s SaaS-based so you don’t have to deploy any Kubernetes Services within your cluster) you should now see the Mezmo environment.


![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/pjhgb5o0sv9xeekcp7l5.png)