Monitoring on HabibiOps

Setting Up Monitoring with Prometheus and Grafana - Part 3 - Grafana

Sat, 18 Apr 2026 00:00:00 +0000

Introduction

In the previous blog posts part 1 and part 2, we have Node Exporter and Prometheus set up. We can already monitor our VMs and get valuable information. However, running PromQL queries repeatedly is not practical for day-to-day monitoring or visualization.

For that, we will deploy Grafana and import a pre-built dashboard so that we can visualize the scraped metrics. By the end of this post, we will have:

A reusable Grafana Ansible role
Provisioning of the data source and dashboards
Docker volume for persisting the Grafana data

Prerequisites

For the demo in this post to work, you need to have:

One or more target VMs
Node Exporter must be preconfigured and set up
Docker to be installed and available on the Prometheus server
community.docker to be installed
An existing Prometheus instance

Architecture Overview

For simplicity, we are going to focus only on Grafana and its immediate components:

A dedicated host for Grafana with an internal IP
Grafana runs as a Docker container and exposes the port 3000
A Docker volume will mount onto the container for persisting grafana-related data

Once all is done, we will have the full architecture setup:

Grafana

Similar to Prometheus, Grafana can be installed directly on the host or deployed as a container. At this point, it is clear that we will deploy Grafana as a container. The Ansible role will be broken down into two phases:

Prepare: Create the directories, render the configuration template and create the Docker volume
Deploy: Pull, run the image and mount the created volume onto the container

Variables

The variables for this role will be split into five categories:

Paths and provisioning
Prometheus integration
Container integration
Storage and volumes
Endpoint

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33


---
grafana_provisioning_dir: "/opt/grafana/provisioning"
grafana_datasources_dir: "{{ grafana_provisioning_dir }}/datasources"

grafana_prometheus_datasource: "{{ grafana_datasources_dir }}/prometheus.yml"

# prometheus variables
grafana_prometheus_host: "prometheus"
grafana_prometheus_port: 9090

grafana_dashboards_dir: "{{ grafana_provisioning_dir }}/dashboards"
grafana_dashboard_provider_file: "{{ grafana_dashboards_dir }}/dashboard_provider.yml"
grafana_node_exporter_dashboard_file: "{{ grafana_dashboards_dir }}/node_exporter_full.json"

grafana_image_name: "grafana/grafana"
grafana_image_tag: "13.0"
grafana_image: "{{ grafana_image_name }}:{{ grafana_image_tag }}"

grafana_container_name: "grafana-instance"
grafana_listen_port: 3000
grafana_container_ports:
 - "{{ grafana_listen_port }}:{{ grafana_listen_port }}"

grafana_volume_name: "grafana-data"
grafana_container_volumes:
 - "{{ grafana_volume_name }}:/var/lib/grafana"
 - "{{ grafana_datasources_dir }}:/etc/grafana/provisioning/datasources:ro"
 - "{{ grafana_dashboards_dir }}:/etc/grafana/provisioning/dashboards:ro"

grafana_prometheus_datasource_url: "http://{{ grafana_prometheus_host }}:{{ grafana_prometheus_port }}"
grafana_prometheus_datasource_name: "Prometheus"

grafana_endpoint_url: "http://{{ ansible_host }}:{{ grafana_listen_port }}"

Preparation

Our focus for this phase is:

Creating config directories, which we will later bind-mount into the container
Render the data source and dashboard provisioning templates
Create the Docker volume, which will persist Grafana’s internal state (database, users, plugins). Dashboards and data sources will be provisioned via bind mounts

Dashboard Template

We define the dashboard provider template in templates/dashboards.yml.j2:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


apiVersion: 1

providers:
 - name: "default"
 orgId: 1
 folder: "Infrastructure"
 type: file
 disableDeletion: false
 updateIntervalSeconds: 30
 options:
 path: /etc/grafana/provisioning/dashboards

Prometheus Data Source Template

We define the template in templates/prometheus_datasource.yml.j2 so that we can pre-include our Prometheus data source:

1
2
3
4
5
6
7
8
9


apiVersion: 1

