Running Prometheus Docker container for monitoring Microservices on Raspberry Pi

Estimated Reading Time: 5 minutes

In the previous post, we talked about running Nagios container on Raspberry Pi for the first time.Nagios is a free and open source monitoring and alerting service which basically collects the statistics of your server using agents like nrpe, check_mk or using SNMP and sends the alert if the metric value is above the predefined threshold. It is a great tool for monitoring the nodes or monolithic application but with the advent of the ‘microservices’ architecture and Docker, monitoring the small piece of services running across the cluster becomes very important.With that also grows the need to monitor these services around the clock, to maintain the healthy functioning of the application.

pi33

One of the most talked-about monitoring tools are Prometheus & Grafana. Prometheus is an open-source systems monitoring and alerting toolkit written in Go. It is a next-generation monitoring system and well appreciated by Docker Core Engineering Team. It’s a service especially well designed for containers and provides perspective about the data intensiveness of this new age and how even Internet scale companies have had to adapt.

On the other hand, Grafana can be rightly called the face of Prometheus. It is also an open-source, general purpose dashboard and graph composer, which runs as a web application. It supports graphite, influxdb or opentsdb as backends. While Prometheus exposes some of its internals like settings and the stats it gathers via basic web front-ends, it delegates the heavy lifting of proper graphical displays and dashboards to Grafana. For anyone who want to collect metrics from the development environment to be graphed and measured, Prometheus as time series store and Grafana as a visualization tool is the perfect solution.

What’s unique about Prometheus?

Prometheus is a self-hosted set of tools which collectively provide metrics storage, aggregation, visualization and alerting. Usually most of the available monitoring tools are push based, i.e. agents on the monitored servers talk to a central server (or set of servers) and send out their metrics. Prometheus is little different on this aspect – It is a pull based server which expects monitored servers to provide a web interface from which it can scrape data. This is a unique characteristic of Prometheus.

