DEV Community: Eden Federman

🎉Monitor your Javascript application like a pro🧙‍♂️💫

Eden Federman — Thu, 14 Dec 2023 12:42:56 +0000

TL;DR

In this tutorial, you will learn how to monitor your Javascript application with modern tools and best practices.

Explore the power of distributed tracing, and discover how to seamlessly integrate and utilize tools like Odigos and Jaeger to enhance your monitoring capabilities.

What you will learn: ✨

How to build microservices 🐜 in Javascript.
Setting up Docker containers 📦 for microservices.
Configuring Kubernetes ☸️ for managing microservices.
Integrating a tracing backend for visualizing the traces 🔍.

Are you ready to become a pro at monitoring your JS application? 😍 Say Yes, sir!.

I can't hear you. Say it louder. 🙉

Let's set it up 🦄

🚨 In this section of the blog, we'll be building a dummy JavaScript microservices application and deploying it on local Kubernetes. If you already have one and are following along, feel free to skip this part.

Create the initial folder structure for your application as shown below. 👇🏻

mkdir microservices-demo
cd microservices-demo
mkdir src
cd src

Setting up the Server 🖥️

👀 For demonstration purposes, I will create two microservices that will communicate with each other, and eventually, we can use that to visualize distributed tracing.

Build and Dockerize Microservice 1

Inside the /src folder, create a new folder /microservice-1. Inside the folder initialize a NodeJS project and install the required dependencies.

mkdir microservice-1
cd microservice-1
npm init -y
npm install --save express node-fetch

Create a new file index.js and add the following code:

// 👇🏻/src/microservice-1/index.js
const express = require("express");
const fetch   = require("node-fetch")

const app = express();
const PORT = 3001;

app.use(express.json());

app.get("/", async (req, res) => {
  try {
    const response = await fetch("http://microservice2:8081/api/data");
    const data = await response.json();
    res.json({
      data: "Microservice 2 data received in Microservice 1",
      microservice2Data: data,
    });
  } catch (error) {
    console.error(error.message);
    res.status(500).json({ error: "Internal Server Error" });
  }
});

app.listen(PORT, () => {
  console.log(`Microservice 1 listening on port ${PORT}`);
});

💡 If you've noticed, we're requesting data from http://microservice2:8081/api/data. You might be wondering, what is this microservice2? Well, we can use service names as host names. 😉 We will build this service later.

The server is listening on port 3001 and on get request to / we are requesting data from microservice2 and returning the response as a JSON object. 📦

Now, it's time to dockerize this microservice. Create a new Dockerfile inside the /microservice-1 folder and add the following code:

// 👇🏻/src/microservice-1/Dockerfile
FROM node:18

# Use /usr/src/app as the working directory
WORKDIR /usr/src/app

# Copy package files and install production dependencies
COPY --chown=node:node package*.json /usr/src/app
RUN npm install --production

# Copy the rest of the files
COPY --chown=node:node . /usr/src/app/

# Switch to the user node with limited permissions
USER node

# Expose the application port
EXPOSE 3001

# Set the default command to run the application
CMD ["node", "index.js"]

It is always nice to add files to .dockerignore that we do not want to push to the container. Create a .dockerignore file with the names of the files we don't want to push.

// 👇🏻/src/microservice-1/.dockerignore
node_modules
Dockerfile

Finally, build 🏗️ the docker image by running the following command:

docker build -t microservice1-image:latest .

Now, that is the entire setup for our first microservice. ✨

Build and Dockerize Microservice 2

We will have a setup similar to microservice1, with just a few changes here and there.

Inside the /src folder, create a new folder /microservice-2. Inside the folder, initialize a NodeJS project and install the required dependencies.

mkdir microservice-2
cd microservice-2
npm init -y
npm install --save express node-fetch

Create a new file index.js and add the following code:

// 👇🏻/src/microservice-2/index.js
const express = require("express");
const fetch   = require("node-fetch")

const app = express();
const PORT = 3002;

app.use(express.json());

app.get("/api/data", async (req, res) => {
  const url = "https://jsonplaceholder.typicode.com/users";

  try {
    const response = await fetch(url);
    const data = await response.json();
    res.json(data);
  } catch (error) {
    console.error(error.message);
    res.status(500).json({ error: "Internal Server Error" });
  }
});

app.listen(PORT, () => {
  console.log(`Microservice 2 listening on port ${PORT}`);
});

The server is listening on port 3002, and upon a GET request to /api/data, we fetch data from jsonplaceholder and return the response as a JSON object. 📦

Now, it's time to dockerize this microservice as well. Copy and paste the entire Dockerfile content for microservice1 and just change the port from 3001 to 3002.

Also, add a .dockerignore file and include the same files that we added when creating microservice1.

Finally, build 🏗️ the Docker image by running the following command:

docker build -t microservice2-image:latest .

Now, that is the entire setup for our second microservice as well. ✨

Setting up Kubernetes

Make sure Minikube is installed, or follow this link for installation instructions. 👀

Create a new local Kubernetes cluster, by running the following command. We will need it when setting up Odigos and Jaeger.

Start Minikube: 🚀

minikube start

Now that we have both of our microservices ready and dockerized, it's time to set up Kubernetes for managing these services.

At the root of the project, create a new folder /k8s/manifests. Inside this folder, we will add deployment and service configurations for both of our microservices.

Deployment Configuration 📜: For actually deploying the containers on the Kubernetes Cluster.

Service Configuration 📄: To expose the pods to both within the cluster and outside the cluster.

First, let's create the manifest for the microservice1. Create a new file microservice1-deployment-service.yaml and add the following content:

// 👇🏻/k8s/manifests/microservice1-deployment-service.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: microservice1
spec:
  selector:
    matchLabels:
      app: microservice1
  template:
    metadata:
      labels:
        app: microservice1
    spec:
      containers:
        - name: microservice1
          image: microservice1-image
          # Make sure to set it to Never, or else it will pull from the docker hub and fail.
          imagePullPolicy: Never
          resources:
            limits:
              memory: "200Mi"
              cpu: "500m"
          ports:
            - containerPort: 3001
---
apiVersion: v1
kind: Service
metadata:
  name: microservice1
  labels:
    app: microservice1
spec:
  type: NodePort
  selector:
    app: microservice1
  ports:
    - port: 8080
      targetPort: 3001
      nodePort: 30001

This configuration deploys a microservice named microservice1 with resource limits of 200MB memory 🗃️ and 0.5 CPU cores. It exposes the microservice internally on port 3001 through a Deployment and externally on NodePort 30001 through a Service.

🤔 Remember the Dockerfile we built with the name microservice1-image? We are using the same image to create the container.