datasources:
 - name: "{{ grafana_prometheus_datasource_name }}"
 type: prometheus
 access: proxy
 url: "{{ grafana_prometheus_datasource_url }}"
 isDefault: true
 editable: false

Later in this series, we will further extend the template to include an Alert data source.

Deployment

The deployment phase consists of two steps:

Pulling the Docker image
Running the container with the volume and bind-mounts included

This can be done using these two tasks:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


---
- name: Pull Grafana Docker image
 community.docker.docker_image:
 name: "{{ grafana_image }}"
 source: pull
 register: grafana_docker_image_pull

- name: Run Grafana container
 community.docker.docker_container:
 name: "{{ grafana_container_name }}"
 image: "{{ grafana_image }}"
 state: started
 restart_policy: always
 recreate: "{{ grafana_docker_image_pull.changed }}"
 ports: "{{ grafana_container_ports }}"
 volumes: "{{ grafana_container_volumes }}"

Main.yml

The role ties the phases together in tasks/main.yml:

1
2
3
4
5
6


---
- name: Run the host-preparation tasks
 ansible.builtin.import_tasks: prepare.yml

- name: Run the Docker setup
 ansible.builtin.import_tasks: deploy.yml

This completes the Grafana role.

Example Playbook

The final step is to actually use our role and run it on our Prometheus host. To do that, we will create playbooks/grafana.yml:

1
2
3
4
5
6
7
8


---
- name: Set up Grafana
 hosts: grafana
 become: true
 roles:
 - grafana
 tags:
 - grafana

Then we run our playbook using the command:

1

ansible-playbook -i inventory playbooks/grafana.yml --tags=grafana

Localhost Deployment

You can perform a safe, local deployment for testing purposes:

1
2
3
4
5
6
7
8


- name: Install Grafana on localhost
 hosts: localhost
 become: false
 gather_facts: true
 roles:
 - grafana
 tags:
 - grafana

Then we can run the playbook using the command:

1

ansible-playbook playbooks/grafana.yml --tags=grafana

You can now access Grafana from the browser at 127.0.0.1:3000 with the default credentials:

1
2


username: admin
password: admin

Verification

Once the playbook finishes execution, we can verify Grafana is up and running by:

Checking running containers:

1

docker ps

Querying the endpoint

1

curl http://<ansible_host>:3000/api/health

If all goes well, you should get:

1
2
3
4
5


{
 "database": "ok",
 "version": "13.0.1",
 "commit": "<hash>"
}

We can also create a dedicated Ansible task for performing the verification for us, making it more suitable for a production environment.

Conclusion

In this post, we built a reusable Ansible role for deploying Grafana as a Docker container while also provisioning the data sources and Node Exporter Full dashboard.

The complete source code for this post can be found on GitHub.

So far, we have a basic monitoring stack setup that can be easily deployed on demand. But we are still missing a few key components to transform it into a more production-level solution. One of these critical components is Alerts, and that will be covered in the next post.

Setting Up Monitoring with Prometheus and Grafana - Part 2 - Prometheus

Sun, 05 Apr 2026 00:00:00 +0000

Introduction

In the previous post, we have covered how to deploy Node Exporter using our custom-built Ansible role. Node Exporter is only the first piece of the puzzle in building a monitoring stack solution. The next critical component in the monitoring stack is Prometheus.

By default, Prometheus uses local storage for persisting metrics data. These metrics are stored in a built-in Time Series Database (TSDB). Prometheus also supports integration with various remote storage solutions. For this post, we will focus on local storage and use a Docker volume to persist metrics data even when the container is restarted.

By the end of this post, you will have:

A reusable Prometheus Ansible role
Persistent metrics storage using Docker volumes
Automatic discovery of Node Exporter targets

Prerequisites

For the demo in this post to work, you need to have:

One or more target VMs
Node Exporter must be preconfigured and set up
Docker to be installed and available on the Prometheus server
community.docker to be installed

Architecture Overview

We will first look at the architecture, then move on to implementation.

Ansible host that runs the deployment
Target VMs that have Node Exporter installed and running as a systemd service
A Prometheus host configured to monitor the target VMs

