Book Image

Hands-On Infrastructure Monitoring with Prometheus

By : Joel Bastos, Pedro Araújo
Book Image

Hands-On Infrastructure Monitoring with Prometheus

By: Joel Bastos, Pedro Araújo

Overview of this book

Prometheus is an open source monitoring system. It provides a modern time series database, a robust query language, several metric visualization possibilities, and a reliable alerting solution for traditional and cloud-native infrastructure. This book covers the fundamental concepts of monitoring and explores Prometheus architecture, its data model, and how metric aggregation works. Multiple test environments are included to help explore different configuration scenarios, such as the use of various exporters and integrations. You’ll delve into PromQL, supported by several examples, and then apply that knowledge to alerting and recording rules, as well as how to test them. After that, alert routing with Alertmanager and creating visualizations with Grafana is thoroughly covered. In addition, this book covers several service discovery mechanisms and even provides an example of how to create your own. Finally, you’ll learn about Prometheus federation, cross-sharding aggregation, and also long-term storage with the help of Thanos. By the end of this book, you’ll be able to implement and scale Prometheus as a full monitoring system on-premises, in cloud environments, in standalone instances, or using container orchestration with Kubernetes.
Table of Contents (21 chapters)
Free Chapter
1
Section 1: Introduction
5
Section 2: Getting Started with Prometheus
11
Section 3: Dashboards and Alerts
15
Section 4: Scalability, Resilience, and Maintainability

Chapter 9, Defining Alerting and Recording Rules

  1. This type of rules can help take the load off heavy dashboards by pre-computing expensive queries, aggregate raw data into time series that can then be exported to external systems, and assist the creation of compound range vector queries.
  2. For the same reasons as in scrape jobs, queries might produce erroneous results when using series with different sampling rates, and having to keep track of what series have what periodicity becomes unmanageable.
  3. instance_job:latency_seconds_bucket:rate30s needs to have at least the instance and job labels. It was calculated by applying the rate to the latency_seconds_bucket_total metric, using a 30-second range vector. Thus, the originating expression could probably be as follows:
rate(latency_seconds_bucket_total[30s])
  1. As that label changes its value, so will the identity of the alert.
  2. An...