It is accessible on port 8080 within the cluster. We assume microservice1-image is locally available with imagePullPolicy: Never. If this is not in place, it would attempt to pull the image from the Docker Hub 🐋 and fail.

Now, let's create the manifest for microservice2. Create a new file named microservice2-deployment-service.yaml and add the following content:

// 👇🏻/k8s/manifests/microservice1-deployment-service.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: microservice2
spec:
  selector:
    matchLabels:
      app: microservice2
  template:
    metadata:
      labels:
        app: microservice2
    spec:
      containers:
        - name: microservice2
          image: microservice2-image
          # Make sure to set it to Never, or else it will pull from the docker hub and fail.
          imagePullPolicy: Never
          resources:
            limits:
              memory: "200Mi"
              cpu: "500m"
          ports:
            - containerPort: 3002
---
apiVersion: v1
kind: Service
metadata:
  name: microservice2
  labels:
    app: microservice2
spec:
  type: NodePort
  selector:
    app: microservice2
  ports:
    - port: 8081
      targetPort: 3002
      nodePort: 30002

It is similar to the manifest for microservice1, with just a few changes. 👀

This configuration deploys a microservice named microservice2 and exposes it internally on port 3002 through a Deployment and externally on NodePort 30002 through a Service.

Accessible on port 8081 within the cluster, assuming the microservice2-image is locally available with imagePullPolicy: Never.

Once, this is all done, make sure to apply these configurations and start the Kubernetes cluster with these services. Change the directory to /manifests and execute the following commands: 👇🏻

kubectl apply -f microservice1-deployment-service.yaml
kubectl apply -f microservice2-deployment-service.yaml

Check that both our deployments are Running by executing the following command: 👇🏻

kubectl get pods

Finally, our application is ready and deployed on Kubernetes with the necessary deployment configurations. 🎉

Installing Odigos 😍

💡 Odigos is an open-source observability control plane that enables organizations to create and maintain their observability pipeline.

ℹ️ If you are running on a Mac run the following command to install Odigos locally.

brew install keyval-dev/homebrew-odigos-cli/odigos

ℹ️ If you are on a Linux machine, consider installing it from GitHub releases by executing the following commands. Make sure to change the file according to your Linux distribution.

ℹ️ If the Odigos binary is not executable, run this command chmod +x odigos to make it executable before running the install command.

curl -LJO https://github.com/keyval-dev/odigos/releases/download/v1.0.9/cli_1.0.9_linux_amd64.tar.gz
tar -xvzf cli_1.0.9_linux_amd64.tar.gz
./odigos install

If you need more brief instructions on its installation, follow this link.

Now, Odigos is ready to run 🎉. We can execute its UI, configure the tracing backend, and send traces accordingly.

Connect Odigos with a Tracing Backend 💫

💡 Jaeger is an open source, end-to-end distributed tracing system.

Setting up Jaeger! ✨

For this tutorial, we will use Jaeger 🕵️‍♂️, a popular open-source platform for viewing distributed traces in a microservices application. We will use it to view the traces generated by Odigos.

For Jaeger installation instructions, follow this link. 👀

To deploy Jaeger on a Kubernetes cluster, run the following commands: 👇🏻

kubectl create ns tracing
kubectl apply -f https://raw.githubusercontent.com/keyval-dev/opentelemetry-go-instrumentation/master/docs/getting-started/jaeger.yaml -n tracing

Here, we are creating a tracing namespace and applying the deployment configuration 📃 for Jaeger in that namespace.

This command sets up the self-hosted Jaeger instance and its service. 👀

Run the below command to get the status of the running pods: 👇🏻

kubectl get pods -A -w

Wait for all three pods to be Running before proceeding further.

Now, to view the Jaeger Interface 💻 locally, we need to port forward. Forward traffic from port 16686 on the local machine to port 16686 on the selected pod within the Kubernetes cluster.

kubectl port-forward -n tracing svc/jaeger 16686:16686

This command creates a tunnel between the local machine and the Jaeger pod, exposing the Jaeger UI so you can interact with it.

Finally, open up http://localhost:16686 on your browser and see the Jaeger Instance running.

Setting up Odigos to work with Jaeger! 🌟

ℹ️ For Linux users, go to the folder where you downloaded the Odigos binaries from GitHub releases and run the following command to launch the Odigos UI.

./odigos ui

ℹ️ For Mac users, just run:

odigos ui

Visit http://localhost:3000 and you will be presented with the Odigos interface where you will see both your deployments in the default namespace.

Select both of these and click Next. On the next page, choose Jaeger as the backend, and add the following details when prompted:

Destination Name 🛣️: Give any name you want, let's say express-tracing.

Endpoint 🎯: Add jaeger.tracing:4317 for the endpoint.

And that's it — Odigos is all set to send traces to our Jaeger backend. It's that simple. 🤯

View the Distributed Tracing 🧐

After setting up Odigos, on the Jaeger homepage at http://localhost:16686, you will already see both of our microservices listed.

Odigos has already begun sending traces of our application to Jaeger. 😉

Remember, this is our microservices application. Make a few more requests to microservice1 since it serves as the starting point, it will subsequently request microservice2 for data and return it. Eventually, Jaeger will begin to populate with the traces.

Click on any one of the requests, and you should be able to observe how the request flows through your application and the time taken to complete each request.

This was all done without changing a single line of code. 🤯 All thanks to Odigos! 🤩

Just imagine, this was such a small dummy application but for a bigger application with tons of microservices running 🏃🏻‍♂️ and interacting with each other, distributed tracing would be extremely powerful! 💪

With distributed tracing, you could easily identify bottlenecks in your application and determine which service is causing problems or is taking a longer time. 🕒

Let's Wrap Up! 🥱

So far, you've learned how to closely monitor 👀 your Javascript application with distributed tracing, using Odigos as the middleware between your application and the tracing backend Jaeger. 👏

If you have made it this far, give yourself a pat on the back. 🥳 You deserve it! 😉

If you found the article and the tools helpful, be sure to give a star 🌟 Odigos and Jaeger on their GitHub repositories.

The source code for this tutorial is available here:

https://github.com/keyval-dev/blog/tree/main/odigos-monitor-JS-like-a-pro

If you have any questions or suggestions about this article, please share them in the comments section below. 👇🏻

So, that is it for this article. Thank you for reading! 🎉🫡

🔥5 Must have tools to install on your Kubernetes cluster ✨️🚀

Eden Federman — Mon, 27 Nov 2023 16:21:40 +0000

TL;DR

This article lists five must-have tools for developers to install on their Kubernetes cluster. 🎉

Feel free to explore these projects, star the repositories, and contribute to your favorites. 😉

Without any further ado, let's get started. 🏃‍♂️💨

1. Odigos

💡 Distributed tracing without code changes.