Prometheus follows a pull-based model, periodically scraping metrics from configured targets. The diagram below illustrates the setup:

Prometheus

Prometheus can be installed directly on the host or deployed as a container. By now, it’s recommended to use containerized deployments, and this is what we will be doing. Our Prometheus Ansible role will be broken down into two main phases:

Prepare: Create the directories, render the Prometheus configuration template and create the Docker volume
Deploy: Pull, run the image and mount the created volume onto the container

Core Variables

Just as in the Node Exporter, we will utilize variables to make our role flexible and adaptable without changing the internal implementation. The main variables are:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


prometheus_provisioning_dir: "/opt/prometheus"
prometheus_config_dir: "{{ prometheus_provisioning_dir }}/config"
prometheus_config_file: "{{ prometheus_config_dir }}/prometheus.yml"

prometheus_port: 9090

prometheus_image_name: "prom/prometheus"
prometheus_image_tag: "v3"
prometheus_image: "{{ prometheus_image_name }}:{{ prometheus_image_tag }}"
prometheus_container_name: "prometheus-instance"
prometheus_volume_name: "prometheus-data"

prometheus_container_ports:
 - "{{ prometheus_port }}:{{ prometheus_port }}"

prometheus_container_volumes:
 - "{{ prometheus_volume_name }}:/prometheus"
 - "{{ prometheus_config_dir }}:/etc/prometheus:ro"

We mount the configuration as read-only (/etc/prometheus:ro) to prevent accidental modification from inside the container.

Preparation

Our focus for this phase is:

Creating config directories, which we will later bind-mount into the container
Render the Prometheus configuration template
Create the Docker volume, which will store Prometheus’ TSDB

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20


---
- name: Create Prometheus provisioning directories
 ansible.builtin.file:
 path: "{{ item }}"
 state: directory
 mode: "0755"
 loop:
 - "{{ prometheus_provisioning_dir }}"
 - "{{ prometheus_config_dir }}"

- name: Render Prometheus configuration
 ansible.builtin.template:
 src: prometheus.yml.j2
 dest: "{{ prometheus_config_file }}"
 mode: "0644"
 register: prometheus_config

- name: Create Prometheus data volume
 community.docker.docker_volume:
 name: "{{ prometheus_volume_name }}"

Prometheus Config Jinja Template

We will be using the following templates/prometheus.yml.j2 template:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


...
scrape_configs:
 - job_name: "prometheus"
 metrics_path: "/metrics"
 scrape_interval: 15s
 static_configs:
 - targets: ["{{ ansible_host }}:{{ prometheus_port }}"]

 - job_name: "nodes"
 metrics_path: "/metrics"
 scrape_interval: 15s
 static_configs:
 - targets:
 {% for host in groups['targets'] %}
 - "{{ hostvars[host]['ansible_host'] }}:{{ prometheus_node_exporter_port }}"
 {% endfor %}

There are two scrape configs:

Prometheus, allowing it to expose and monitor its own internal metrics
nodes or the target VMs.

The targets are dynamically generated as we loop over the inventory groups['targets'] and we set the metrics endpoint. The metrics endpoint has the format of <ansible_host>:<node_exporter_port>. Each target exposes its metrics via an HTTP endpoint (typically /metrics), which Prometheus periodically scrapes. This is defined in the configuration file via metrics_path: "/metrics".

Below is an example of a rendered prometheus.yml template:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


global:
 scrape_interval: 15s
 evaluation_interval: 15s

scrape_configs:
 - job_name: "prometheus"
 metrics_path: "/metrics"
 scrape_interval: 15s
 static_configs:
 - targets: ["prometheus:9090"]

 - job_name: "nodes"
 metrics_path: "/metrics"
 scrape_interval: 15s
 static_configs:
 - targets:
 - "vm-1:9100"
 - "vm-2:9100"

Rendering of the hosts depends on how ansible_host is defined in your inventory. On localhost, this will be resolved to 127.0.0.1

Deployment

The deployment phase consists of two steps:

Pulling the Docker image
Running the container with the volume and bind-mounts included

This can be done using these two tasks:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