The main features of Prometheus can be summed below:

  • Decentralized architecture
  • Scalable data collection
  • Powerful Query language (leverages the data model for meaningful alerting (including easy silencing) and graphing (for dashboards and for ad-hoc exploration).
  • A multi-dimensional data model.( data can be sliced and diced at will, along dimensions like instance, service, endpoint, and method)
  • No reliance on distributed storage; single server nodes are autonomous.
  • Time series collection happens via a pull model over HTTP.
  • Pushing time series is supported via an intermediary gateway.
  • Targets are discovered via service discovery or static configuration.
  • Multiple modes of graphing and dashboard support.

You can deep dive more into its architecture at https://prometheus.io/docs/introduction/overview/#architecture.

I was in need of lightweight monitoring tool like Prometheus and Fancy UI like Grafana for my Raspberry Pi which I can spin up as Docker container in few seconds and then grow /spread it across the cluster primarily to test it for Docker 1.12 Swarm Mode. Unfortunately, I didn’t find any Docker image for Prometheus. I decided to build one for myself to explore it on Raspberry Pi 3 box.

After spending considerable amount of time on Pi box, I was able to build the first Prometheus Docker image and pushed it to Dockerhub. In case you are interested, check out my github page : https://github.com/ajeetraina/prometheus-armv7 to build and run your own Prometheus container.

[Thanks to Alex Ellis, #Docker Captain for reviewing this container and cleaning the Dockerfile.]

 

pi3

Running Prometheus & Grafana Docker Image on Raspberry Pi

Follow the below command to spin up Prometheus container on the fly:

pi11

Luckily, there was already a Grafana ARM image available in Dockerhub which I spent no minute to spin up easily as shown below:

 

pi22

You can also use docker-compose to bring up both the container in a single shot as shown:

pi@raspberrypi:~/testingPi $ cat docker-compose.yml

prometheus:
image: ajeetraina/prometheus-armv7
volumes:
– ./prometheus.yml:/etc/prometheus/prometheus.yml
command:
– ‘-config.file=/etc/prometheus/prometheus.yml’
ports:
– ‘9090:9090’

grafana:
image: fg2it/grafana-armhf:v3.1.1
environment:
– GF_SECURITY_ADMIN_PASSWORD=collabnix

ports:
– “3000:3000”

Ensure that you have either sample or your own customized prometheus.yml file under / directory to run this container.

Just one command and you are ready to spin up both the containers as shown below:

pi432pi90

That’s it. Browse to http://<ipaddress>:9090 to check out the Prometheus UI.

pi323

Also, Browse to http://<ipaddress>:3000 to open up fancy Grafana UI as shown below. Supply admin/collabnix as credentials to enter into Grafana UI.

graf2

Importing Prometheus Data into Grafana

Once you login into Grafana UI, click on Data Sources followed by “Add Data Source” button. You will find the below screen:

pi44

Next, Let’s import the prometheus into Grafana dashboard:

import

pi2345

I firmly believe that the newly built Prometheus container is sure to help developers to monitor their microservice application on top of Raspberry Pi box.In the next post, I will talk about the other available data sources and how it integrates with Prometheus and Grafana as a monitoring stack in detail.

Demonstrating Docker 1.12 Service Discovery with Docker Compose

Estimated Reading Time: 4 minutes

CofvQBxUAAE1UpT

Docker 1.12 is GA now. Thanks to Docker Inc. core Team and community support for releasing it on time as promised during DockerCon 2016.In my earlier post, I briefed around Service Discovery concept and how does it work in terms of  Swarm Mode. As we are well aware, Swarm Mode is an optional mode which can be ON and OFF based on your choice and requirement. Under this blog post, I am going to demonstrate service discovery while playing around with docker-compose.

Compose

I have a Ubuntu 16.04 machine upgraded with Docker 1.12 GA version. I have docker-compose 1.8.0 running on the same machine. To demonstrate how one service discover others through hostname, I am going to build a very simple Nginx application and a proxy which redirects to the default Nginx web application through the following structure:

Docker_11

The collabapp contains a very simple Dockerfile which pulls nginx running alpine image from Dockerhub.

Docker_12

 

The collabproxy contains Dockerfile to use the same nginx image with the customized proxy.conf. All it does is whenever there is any request coming to port: 80 will be redirected to http://collabapp which is nothing but a container running web application.

Docker_13

A quick look at docker-compose.yml file:

Docker_19

One thing which you would notice here is that we are NOT providing any “link:” parameter for linking both the services. Docker 1.12 handles this service name aspect internally through the in-built service discovery concept.

Let’s build up the containers using docker-compose as shown below:

Docker_14

Let’s bring up both the containers:

Docker_15

There are two services running – test_collabapp_1 and test_collabproxy_1. You can view the services running in a single shot as shown:

Docker_16

Let’s try to reach out to collabapp from within collabproxy using hostname and see if internal DNS resolves that or not.

Docker_16

As shown above, we are able to ping web application from proxy container using hostname.

To see how does it resolve that hostname, let us look up few interesting files inside the container:

Docker_17

Also, the mount command too shows how the /etc/resolv.conf, /etc/hostname and related files are created for service discovery to be enabled.

Docker_18

The 127.0.0.11 is an embedded DNS server which enables the service discovery functionality.The embedded DNS server is really a light weight server only interested in responding to container name/alias queries and for everything else it just acts as the proxy to any other DNS server.There is a socket created in the container namespace and which listens on it in the daemon itself and respond queries using that. The socket acts as the demux identifier to identify the network in case of unqualified name queries.

Let’s look at an interesting aspect of Service Discovery while we scale the service to run multiple containers across the same machine.

Docker_20

Now, the docker-compose ps shows scaled value of 5.

Docker_21

If you enter into collabproxy container and try to check the nslookup output:

Docker_23

Wow ! The command returned five different IP addresses from in-built DNS and all it does is round-robin DNS to load-balance across those 5 different containers.