Odigos is an open-source observability control plane that enables organizations to create and maintain their observability pipeline.

Odigos automatically generates telemetry data in OpenTelemetry format to any Observability backend, without any code change. 😻.

It automatically instruments our application, eliminating the need to set up OpenTelemetry or anything on our own. Odigos handles it all. 🤯

All this is possible because of the following:

Automated Instrumentation 👾: Odigos enables automated instrumentation of applications with OpenTelemetry and eBPF, eliminating the need for code modifications.
Universal Observability Tool Compatibility 🤝: It smoothly integrates with various observability tools, providing comprehensive support and efficient collector management.

We've recently published an article on implementing Odigos, check it out here.

🌟 Star Odigos

2. Argo CD

💡 Declarative GitOps CD for Kubernetes.

Argo CD is a powerful GitOps CD tool that can help automate and simplify the deployment and management of Kubernetes applications 🚀.

Argo CD main feature include a web UI 💻, CLI, rollback capabilities, and simplified monitoring.

Why use Argo CD over traditional CD tools? 🤔

Git as single source of truth 🤫: Argo CD uses Git as a single aource of truth for app and infrastructure configuration. It makes it easy to track changes and rollback deployment if something goes wrong.
Friendly web UI 💻: Argo CD provides a dashboard to manage and get status of all the deployed applications.
Easy Rollbacks 🔄: The cluster is synced with a separate git repository so we just need to revert the changes in git and the cluster will be automatically synced with the git repository.
Disaster Recovery 🌋: In case of a disaster just point the git repository to the newly created cluster and it will have all the configs of previous cluster.

These features makes it accessible for both beginners and experienced Kubernetes users.

In short, Argo CD is a GitOps CD tool for Kubernetes ☸️ that uses Git as the single source for app and infastructure configurations and provides easy rollbacks, dashboard, and disaster recovery capabilities.

🌟 Argo CD on GitHub

3. Nginx Ingress Controller

💡 Specialized load balancer for Kubernetes environments.

It is a most widely used ingress controller for Kubernetes. ☸️ It uses Nginx as a reverse proxy and load balancer.

It runs 🏃‍♂️ in a Kubernetes environment with Nginx Plus or Nginx Open Source instances.

The key responsibilities of Nginx Ingress Controller are 👇:

Load balance traffic to containers 📦 in the Kubernetes cluster. It monitors Kubernetes ingress resources and routes traffic to the appropriate Kubernetes services and pods.
Handles networking, traffic management 👮‍♂️, communication and security 🔒.
Deploys resources based on its configuration 📝 and automatically updates rules based on ingress resource definitions.

In short, It manages traffic, security and dynamically adjusts routing based on Kubernetes ingress resources and configurations.

🌟 Nginx Ingress Controller on GitHub

4. AWS Controller for Kubernetes

💡 Manage AWS services using Kubernetes.

ACK, short for AWS Controllers for Kubernetes, is a set of custom controllers enabling integration between AWS services and Kubernetes clusters that let you directly manage AWS services from Kubernetes 😮.

ACK makes it simple to build scalable and highly-available Kubernetes applications that utilize AWS services. It provides a unified way to manage our application and it's dependencies ✨️.

Some key features of AWS Controllers for Kubernetes are:

Define and use AWS service resources directly from Kubernetes.
Take advantage of AWS managed services for our Kubernetes applications without needing to define resources outside of the cluster or run services that provide supporting capabilities like databases 🗄 or message queues.

In short, ACK enables us to manage AWS services directly from Kubernetes and provides a unified way to define and use AWS services from within our Kubernetes cluster.

🌟 AWS Controllers for K8 on GitHub

5. Kyverno

💡 Policy engine designed for Kubernetes.

When deploying things in Kubernetes, like Pods or ConfigMaps, it's important to set rules/policies.

A key practice is avoiding the use of the latest tag for container images in production, as it's often a work-in-progress dev build.

What Kyverno actually does? 🧐

In Kubernetes, security issue is a big deal, and one of the main reason is misconfigurations. These security issues arise when there are no good rules (policies) in place.

This is where policy manager like Kyverno comes in action. 😎

🚨 NOTE: Kyverno does not work on any other environment other than Kubernetes. If you are looking for a policy management that is vendor agnostic you might consider using something like Open Policy Agent.

Kyverno manages policies, whether they're about security or just good practices, in our Kubernetes setup.

We can create rules for things like the latest tag issue mentioned earlier or focus on security, like making sure your container images are safe in the software supply chain.

In short, Kyverno is a policy engine that helps manage security and best practices by allowing users to manage policies for deployments, addressing issues like misconfigurations and promoting good practices ✅️.

🌟 Kyverno on GitHub

If you think of any other helpful projects that I haven't covered in this article, please share them in the comments section below. 👇🏻

So, that is it for this article. Thank you so much for reading! 🎉

💨 The fastest way to deploy your Javascript app to Kubernetes 🌬️ ✨

Eden Federman — Tue, 14 Nov 2023 12:24:54 +0000

TL;DR

In this tutorial, you'll learn how to deploy your first javascript application on Kubernetes - a container orchestration platform ☸️.

We will deploy a simple express server that returns a sample JSON object on Kubernetes locally using Minikube ✨.

Prerequisites 📜:

Docker: For containerizing the application. 🐋

Minikube: For running Kubernetes locally. ☸️

Odigos - Open-source Distributed Tracing

Monitor all your apps simultaneously without writing a single line of code!
Simplify OpenTelemetry complexity with the only platform that can generate distributed tracing across all your applications.

We are really just starting out.

Can you help us with a star? Plz? 😽

Let's set it up 🚀

We'll start by initializing our project with:

npm init -y

This initializes a NodeJS project with the package.json 📝 file which keeps track of our installed dependencies.

Install Express.js framework

npm install express

Now, inside the package.json the dependencies object should look something like this. ✅

  "dependencies": {
    "express": "^4.18.2"
  }

Now, at the root of the project create an index.js file and add the following lines of code. 🚀

// 👇🏻 Initialize express.
const express = require("express");
const app = express();

const port = 3000;

// 👇🏻 Return a sample JSON object with a message property on the root path.
app.get("/", (req, res) => {
  res.json({
    message: "Hello from Odigos!",
  });
});

// 👇🏻 Listen on port 3000.
app.listen(port, () => {
  console.log(`Server is listening on port ${port}`);
});

We need to add a script in our package.json for running the application. Add it within the scripts object of package.json.

  "scripts": {
    "dev": "node index.js"
  },

Now, to check our application is running properly, run the server using npm run dev and make a get request to localhost:3000 either via CLI or in the browser. ✨

If you are using CLI, make sure to have cURL installed. ✅

curl http://localhost:3000

You should see something like this. 👇🏻

