Prometheus Archives - DEVOPS DONE RIGHT

Agentless Monitoring: Integrating Supabase Metrics with Grafana Cloud

The Power of Agentless Monitoring

Before we dive into the technicalities, let’s understand the core benefits of agentless monitoring. It’s like having a silent guardian for your application, one that doesn’t require the extra resources or management overhead that traditional agents do. This means less complexity, less maintenance overhead, and better accuracy in your monitoring.

TLDR; If you have a service exposing prometheus compatible endpoint, then you can scrape those metrics directly with services like Grafana Cloud without needing any intermediate agent.

Why Supabase and Grafana Cloud

Supabase is making waves as a top pick for developers needing a backend service, thanks to its solid PostgreSQL base and ease of use.

Grafana Cloud brings a lot to the table, with its easy-to-use features like drag-and-drop dashboards, smart alerts, and even some clever machine learning tricks to help you spot and fix problems before they blow up. In short, Grafana Cloud doesn’t just make monitoring simpler; it makes it smarter, helping developers keep their apps running smoothly and their users happy.

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

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.