---
- name: Pull Prometheus image
 community.docker.docker_image:
 name: "{{ prometheus_image }}"
 source: pull
 register: prometheus_image_pull

- name: Run Prometheus container
 community.docker.docker_container:
 name: "{{ prometheus_container_name }}"
 image: "{{ prometheus_image }}"
 state: started
 restart_policy: always
 recreate: "{{ prometheus_config.changed or prometheus_image_pull.changed }}"
 ports: "{{ prometheus_container_ports }}"
 volumes: "{{ prometheus_container_volumes }}"

Main.yml

The role ties the phases together in tasks/main.yml:

1
2
3
4
5
6


---
- name: Run Prepare tasks
 ansible.builtin.import_tasks: prepare.yml

- name: Run Deploy tasks
 ansible.builtin.import_tasks: deploy.yml

This completes our Prometheus role.

Example Playbook

The final step is to actually use our role and run it on our Prometheus host. To do that, we will create playbooks/prometheus.yml:

1
2
3
4
5
6
7
8


---
- name: Set up Prometheus
 hosts: prometheus
 become: true
 roles:
 - prometheus
 tags:
 - prometheus

Then we run our playbook using the command:

1

ansible-playbook -i inventory playbooks/prometheus.yml --tags=prometheus

Localhost Deployment

You can perform a safe, local deployment in case you do not have a remote host:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


- name: Install Prometheus on localhost
 hosts: localhost
 become: false
 gather_facts: true
 vars:
 prometheus_provisioning_dir: "./tmp/prometheus"
 ansible_host: "127.0.0.1"
 roles:
 - prometheus
 tags:
 - prometheus

Since we’re running on localhost, we don’t need to explicitly specify an inventory file. So we can run our playbook directly:

1

ansible-playbook playbooks/prometheus.yml --tags=prometheus

You can now access Prometheus from the browser at 127.0.0.1:9090

Verification

Once the playbook finishes execution, we can verify Prometheus is up and running by:

Checking running containers:

1

docker ps

Querying the endpoint

1

curl http://<ansible_host>:9090/-/healthy

If all goes well, you should get Prometheus Server is Healthy. as an output.

We can also create a dedicated Ansible task for performing the verification for us, making it more suitable for a production environment.

We can also access the dashboard from our browser and verify that our targets are being monitored:

Conclusion

In this post, we built a reusable Ansible role for deploying Prometheus as a Docker container. By structuring the role into clear phases and driving it through variables, we ensure maintainability and consistency across environments. The role is also written to be easily adjustable by modifying variables without changing the internal implementation.

The complete source code for this post can be found on GitHub.

By now, we have Node Exporter installed on the target hosts and Prometheus pulling the metrics. The next step is to visualize and explore these metrics using Grafana.

Setting Up Monitoring with Prometheus and Grafana - Part 1 - Node Exporter

Wed, 25 Mar 2026 00:00:00 +0000

Introduction

A monitoring stack is only useful when it is deployed consistently and remains easy to maintain over time. Manual installations and one-off configurations tend to drift quickly, which makes upgrades and troubleshooting harder than they need to be.

In this series, we build the stack component by component using Ansible roles. This first post focuses only on Prometheus Node Exporter, which is a lightweight collector that exports and exposes a wide variety of hardware- and kernel-related metrics. We will go over the installation process, running as a hardened systemd service, and exposing the metrics on port 9100 for later scraping by Prometheus.

Node Exporter

It is recommended to run Node Exporter directly on the host itself instead of a container since the exporter needs to access kernel-related metrics. Although it is possible to run in a container, the /proc, /sys and other directories have to be mounted for it to function properly. In this post, we will focus on host-based set up for the exporter.

The role is broken down into four phases:

Preparation: Create user, group and working directory
Installation: Download and install the Node Exporter binary
Configure: Create and manage systemd service for the exporter
Cleanup: Remove temporary artifacts

Core Variables

Rather than hard-coding installation details into the role, we keep the behavior driven by defaults/main.yml. That way, we get a clean base role that can be reused across hosts and environments with only variable overrides.

The core variables for this role are defined as:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