Now, you can simply stop the running express server using Ctrl + C 🚫

Our sample application is ready! 🎉 Now, let's containerize it and push it to Kubernetes. 🐳☸️

Containerize the application 📦

We will be using Docker to containerize our application.
In the root of the project, create a new file named Dockerfile.

💡 Make sure to exactly name it the same. Otherwise, you will need to explicitly pass the -f flag for specifying the Dockerfile path.

# Uses node as the base image
FROM node:21-alpine 
# Sets up our working directory as /app inside the container.
WORKDIR /app
# Copyies package json files.
COPY package.json package-lock.json ./
# Installs the dependencies from the package.json
RUN npm install --production
# Copies current directory files into the docker environment
COPY . .
# Expose port 3000 as our server uses it.
EXPOSE 3000
# Finally runs the server.
CMD ["node", "index.js"]

Now, we need to build ⚒️ this container to be able to actually use it and push it to Kubernetes.

Run this command to build the Dockerfile.

🚨 If you are running it on Windows, make sure to have Docker Desktop running.

// 👇🏻 We are tagging our image name to express-server
docker build -t express-server .

Now, it's time to run the container. 🏃🏻‍♂️💨

docker run -dp 127.0.0.1:3000:3000 express-server

💡 We are running our container in the background with the container port 3000 mapping to our computer port 3000.

Once again run the following command and you should see the same result as earlier. ✅

curl http://localhost:3000

NOTE: This time the application is not running on our computer as before. Instead, it is running inside the container. 🤯

Deploying in Kubernetes ⚓

As said earlier, we will use Minikube to create an orchestration environment in our local computer and use kubectl command to interact with Kubernetes. 😄

Start Minikube: 🚀

minikube start

Since we are going to be using local containers instead of pulling them from the docker hub, run these commands. ✨

eval $(minikube docker-env)
docker build -t express-server .

eval $(minikube docker-env): It is used to point your terminal’s docker-cli to the Docker Engine inside minikube.

🚨 Note, many of us use Fish as our shell, so for fish the corresponding command would be eval (minikube docker-env)

Now, in the project root, create a nested folder k8/deployment, and inside the deployment folder, create a new file called deployment.yaml with the following content.

In this file, we will manage the deployment of our container. 👇🏻

# 👇🏻 /k8/deployment/deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: express-deployment
spec:
  selector:
    matchLabels:
      app: express-svr
  template:
    metadata:
      labels:
        app: express-svr
    spec:
      containers:
        - name: express-svr
          image: express-server
          imagePullPolicy: Never # Make sure to set it to Never, or else it will pull from the docker hub and fail.
          resources:
            limits:
              memory: "128Mi"
              cpu: "500m"
          ports:
            - containerPort: 3000

Finally, run this command to apply the deployment configuration we just created, deployment.yaml. ✨

kubectl apply -f .\k8\deployment\deployment.yaml

Now, if we take a look at the running pods we can see that the pod has successfully been created. 🎉

To view the logs of our created pod, run kubectl logs <pod_name> and we should see the following.

With this, our express-server is successfully deployed on a local Kubernetes. 😎

That is it for this article, we successfully containerized our application and deployed it to Kubernetes.

The source code for this article can be found here
https://github.com/keyval-dev/blog/tree/main/js-on-k8s

Thank you so much for reading! 🎉🫡

💨 How to know what's going on in your cloud 🌥️⚡️

Eden Federman — Mon, 06 Nov 2023 11:51:04 +0000

TL;DR

Today, you will learn about the world of open-source observability. In this guide, I'll be touching:

Build a Comprehensive Observability Stack: Assemble an end-to-end solution using popular open-source tools.
Extract and Ship with Ease: Learn the ins and outs of handling traces, metrics, and logs.
Master Data Correlation: Gain expertise in linking various types of observability data for deeper insights.
Utilize a Powerful Backend Stack: Implement Grafana, Prometheus, Tempo, and Loki for robust backend management.
Control with Confidence: Harness the capabilities of Odigos to manage your observability landscape effectively.

Odigos - Open-source Distributed Tracing

We are really just starting out.
Can you help us with a star? Plz? 😽

https://github.com/keyval-dev/odigos

Theory

If you are new to observability or just interested in the difference between monitoring and observability, we recommend watching this short video by the creator of OpenTelemetry.

In short, distributed traces, metrics, and logs, with the ability to correlate between one signal to another, are the best practices for debugging production issues when working with microservices-based applications.

This is exactly what we are going to achieve for our demo application.

There is no need to learn any new technologies in order to implement and enjoy observability. With some basic Kubernetes commands — you are ready to get started.

Solution Overview

We are going to deploy 3 different systems on our Kubernetes cluster:

Target application — we will use a microservices-based application written in Java and Python. (for example applications with more programming languages and more complex architecture, use the example from the Odigos getting started guide)
Observability backend — we are going to use the following applications to store and analyze our observability data: - Grafana: for dashboards and visualization of the data - Prometheus: for storage of metrics data - Loki: for storage of logs data - Tempo: for storage of distributed tracing data
Observability control plane — we will use Odigos for automatic instrumentation of our applications (automatic extraction of traces, metrics, and logs), collectors deployment, and configuration.

Prerequisites

The following tools are required to run this tutorial:

Kind to run a local Kubernetes cluster with Docker container nodes.
Kubernetes CLI (kubectl) to run commands against Kubernetes clusters.

Creating the Kubernetes cluster

Create a new local Kubernetes cluster, by running the following command:

kind create cluster

Installing Target Applications

We will install a fork of bank-of-athnos, an example of a bank application created by Google.

We use a modified version without any instrumentation code to demonstrate how Odigos automatically collects observability data from the application.

Deploy the application using the following command:

kubectl apply -f https://raw.githubusercontent.com/keyval-dev/bank-of-athnos/main/release/kubernetes-manifests.yaml

Installing Observability Backend

As there is currently no one database that can store traces, logs, and metrics, we will deploy three different databases alongside Grafana as a visualization tool.

The following helm chart deploy Tempo (traces database), Prometheus (metrics database), and Loki (logs database) as well as a preconfigured Grafana instance with those databases as data sources.

Install odigos CLI by following this link

Connecting Everything Together Using Odigos

Now that our test application is running, our observability databases are deployed and ready to receive data, the last piece of the puzzle is to extract and ship logs, metrics, and traces from our applications to the observability databases.

The simplest and easiest way to do it is by using Odigos - a control plane for observability data. Install Odigos by executing the following command:

odigos install

After all the pods in the odigos-system namespace are running, open the Odigos UI by running the following command:

odigos ui

And navigate to http://localhost:3000 to access the UI.

Selecting Applications

There are two ways to select which applications Odigos should instrument:

