Hello and welcome to this presentation on an Introduction to Prometheus.
In this video presentation, I'll cover the following topics.
I'll begin with a high level look at what Prometheus is and some of its features.
Then I'll discuss some of the key components of the Prometheus architecture.
Next, I'll move on to a deeper dive into the Prometheus data model, following up with a
look at the Prometheus query language. Prometheus is an open source monitoring and
alerting system. Prometheus stores data in a highly optimized
time-series database. Time series data are data points indexed in
time order. Time series data provides a historical view,
which aids in understanding what is happening in an application by comparing when the application
was healthy to when it became broken. Prometheus is a multi-dimensional data model
for collecting millions of time-series events. You can monitor anything about the application,
like the number of requests, successful or failed, its CPU usage, and memory allocation.
Each time series event is uniquely identified by a metric name and a set of key-value pairs,
also known as labels. Prometheus has its own query language called
PromQL which is optimized for time series queries.
Prometheus uses a pull model, which means it scrapes metrics from applications.
Data collection happens over HTTP. This means the Prometheus service pulls or
scraps stats from applications at specific end points.
In contrast, the push model architecture has agents that expose these metrics to a backend
server. Operationally, with pull-based architectures
each application is responsible for exposing its own stats.
The diagram on the slide shows the components of the Prometheus architecture.
I ll describe the function of some of these key components.
The Prometheus Server - Prometheus architecture is pretty straightforward.
The server is a single binary with a configuration file.
It provides basic networking, optimized storage database, and a query language frontend to
the Prometheus interface. Service Discovery Prometheus discovers targets
to scrape from the service discovery. This is how Prometheus knows what to monitor,
and whether the targets it s suppose to monitor are responding.
These can be from services like Kubernetes and other common instruments like EC2 and
Consul. Client libraries are libraries that help you
create custom metrics for Prometheus to scrape. Before you can monitor your services, you
need to add instrumentation to their code via one of the Prometheus client libraries.
You choose a Prometheus client library that matches the language in which the application
is written. This lets you define and expose internal metrics
via HTTP endpoints on your application s instance. Exporters In many cases you cannot instrument
a given system with Prometheus metrics directly, for example, third-party software that exposes
metrics in a non-Prometheus format. An exporter is a piece of software that you
deploy next to the application from which you want to scrape metrics.
Exporters collects requests from Prometheus, gathers the required data from the application,
and then converts them into Prometheus metrics. Exporters, just like instrumented services,
exposes these metrics through an endpoint, which are then scraped by Prometheus.
Prometheus also has a push gateway you can use for small batch jobs, for example, data
from targets that can t be pulled, like transient jobs or jobs behind firewalls.
The next topic is a discussion on the type of metrics.
Prometheus client libraries offers four metric types which you can use to generate one or
multiple time series. The first one we re going to talk about is
a counter. A counter is a metric which is a numerical
value that is only incremented, never decremented. Examples of a counter metric are the total
amount of requests served, or how many exceptions that occur.
Gauge is a metric similar to the counter. Gauges are numerical values that can go either
up or down. Think of things like memory usage, CPU usage,
the amount of threads, and perhaps temperature. Histogram is a metric that samples observations.
After being scraped, a histogram provides multiple time series, including one for each
bucket, one for the sum of all values, and one for the count of the events that have
been observed. A typical use case of a histogram is the measuring
of response times. Summary is similar to a histogram, but it
also calculates configurable statistical quantiles. You can also refer to the link on the slide
for more information on Prometheus metric types.
Now we ll explore some of the characteristics of the Prometheus data model.
As previously stated, Prometheus stores all data as time series.
Time series values belong to the same metric and the same labels.
The labels are what makes the metrics multidimensional. For example, let s say you want to monitor
the total number of HTTP requests on an API, you could create a metric named like the one
shown in the first code box. Now, to make this metric multidimensional,
you add labels. Labels are the simple key value pairs.
So, using the HTTP requests metric above, you can attach a label named method, that
takes the HTTP method GET as a value. To add more dimensionality, other labels could
include the endpoint that is called on the API, and the HTTP status returned by the server
for that request. The notation for a metric like that is represented
in the second code box. Now let s take a look at a time series example.
The table on the slide represents a time series based on two different sampling values of
the metric from the previous slide. The series returned a value for the number
of times an HTTP request returned the status code of either 200 or 500.
Time series data provides insights to the state and performance of monitored resources.
We'll now begin the demonstration portion of this video.
I'm logged into my master as a regular user. I'll show that I have Oracle Cloud Native
Environment deployed with a 2-node Kubernetes cluster, one master and one worker.
I'll view the namespaces and show we have the istio-system namespace along with the
default namespace and the kube namespaces. I'll show the pods in the istio-system namespace.
Notice that the grafana and prometheus pods are running in this namespace.
I'll view the services in the istio-system namespace.
Again notice the grafana and prometheus services. Notice the prometheus service is TYPE ClusterIP
and the node is TCP port 9090. I need to change the TYPE from ClusterIP to
NodePort so I'm going to edit this service and made this change.
Now I'll view the services again in the istio-system namespace.
Notice the TYPE for the prometheus service is now NodePort and the PORTS now contains
an additional value, which in this example is 31485.
From a browser, use this port value, along with the IP address of the master or worker
node, to bring up the Prometheus GUI. To
verify that Prometheus is serving metrics about itself, navigate to its own metrics
endpoint by replacing graph with metrics. I'll search the page for the metrics of the
type promhttp to confirm data collection. This time series data helps view the state
and performance of Prometheus. Another way to view the data Prometheus has
collected is to use the expression browser. I'll start to type prometheus_http and then
select requests_total. Press the Execute button to view the data.
I'm in Console mode but I can also view a graph.
I click the stacked button and also make a couple additional changes.
Hold you mouse over the graph or scroll down to view details.
You can click the Help button to get more information on using the expression browser.
To summarize, we covered the key features and the architecture of Prometheus.
The presentation discussed the characteristics and power of the Prometheus multidimensional
data model. Hope viewing this video provided you with
an introduction to Prometheus. This concludes this presentation. Thanks for
watching.