Prometheus

Deploying Prometheus and Grafana on Kubernetes

Monitoring a Kubernetes Cluster is the need of the hour for any application following a microservices architecture. There are a bunch of solutions that one can implement to monitor their Kubernetes workload and one of them is Prometheus and Grafana. This article will help you to deploy Prometheus and Grafana in your kubernetes cluster with the help of prometheus-operator.

But before setting up these components let’s understand a bit about each of them.

Prometheus is a pull-based open-source monitoring and alerting tool originally built by SoundCloud. It works on a time-series database and scrapes metrics at a given interval from HTTP endpoints. After Kubernetes, Prometheus joined the Cloud Native Computing Foundation in 2016 as the second hosted project.

Alertmanager

The Alertmanager takes care of alerts sent by alerting tools such as the Prometheus server. It handles grouping, silencing, and routing them to the correct receiver integration such as email, PagerDuty, Slack, etc. It also supports the inhibition of alerts.

Grafana

Grafana is the visual representation of metrics collected by a data source which in our case happens to be Prometheus. We can create or import dashboards for grafana which will make use of promQL to visually represent metrics collected by Prometheus.

A Detailed Guide to Key Metrics of MongoDB Monitoring

In the current era, organizations demand high-quality working data, and management systems that can scale, deploy quickly, robustly, are highly available, and highly secure for any unfortunate incidents. Traditionally, applications used relational databases as the primary data stores but in today’s need for data-driven applications, developers lean towards alternative databases like NoSQL(Not Only Structured Query Language).

NoSQL databases enable speed, flexibility, and scalability in this era of growing development in the cloud. Moreover, NoSQL databases also support JSON-like documents which are commonly used formats to share data in modern web applications.

Azure HA Kubernetes Monitoring using Prometheus and Thanos

Introduction

Long since Prometheus took on the role of monitoring the systems, it has been the undisputed open-source leader for monitoring and alerting in Kubernetes systems, it has become a go-to solution. While Prometheus does some general instructions for achieving high availability but it has limitations when it comes to data retention, historical data retrieval, and multi-tenancy. This is where Thanos comes into play. In this blog post, we will discuss how to integrate Thanos with Prometheus in Kubernetes environments and why one should choose a particular approach. So let’s get started.

MongoDB Setup on Kubernetes using MongoDB Operator

MongoDB is a popular NoSQL database that supports large as well as small size of datasets. Just like any other database standalone setup, MongoDB is straightforward but we have to make a replicated or shared cluster of MongoDB, and there we have certain complications. Especially if we are doing these kinds of setups in orchestration tools like Kubernetes.

There is a lot of complexity in setting up MongoDB on Kubernetes that people(including me) have faced for a long time which I would like to highlight:-

Standalone setup is pretty straightforward but for replicated and sharded clusters additional mongo configurations are required.
In the replicated scenario, separate configurations need to be managed for the leader and follower.
Monitoring and access management of MongoDB inside Kubernetes is a little tricky part to handle.

Autoscaling in Nomad Cluster

We are living in the microservice era, where we have a number of applications to support a business model. But our application success cannot be determined by the features only, it should have a scalable model as well. Otherwise, something like this would happen:-

When we generally talk about the scaling in the microservices, people think that applications that are running inside Kubernetes as containers. Since Kubernetes has its own method of autoscaling using the metrics-server, we don’t have to worry about the scaling of the applications inside it.