Opt out (recommended): Instrument everything, including every new application that will be deployed going forward. Users can still manually mark applications that should not be instrumented
Opt In: Only instrument the applications selected manually by the user.

For this tutorial, we recommend choosing the opt out mode.

Choosing Destinations

The next step is to tell Odigos how to reach the three databases that we deployed earlier.
Add the following three destinations:

Tempo

Name: tempo (you can choose any name you would like)
URL: http://observability-tempo.observability

Prometheus

In order to add another destination, select Destinations from the sidebar and click Add New Destination

Name: prometheus
URL: http://observability-prometheus-server.observability

Loki

Name: loki
URL: http://observability-loki.observability

Exploring The Data

Wait a few seconds for Odigos to finish deploying the required collectors and instrument the target applications. You can monitor the progress by running

kubectl get pods -w

Wait for all the pods to be in Running state (especially notice the transactionservice application which has a slow startup time).

The last step is to explore our observability data in Grafana. We can now see and correlate metrics to traces to logs in order to dive deeply into how our application behaves.

Connecting to Grafana

Port forward to your Grafana instance by running:

kubectl port-forward svc/observability-grafana -n observability 3000:80

And navigating to http://localhost:3000

Enter admin as the username
For the password enter the output of the following command:

kubectl get secret -n observability observability-grafana -o jsonpath={.data.admin-password} | base64 --decode

Service Graph

Let’s start by viewing a service graph of our microservices application:

Go to the Explore from the sidebar
Select Tempo as datasource
Choose the Service Graph tab
Run the query

Metrics

Now let’s view some metrics. Click on the contacts node from the service graph and choose Request rate

A graph similar to the following should be presented:

There are many more metrics that Odigos collect and can be queried easily from the Prometheus data source, check out this document for the full list.

Traces

Click on the contacts application again in the Service Graph, but this time choose Request Histogram.

In order to correlate metrics to traces, we will use a feature called exemplars. To show exemplars:

Open the options menu
Turn on exemplars
Notice that the histogram is now added with green diamonds.

Hover over one of the added points and click Query With Tempo. A trace similar to the following should be presented:

In this trace, you can see exactly how much time each part of the entire request took.

Digging into one of the sections will show additional information such as database queries.

Logs

To further investigate specific action you can simply query the relevant logs by pressing on the small document icon.
Press on the document icon next to the balancereader to show the relevant logs:

Summary

We have shown how easy it is to extract and ship logs, traces, and metrics using only open-source solutions.

In addition, we were also able to generate traces, metrics, and logs from an application within minutes.

We now also have the ability to correlate between the different signals: We correlated metrics to traces and traces to logs. We now have all the needed data to quickly detect and fix production issues in our target applications.

What’s Next?

Notice that the observability backend that we installed is not suited for production usage.

For high volumes of data, it is recommended to persist those databases to cloud storage like S3 or use a managed offering.

⤴️ Top 6 projects for building scalable cloud-based applications 🚀

Eden Federman — Mon, 30 Oct 2023 14:39:46 +0000

TL;DR

This article lists 6 top projects for simplifying the deployment and building scalable cloud-based applications for developers. 🎉

Feel free to explore these projects, contribute to your favorites, and support them by starring their repositories.🌟

Odigos - Open-source Distributed Tracing

We are really just starting out.
Can you help us with a star? Plz? 😽

https://github.com/keyval-dev/odigos

1. OpenTelemetry

💡 Collect telemetry data and forward it to analysis tools.

OpenTelemetry is an observability toolkit that helps us collect data like traces, metrics, and logs. It is vendor and tool-neutral 🛠️ meaning it can work with different Observability Backends.

What OpenTelemetry is not? 🫣

OpenTelemetry is not a monitoring backend. Many people confuse themselves between OpenTelemetry and Observability backends like Jaegar, Datadog, etc. OpenTelemetry only generates, collects, and exports telemetry data. Storage and visualization are left to other tools. 📊

OpenTelemetry sits between the code and the observability tools we use. This provides us with flexibility and makes it easier to switch tools. 🔄

To better understand how OTel (short for OpenTelemetry) works, take a look at the below image. 👇🏻

🌟 OpenTelemetry on GitHub

2. Kubernetes

💡 Container orchestration platform for managing applications.

Kubernetes is the most important repo on the list when we are talking about cloud-native applications. How, can we skip Kubernetes right? 😜 It is the most famous orchestration platform for container-based applications and a foundation for many cloud-native tools to work.

What is Container Orchestration, and why do we even need it? 🤔

A container engine is sufficient for managing a few containers, but for hundreds or thousands of containers and hundreds of services running, the complexity grows huge 📈. Trust me, it is something I have had experience with. 🥲

This is where the orchestration engine like Kubernetes comes into play.

The best way I think of Kubernetes is as a puppet master 🎭 for containers, manipulating their actions, coordinating their tasks, and ensuring they work in harmony across a cluster of servers.

Refer to the image below to get a better understanding of what I meant by puppet master.

🌟 Kubernetes on GitHub

3. Backstage

💡 Unifies tools for a streamlined development environment.

Backstage is an open-source project that serves as a developer portal, offering a unified view of infrastructure resources, CI/CD pipelines, and observability metrics. 📊 It gives us all the building blocks to create a platform ourselves that manages our complex software development ecosystem.

It provides us with easy access to essential information without requiring in-depth tool knowledge 🧰, acting as a central hub 🏛️ for company-wide development needs.

The core functionalities of Backstage are:

Service Catalog 📋: This is the core Backstage foundation. It allows us to track and manage all our services, apps, and pipelines in one place.

Software Templates 📄: With the Backstage UI interface, we can easily create new services with just a few clicks or use a YAML template to add necessary resources.

Tech Documentations 📃: It adds seamless technical documentation management, ensuring teams can effortlessly keep content up-to-date, all from their code repositories.

In short, this abstracts away a lot of CI/CD and provides us with information on the company's services. 🚀 I would say this is a must-have tool for any company that is planning to upscale and streamline their development operations.

🌟 Backstage on GitHub

4. Prometheus

💡 System monitoring tool with time-series data.

Prometheus is a free open-source software application used for event monitoring and alerting. 🧐 It records real-time metrics in a time series database (allows querying the data using its own query language called PromQL).

It also provides an alerting system that allows us to define thresholds and conditions for alerts.

When certain metrics exceed or fall below defined thresholds, Prometheus can trigger notifications, helping in successfully addressing potential issues before they impact the system's health.

In short, Prometheus helps keep a close watch 👀 on our infrastructure's health and performance.

🌟 Prometheus on GitHub

🔴 GOOD TO KNOW: Notice that I've mentioned two similar projects, OpenTelemetry and Prometheus, which serve similar purposes. 🔄

