Hi Guys !! Welcome to my blog where concepts are taught in a fun way. This is continuing part of series. In this we will try to understand Prometheus Architecture , Metrics and Instrumentation.
Prometheus Architecture ( Funny Version )
Components of Prometheus ( Fun Version )
Prometheus Server — Detective Prom’s Headquarters
In the middle of everything is the Prometheus Server — this is Detective Prom’s headquarters. It’s where all the data (clues) from different suspects (targets) is gathered, stored, and analyzed. Prom is constantly working here, retrieving metrics and storing them in the TSDB (Time-Series Database), which is like his extensive archive of case files.
Metrics Retrieval — Prom’s Daily Patrol
Prom goes on his daily patrols, checking in on different parts of the city (your infrastructure). He does this by visiting the /metricsendpoints of exporters (which are like Prom’s snitches), collecting data from them. This data includes all sorts of details about what’s going on in the city—CPU usage, memory stats, and more.
[ Good Read: Monitoring and Observability With Prometheus]
Exporters — The Snitches
The exporters are the snitches who gather information from various parts of the system (like apps, servers, etc.). They know everything that’s happening and report back to Prom via the /metrics endpoint. Prom regularly visits these snitches to collect all the juicy details.
Push Gateway — The Drop Point
Sometimes, Prom can’t always check on certain suspects because they only appear occasionally (like batch jobs). For those cases, Prom sets up a Push Gateway, which acts like a drop point. These batch jobs push their metrics to the Push Gateway, and Prom collects them when he’s available.
Service Discovery — Prom’s Network of Informants
Prom doesn’t manually keep track of all the suspects in the city. Instead, he has a network of informants, which includes Kubernetes, Consul, and File SD. These informants let him know when new suspects appear or when existing ones change locations, ensuring that Prom’s target list is always up to date.
Alert manager — Prom’s Sidekick
Prom isn’t just about collecting data — he’s also about taking action when something goes wrong. That’s where Alert manager comes in. If Prom sees something suspicious (like a server going down), he tells Alert manager, who then notifies the right people via Slack, email, or xmatters. These are the channels through which the SWAT team (DevOps engineers) gets alerted to solve the issue.
PromQL — Detective Prom’s Secret Code
When Prom needs to solve a case, he dives into his archives using PromQL, his secret code language. This helps him pull out exactly the information he needs from the tons of data stored in his TSDB.
Grafana — The Forensic Artist
Prom loves visual aids, so he works with Grafana, the forensic artist, to create detailed graphs and dashboards. Grafana takes all of Prom’s case files and turns them into visuals that are easy to understand. Prometheus’s Web UI and Grafana are where these visualizations live, making it easier to see patterns and trends in the data.
Node Local Storage — Prom’s Filing Cabinet
All the case files Prom collects need to be stored somewhere safe, so he uses Node Local Storage — his sturdy filing cabinet where all the data is kept in order.
API — Prom’s Hotline
Lastly, there’s an API that acts like Prom’s hotline. Other tools or services can call up Prom to get specific data whenever they need it, making it easy to integrate Prometheus with other systems.
Data Model (Time Series Data and Metrics)
Boring Version Definition
In Prometheus, data is stored in the form of time series. A time series is essentially a sequence of data points, each associated with a specific timestamp. These data points are called metrics, which represent the state or performance of a system at a particular time.
Fun Version
Imagine Prometheus as a seasoned detective (Detective Prom), and time series data as his case files.
You can check more info about: Prometheus — The Prom King.