---
# Core configuration (commonly overridden)
node_exporter_version: "1.10.2"
node_exporter_user: "node_exporter"
node_exporter_group: "node_exporter"
node_exporter_work_dir: "/tmp/node_exporter"

node_exporter_arch: "linux-amd64"
node_exporter_archive_name: "node_exporter-{{ node_exporter_version }}.{{ node_exporter_arch }}.tar.gz"

node_exporter_port: 9100
node_exporter_listen_address: "{{ ansible_host }}:{{ node_exporter_port }}"

Preparation

It is worth setting up the environment before directly jumping into the installation. That way, we avoid cluttering our host and maintain a clean state. The environment will also help us in achieving:

Security: The Node Exporter should not run as root or with escalated privileges. Instead, we will create a system user and group for the exporter.
Isolation: All operations such as download, extractions, etc. will reside in a temporary work directory, keeping the host system clean and unaffected.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19


---
- name: Create node_exporter group
 ansible.builtin.group:
 name: "{{ node_exporter_group }}"
 system: true

- name: Create node_exporter user
 ansible.builtin.user:
 name: "{{ node_exporter_user }}"
 group: "{{ node_exporter_group }}"
 system: true
 shell: /usr/sbin/nologin
 create_home: false

- name: Create Node Exporter work directory
 ansible.builtin.file:
 path: "{{ node_exporter_work_dir }}"
 state: directory
 mode: "0755"

These tasks ensure Node Exporter runs as a non-privileged system user and the work directory provides the isolation layer by keeping all temporary files contained.

Installation

Download

We can use Ansible’s built-in get_url module for downloading the release archive:

1
2
3
4
5
6


---
- name: Get Node Exporter release
 ansible.builtin.get_url:
 url: "{{ node_exporter_release_url }}"
 dest: "{{ node_exporter_archive_path }}"
 mode: "0644"

As an added layer of safety, especially in production, add a checksum value to verfy the downloaded archive

The values for url and dest are derived variables, defined in the defaults/main.yml as:

1
2


node_exporter_release_url: "https://github.com/prometheus/node_exporter/releases/download/v{{ node_exporter_version }}/{{ node_exporter_archive_name }}"
node_exporter_archive_path: "{{ node_exporter_work_dir }}/{{ node_exporter_archive_name }}"

Unarchiving

The downloaded release is a Tar file, so we cannot use it directly. Instead, we will be using Ansible’s built-in unarchive module:

1
2
3
4
5


- name: Unarchive Node Exporter
 ansible.builtin.unarchive:
 src: "{{ node_exporter_archive_path }}"
 dest: "{{ node_exporter_work_dir }}"
 remote_src: true

Setting remote_src: true tells Ansible that the archive already exists on the remote host, so the unarchiving process happens on the remote host itself.

Installation

The final step in this phase is installing the exporter binary. We defined our helper derived variables in defaults/main.yml:

1
2
3
4


node_exporter_extracted_name: "node_exporter-{{ node_exporter_version }}.{{ node_exporter_arch }}"
node_exporter_extracted_dir_path: "{{ node_exporter_work_dir }}/{{ node_exporter_extracted_name }}"
node_exporter_extracted_bin_path: "{{ node_exporter_extracted_dir_path }}/node_exporter"
node_exporter_bin_path: "/usr/local/bin/node_exporter"

/usr/local/bin/ would make Node Exporter available system-wide and is the recommended installation path

We copy the exporter from our temp work directory to the /usr/local/bin directory:

1
2
3
4
5
6
7


- name: Install the Node Exporter binary
 ansible.builtin.copy:
 src: "{{ node_exporter_extracted_bin_path }}"
 dest: "{{ node_exporter_bin_path }}"
 remote_src: true
 mode: "0755"
 notify: Restart node_exporter

Setting mode: "0755" ensures the binary is executable by all users while remaining writable only by the owner.

Notice the notify part at the end of the task. A change in binary ensures the service is only restarted when the binary actually changes. The handler Restart node_exporter is implemented in handlers/main.yml:

1
2
3
4
5