Prometheus is primarily a system-level monitoring and alerting tool, while OpenTelemetry is focused on collecting and forwarding application-level telemetry data.

Prometheus didn't initially support OpenTelemetry metrics, but now they can work together.

For more details, you can refer to this article.

5. Cilium

💡 Efficient eBPF-based networking for containers.

Cilium is a free and open-source software solution that provides networking and security 🛡️ for containerized applications.

Cilium leverages eBPF to provide high-performance networking and security and has been designed to integrate with container orchestration platforms like Kubernetes. ☸️

One important feature of Cilium is its ability to apply security rules at the network level, also allows us to encrypt and authenticate network traffic, making sure that data is transmitted securely between containers. 🐋

In short, Cilium secures container workloads in Kubernetes with eBPF, offering network security, encryption, and authentication.

To better understand how Cilium works at its architectural level, take a look at the below image. 👇🏻

🌟 Cilium on GitHub

6. Rook

💡 Simplifies cloud-native persistent storage management.

This tool really is a lifesaver for anyone who is working with the Ceph storage. 😍

To understand and implement Rook, you must have a basic understanding of Ceph software-defined storage. If not, let me briefly introduce Ceph.

What exactly is Ceph? 🧐

Ceph is an open-source software storage platform that provides object storage, block storage, and file system storage in a single unified storage cluster. 📦

Rook simplifies the deployment and management of Ceph storage systems on Kubernetes.

By deploying Rook on Kubernetes, we can make Ceph storage highly available, automated 🤖, and simple to operate at scale.

In short, Rook turns Ceph into a fully managed service for Kubernetes and abstracts away the complexity of Ceph, making it easy to set up and manage cloud-native storage for our containers.

🌟 Rook on GitHub

Introducing Odigos

💡Distributed tracing without code changes.

If you are working with OpenTelemetry then this is the tool you need. ✨

Odigos automatically generates telemetry data in OpenTelemetry format to any Observability backend, without any code change. 😲

It achieves this all by the following:

Automated Instrumentation 🤖: Odigos enables automated instrumentation of applications with OpenTelemetry and eBPF, eliminating the need for code modifications.

Universal Observability Tool Compatibility 🤝: It smoothly integrates with various observability tools, providing comprehensive support and efficient collector management.

Ease of installation ✨: Odigos excels in user-friendliness, seamlessly integrating OpenTelemetry, ensuring easy installation and adaptability to specific requirements with minimal hurdles.

We've recently published an article on implementing Odigos. Read here.

If you think of any other helpful projects that I haven't covered in this article, please share them in the comments section below. 👇🏻

So, that is it for this article.

Thank you so much for reading! 🎉🫡

🔥 Top 6 monitoring tools to become a better developer 🤯 🤯

Eden Federman — Mon, 23 Oct 2023 11:35:41 +0000

TL;DR

Monitoring can be complex, especially given the number of available tools and the dynamic nature of environments.

In this article, I compare the most popular monitoring tools to help you choose the right one for your specific needs.

Odigos - Open-source Distributed Tracing

We are really just starting out.
Can you help us with a star? Plz? 😽

https://github.com/keyval-dev/odigos

Introduction

With the growing need for scalable applications, Kubernetes emerged as the standard for managing containerized workloads and services.

It makes deploying and running applications on distributed instances easy, but monitoring the infrastructure can be challenging.

Kubernetes monitoring is the practice of tracking and observing the performance, health, and behavior of your applications and the infrastructure providing them.

It involves collecting and analyzing traces, metrics, and logs to help you detect and troubleshoot issues, and even optimize your clusters for better resource management.

But being such a complex environment, various tools have arisen to address this issue.

Here we’ll explore some of the main solutions and hopefully help you choose according to your needs.

Key metrics to monitor

First, let’s divide our metrics into two groups:

Resource Utilization

These include CPU, memory, and disk usage at the cluster, node, pod, and container levels, and help you make decisions about decreasing or increasing the size of your cluster. It is also important to monitor your cluster with more general metrics such as node availability and health.

Cluster is a set of nodes that run containerized applications. It is the highest level of abstraction in Kubernetes.
Node is a physical or virtual machine that is part of your cluster. It can be a virtual machine in the cloud, for instance
Pod is a group of one or more containers that share storage and network resources. It is the smallest deployable unit in Kubernetes.
Container is a standard unit of software that packages up code and all its dependencies so the application runs quickly and reliably from one computing environment to another.

Application Performance

These will depend on the type of your application and business.

For example, an API will provide metrics like response time, request latencies, error rates and throughput.

With that in mind, let’s get to know some of the solutions we can use.

Tools

Kubernetes Dashboard

https://github.com/kubernetes/dashboard

The Kubernetes Dashboard is a web-based user interface made for monitoring and managing Kubernetes clusters. You can access essential information such as CPU and memory utilization, deploy and manage applications running in the pods, and change the amount of resources in the cluster.

It gives you a basic overview of your cluster and it makes it easy to execute some actions, while it is maintained by the Kubernetes community.

But being that simple also means it doesn’t have many options for visualizations, and it also does not have advanced resource metrics.

cAdvisor

https://github.com/google/cadvisor

cAdvisor is an open-source tool developed to monitor containers, and since Kubernetes is a container orchestrator, we can use it too. It can help you collect, process, and export container metrics such as CPU and memory usage. By default, it exists on every Kubernetes node, and it can even expose Prometheus metrics. It is one of the more basic Kubernetes-native monitoring tools.

It is built into Kubernetes and is easy to use, but it is also basic and has limited functionality. It is usually used together with Prometheus and Grafana.

Prometheus

https://prometheus.io/

Prometheus is the leading solution for open-source monitoring, widely recognized as the primary standard for monitoring Kubernetes. It is a fundamental component of the Cloud Native Computing Foundation (CNCF).

Prometheus consists of three main components:

Server: This component is responsible for managing and storing the metrics collected.
Alert Manager: It handles alerting and notification functionalities.
Exporters: Exporters are in charge of generating and exporting metrics.

Exporters gather metrics from various sources, and the server stores them in a database for analysis and visualization.

Prometheus offers several noteworthy features:

An intuitive query-based system.
Built-in alerting capabilities.
A thriving and extensive community for support.

One thing to note is that Prometheus lacks a built-in visualization interface. Therefore, it is common to complement Prometheus with a tool like Grafana, which is another open-source project. Grafana not only offers pre-built dashboards for Kubernetes but also enables users to create custom visualizations to suit their specific needs.

ELK stack (and OpenSearch)

https://www.elastic.co/pt/elastic-stack
https://opensearch.org/

The ELK stack used to be an open-source monitoring solution for Kubernetes, but Elastic decided to close it with proprietary licenses.

ELK stands for:
- ElasticSearch: A database engine for storing and searching data.
- Logstash: Captures and processes logs, then sends them to ElasticSearch.
- Kibana: A data visualization tool.

In response to Elastic's decision, AWS forked ElasticSearch and Kibana to create OpenSearch and OpenSearch Dashboard. As of now, they remain relatively similar to their ELK counterparts.

Advantages of choosing the open-source option:

It includes some security and analysis features that are paid in the ELK stack.
Both ELK and OpenSearch have strong communities.
They are easy to deploy and use with Kubernetes and offer rich analysis capabilities.

However, there are disadvantages:

They can be challenging to maintain at scale.
Often paired with Apache Kafka for buffering data with large volumes.
While the closed source ELK has a free tier, payment is required for some features.

Datadog

https://www.datadoghq.com/

Datadog: When exploring beyond open-source options, Datadog emerges as a comprehensive full-stack monitoring solution.

Key Features:

End-to-End Monitoring: Datadog offers robust infrastructure, security, and application monitoring features, covering the entire spectrum of your systems.
Data Insights: You can monitor requests, traces, logs, and correlate these diverse data sets to derive valuable insights.
Resource Metrics: Datadog provides detailed metrics on resource utilization.
Data Coverage: Once configured, Datadog efficiently gathers data from across your architecture, offering a holistic view of your systems.

But it also has its disadvantages:

Complex Initial Setup: Please note that the initial setup may be somewhat intricate, requiring configuration file adjustments.
Budget Considerations: Keep in mind that while this broad data collection is beneficial, it can be expensive and should be managed prudently to avoid unnecessary expenses.

Dynatrace

https://www.dynatrace.com/

Dynatrace is a comprehensive, paid full-stack monitoring solution.

It excels in monitoring the availability and health of your Kubernetes clusters while enabling unified monitoring across a wide array of tools, including services in AWS and Google Cloud.

The platform is known for:

user-friendly setup
highly effective for tracking metrics in complex, distributed systems.

However, it comes with a notable investment requirement.

For those who prefer not to handle monitoring setup and infrastructure management, Dynatrace offers a compelling option.

It's often chosen over Datadog when the focus is primarily on application monitoring rather than monitoring infrastructure resource usage.

Odigos

https://odigos.io

Odigos is an open-source platform that generates distributed traces, metrics, and logs instantly, without code changes.

It focuses on the automatic instrumentation and collection of the telemetry data from all your applications and works alongside traditional monitoring solutions.

It’s great for beginners who want to instrument their applications quickly, without touching their code.

It’s also great if you are unhappy or stuck with your current monitoring solution and want to try other options.

Just install Odigos, and it will:

Automatically instrument all of your applications
Collect and manage the telemetry data, and
Send it to the monitoring vendor of your choice.

Instantly

It supports all the major open-source and managed solutions and is very easy to install and implement.

Wrapping up

With so many Kubernetes monitoring solutions available, it can be difficult to choose the right one for your needs. Now that you have a basic understanding of the different options available, you can start to narrow down your choices and choose the solution that best meets your specific requirements.

The main factors to consider when choosing a Kubernetes monitoring solution:

Features: What features are most important to you
Cost: Open source (typically free to use) vs paid solutions (can be expensive).
Ease of use: Some solutions are easier to set up and use than others.
Scalability: Can the solution scale to meet your needs as your cluster grows?

How to monitor your requests between multiple applications... 🤔

Eden Federman — Mon, 16 Oct 2023 11:20:53 +0000

TL;DR

Imagine that you are sending an HTTP request from one app; this one sends it to another app that sends it to another app. What if something happens along the way?

You need to mark all the requests to pinpoint where the problem occurred.

In this tutorial, you'll learn how to use OpenTelemetry to monitor your applications with insights into performance, tracing, and metrics.

You will learn:

How to monitor our application using OpenTelemetry.
How to view logs and ship traces.
How to view Metrics and filter the traces.
How to automate the monitoring of applications.

Odigos - Open-source Distributed Tracing

We are really just starting out.
Can you help us with a star? Plz? 😽

https://github.com/keyval-dev/odigos

Let's set it up🔥

Here, I'll walk you through installing the package dependencies required for this project.

Create your project folder for the web application as done below.

mkdir monitor-app
cd monitor-app
mkdir server

Setting up the Node.js server 🤖

Navigate into the server folder and create a package.json file.

cd server && npm init -y

Install Express.

npm install express

ExpressJS is a back-end web application framework for building RESTful APIs with Node.js.

Create an index.js file - the entry point to our web server.

// 👇server/index.js
touch index.js

Set up a Node.js server using Express. The code snippet below returns a JSON object with one key when we do a get request to /static-data or /fetch-data endpoint in our browser.

 // 👇server/index.js
const express = require("express");
const app = express();
const PORT = 8000;

app.use(express.urlencoded({ extended: true }));
app.use(express.json());

app.get("/static-data", (req, res) => {
  res.json({
    msg: "Hello world!",
  });
});

app.get("/fetch-data", (req, res) => {
  // Simulate a real-world database call
  setTimeout(() => {
    res.json({
      msg: "Hello world!",
    });
  }, 2000);
});

app.listen(PORT, () => {
  console.log(`The server is listening on port: ${PORT}`);
});

💡TIP OF THE DAY

Since the node version v18.11.0 we no longer need nodemon to watch for changes and restart the server, it is now built into Node with --watch flag.

Configure node --watch by adding the start & trace-start command to the list of scripts in the package.json file.

// 👇server/package.json
"scripts": {
  "test": "echo \"Error: no test specified\" && exit 1",
  "start": "node --watch index.js",
  "trace-start": "node -r ./tracing.js --watch index.js"
},

start: The code snippet starts the web server.
trace-start: This code snippet starts the web server while preloading the tracing.js file. We will be using this command for demonstration.

Manually Setting up OpenTelemetry and SigNoz ⚒️

OpenTelemetry is used to instrument, generate, collect, and export telemetry data. SigNoz is an open-source APM. It helps developers monitor their applications & troubleshoot problems, an open-source alternative to other APMs available. It is a one-stop solution to get access to metrics, logs, and traces of an application.

We'll start by installing the required OpenTelemetry packages.

⚠️ If you are running this on Windows, run each of these commands individually.

npm install --save @opentelemetry/sdk-node \
@opentelemetry/auto-instrumentations-node \
@opentelemetry/exporter-trace-otlp-http

For SigNoz installation, follow the installation steps shown here.

Instantiate tracing by creating a tracing.js file and using the below code.

    // 👇server/tracing.js