---
- name: Restart node_exporter
 ansible.builtin.systemd:
 name: "{{ node_exporter_service_name }}"
 state: restarted

Configure

At this point, we managed to download and extract the exporter’s binary. The next step is to create systemd unit for the exporter. Using systemd ensures the exporter is managed consistently, starts on boot, and can be controlled via standard system tooling.

This can be done through a two-step process:

Create the systemd unit file
Enable and start the service

Systemd Unit File

The systemd unit file will be implemented as a jinja template. The file templates/node_exporter.j2.service:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


[Unit]
Description=Prometheus Node Exporter
Wants=network-online.target
After=network-online.target

[Service]
User={{ node_exporter_user }}
Group={{ node_exporter_group }}
Type=simple
NoNewPrivileges=yes
PrivateTmp=yes
ProtectSystem=full
ProtectHome=yes
ExecStart={{ node_exporter_bin_path }} --web.listen-address={{ node_exporter_listen_address }}

[Install]
WantedBy=multi-user.target

Additional systemd options such as NoNewPrivileges and ProtectSystem are used to provide basic service hardening and reduce the potential attack surface.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


---
- name: Create Node Exporter systemd service
 ansible.builtin.template:
 src: node_exporter.j2.service
 dest: "{{ node_exporter_unit_path }}"
 mode: "0644"
 notify:
 - Restart node_exporter

- name: Enable and start {{ node_exporter_service_name }}
 ansible.builtin.systemd:
 name: "{{ node_exporter_service_name }}"
 enabled: true
 state: started
 daemon_reload: true

The variables needed here can be defined as:

1
2


node_exporter_unit_path: "/etc/systemd/system/{{ node_exporter_service_name }}.service"
node_exporter_service_name: "node_exporter"

Cleanup

The final stage for this role is to perform cleanup. Since all intermediate artifacts are stored in a single working directory, it can be removed entirely through a single task:

1
2
3
4
5


---
- name: Remove Node Exporter work directory
 ansible.builtin.file:
 path: "{{ node_exporter_work_dir }}"
 state: absent

Main.yml

The role ties the phases together in tasks/main.yml:

1
2
3
4
5


---
- import_tasks: prepare.yml
- import_tasks: install.yml
- import_tasks: configure.yml
- import_tasks: cleanup.yml

This now finally completes our Node Exporter role.

Example Playbook

The final step is to actually use our role and run it on our target hosts. To do that, we will create playbooks/node_exporter.yml:

1
2
3
4
5
6
7
8


---
- name: Set up Node Exporter on target nodes
 hosts: target_hosts
 become: true
 roles:
 - node_exporter
 tags:
 - node_exporter

Then we run our playbook using the command:

1

ansible-playbook -i inventory playbooks/node_exporter.yml --tags=node_exporter

Installing a Different Version

You can override the version, 1.10.2, without doing any modifications to the role. For example, if we want to use 1.10.0 instead, then we override the node_exporter_version and node_exporter_checksum values:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


- name: Install Node Exporter
 hosts: vm-1
 become: true
 gather_facts: true
 vars:
 node_exporter_version: 1.10.0
 node_exporter_checksum: "sha256:6c2a4d886fc82743f7f97b8e0a0cd80ab0199939edce3cf0b9b36dad8d48d9b4"
 roles:
 - node_exporter
 tags:
 - node_exporter

Verification

Once the playbook finishes execution, we can verify the exporter is successfully configured and setup by:

Checking the service is running

1

sudo systemctl status node_exporter

Confirm the exporter is listening on port 9100

1

ss -ltn | grep 9100

Query the endpoint

1

curl http://<ansible_host>:9100/metrics

We can also create a dedicated Ansible task for performing the verification for us, making it more suitable for a production environment.

Conclusion

In this post, we built a reusable Ansible role for deploying Node Exporter. By structuring the role into clear phases and driving it through variables, we ensure maintainability and consistency across environments. The role is also written to be easily adjustable by modifying variables without changing the internal implementation.

The complete source code for this post can be found on GitHub.

In the next post, we will build on this foundation by deploying Prometheus and configuring it to scrape metrics from our exporters.