"use strict";
const process = require("process");
const opentelemetry = require("@opentelemetry/sdk-node");
const {
  getNodeAutoInstrumentations,
} = require("@opentelemetry/auto-instrumentations-node");
const {
  OTLPTraceExporter,
} = require("@opentelemetry/exporter-trace-otlp-http");
const { Resource } = require("@opentelemetry/resources");
const {
  SemanticResourceAttributes,
} = require("@opentelemetry/semantic-conventions");

const exporterOptions = {
  url: "http://localhost:4318/v1/traces", // default URL for sending tracing data.
};

const traceExporter = new OTLPTraceExporter(exporterOptions);
const sdk = new opentelemetry.NodeSDK({
  traceExporter,
  instrumentations: [getNodeAutoInstrumentations()],
  resource: new Resource({
    [SemanticResourceAttributes.SERVICE_NAME]: "Monitor-Node-App",
  }),
});

// initialize the SDK and register with the OpenTelemetry API
sdk.start();

// shut down the SDK on process exit
process.on("SIGTERM", () => {
  sdk
      .shutdown()
      .then(() => console.log("Tracing terminated!"))
      .catch((error) => console.log("Error terminating tracing.", error))
      .finally(() => process.exit(0));
});

We are monitoring our Node application using the Node SDK @opentelemetry/sdk-node for tracing and metrics, @opentelemetry/auto-instrumentations-node for easy setup of instrumentations, and @opentelemetry/exporter-trace-otlp-http for exporting trace data to OTLP-compatible receivers via HTTP and JSON.

We are done with the basic instrumentation of our demo Node application with OpenTelemetry and SigNoz 🥂. Now, run the trace-start command.

npm run trace-start

Visit the SigNoz UI http://localhost:3301. We should be presented with something like this after we log in.

Don't worry about all this data; it is pre-populated by SigNoz. Note that we do not see our Monitor-Node-App in the list of services. This is because we have not made requests to our server.

For SigNoz to show the traces, we need to generate some load on our server. For this, we can refresh endpoints multiple times on our browser or run the following CLI command on our endpoints /static-data or /fetch-data to automatically do that for us.

For Linux Users

ℹ️ Make sure to have curl installed.

for i in {1..20}; do curl http://localhost:8000/fetch-data; done

For Windows Users

1..20 | ForEach-Object { Invoke-RestMethod -Uri 'http://localhost:8000/fetch-data' }

Now, on visiting the SigNoz UI once again we should see our service in the list of services.

In this trace, we can exactly see how much time each part of the entire request took. In our case not many, since the request is fairly simple.

For proper visualization, we will take a look at the request from one of the demo applications already provided with SigNoz.

As we can clearly see, the first request which basically executes SQL Query goes through multiple steps, and, at last, it finally executes the SQL query. We can also see the time taken for each span in the request.

SigNoz's Traces dashboard offers ready-made visualizations for our tracing data. It includes strong filters to analyze the spans based on our selected criteria and chosen time frame.

Visualize Metrics from Hostmetrics 👀

The most common way to accept metrics in SigNoz is through the Prometheus receiver.

For simplicity, I will demonstrate how to Visualize default metrics provided by Hostmetrics that is by default enabled on SigNoz installation.

All the list of available metrics can be found here.

Under the Dashboards section in the SigNoz UI, create a new Time Series panel.

In the PromQL query input, please enter the following: For example, let's use the metric system_cpu_load_average_5m, as the name suggests it gives the 5-minute load average of the CPU. Feel free to adjust the metric to your preference.

Automatically connect with Odigos 🤝

Odigos is an open-source observability control plane that enables organizations to create and maintain their observability pipeline.

Remember all the hassle we went through when manually setting up? With Odigos, there's no need for that. It automatically instruments our application, eliminating the need to set up OpenTelemetry or anything on our own. Odigos handles it all for us. 🤯

Instructions on how to install Odigos can be found here.

We need to install SigNoz on Kubernetes so that OpenTelemetry can send the collected data to it.

SigNoz can be installed on Kubernetes easily using Helm:

helm repo add signoz https://charts.signoz.io
kubectl create ns platform
helm --namespace platform install my-release signoz/signoz

To port forward SigNoz UI on our local machine, run the following.

export POD_NAME=$(kubectl get pods --namespace platform -l "app.kubernetes.io/name=signoz,app.kuber
    netes.io/instance=my-release,app.kubernetes.io/component=frontend" -o jsonpath="{.items[0].metadata.name}")

kubectl --namespace platform port-forward $POD_NAME 3301:3301

Now, you can access the SigNoz UI on http://localhost:3301

For the demonstration, we will use another e-commerce application from Google to get a bigger picture of distributed tracing. The repo does not contain any instrumentation or monitoring setup.

Create a clone of this repository microservices-demo

git clone https://github.com/keyval-dev/microservices-demo.git

Create a new local Kubernetes cluster, by running the following command. We will need it when setting up Odigos.

ℹ️ For Windows Users, make sure to have Docker Desktop running.

minikube start

Instructions on how to install minikube can be found here.

Deploy the cloned application with the following command

kubectl apply -f https://raw.githubusercontent.com/keyval-dev/microservices-demo/master/release/kubernetes-manifests.yaml

Start the Odigos UI with the following command.

./odigos ui

Visit the Odigos UI on localhost:3000. Select all the microservices in the namespace as shown below.

After selecting all the applications we will be asked for:

Destination Name: A name for our destination.
Host Endpoint: Use the host endpoint for SigNoz.

After doing this, we should now be prompted with the following UI.

Congratulations🎉! The Odigos setup has been successful. Now, it should automatically send traces, metrics, and logs to our observability backend.

Now, to see that in practice, we need to first set up the external IP for our frontend-external LoadBalancer service.

Running the kubectl get services command should show the following. Notice the <pending> IP for the external-frontend service.

By default, it is not possible to access LoadBalancer service on the browser. For this, we need to set up minikube tunnel. For more info on this command visit here.

minikube tunnel
kubectl get services

Now, we can see the IP and port assigned to the external-frontend service.

Visit http://127.0.0.1:8081 on the browser to access the application.

Run the SigNoz service and execute the following command.

kubectl port-forward -n tracing svc/<service_name> <port_to_use>:<port>

Now, we should be able to view all the traces of our application as we did previously.

Wrap Up! 📝

So far, we've learned how to closely monitor our app's performance with traces and Hostmetrics, first manually using OpenTelemetry and SigNoz, and then automating the process with Odigos.

Note: We are not limited to using SigNoz; we can use any observability database out there. Just for the sake of this article, I have chosen to use SigNoz.

It is always a good idea to have a monitoring system for any production-level application. This will help us debug errors if any arise in the future. Most importantly, it will help us identify any performance bottlenecks in our application, resulting in enhanced efficiency and user experience.

The source code for this tutorial is available here:

https://github.com/keyval-dev/blog/tree/main/instrumenting-node-app

Thank you for reading! 🎉