## 1. Project Overview & Quickstart (prometheus/ContribFest.pdf) # ContribFest.pdf Open-source repository prometheus/ContribFest.pdf ### Repository Details - **Repository:** [prometheus/ContribFest.pdf](https://github.com/prometheus/ContribFest.pdf) - **Primary Language:** Code *Note: High-volume repository documentation is actively indexed and synchronized by YakaAI.* ## 2. Official Technical Reference & Guides (prometheus/docs) ## File: blog/README.md # Prometheus Blog Content Guide The Prometheus blog exists to share what’s happening in and around the Prometheus project. It’s a space for updates, tutorials, deep dives, and stories from the community. Our goal is to keep Prometheus users and contributors informed and engaged. ## What belongs on the blog? We feature posts that help people learn, stay up to date, or feel more connected to the project. That could mean announcing new releases, explaining how a feature works, or walking readers through a setup guide. It might also mean sharing how your organization uses Prometheus, talking about a recent event, or reflecting on your journey as a contributor. What doesn’t belong are ads, marketing pitches, or reposts from company blogs. We want posts that feel original, useful, and rooted in the spirit of open source collaboration. ## How should posts be written? We understand that everyone has their own writing style, and we’d hate to cramp yours. So, there are no rigid rules around style. But here a few formatting guidelines to keep the posts consistent: - **Headings:** See [this guide for headings](../markdown-guide.md#proper-usage-of-heading-levels). - **Links:** Add them with descriptive text instead of just dropping the raw URL. Example: `[Prometheus documentation](https://prometheus.io/docs/introduction/overview/)`. - **Images and diagrams:** Always include alt text so the content is accessible to everyone. Store images in the `/public/assets` folder (instead of linking from external sites) and reference them in your post. > [!NOTE] > See the general [Markdown Documentation Formatting Guide](../markdown-guide.md) for more formatting rules. The tone should be friendly and professional. If you’re not sure what that looks like, take a look at some of the [previously published posts](https://prometheus.io/blog/) on the blog for inspiration. Most posts fall somewhere between 800 words (like [this short announcements](https://prometheus.io/blog/2023/09/01/promcon2023-schedule/)) and 1500 words (like [this long deep dive](https://prometheus.io/blog/2021/11/16/agent/)). If you include code snippets or configuration examples, please make sure they work as written. Diagrams or screenshots are also great additions if they help readers grasp complex ideas more quickly. When multiple people contribute to a post, we’ll make sure everyone is credited at the end. > [!IMPORTANT] > After your introductory section, add a `` marker on its own line. This marker indicates where the preview cuts off on https://prometheus.io/blog/. See the example below. **Example structure:** ```markdown --- title: "Getting Started with Prometheus" author: Your Name (@yourgithubusername) date: 2025-11-02 --- Prometheus makes it easy to collect and query metrics from your applications. In this post, we'll walk through setting up your first metrics endpoint and understanding what Prometheus collects. ## Installing Prometheus First, let's get Prometheus installed on your system... ``` ## How to contribute If you’d like to write for the blog, the process is simple: 0. Find a sponsor (a [maintainer](https://github.com/prometheus/prometheus/blob/main/MAINTAINERS.md) with expertise in your topic area), discuss your post idea with them, and see if they can sponsor your post. > [!IMPORTANT] > **For Sponsors:** > By agreeing to sponsor a post, you are committing to reviewing the post PR for technical accuracy and > merging it once you are satisfied it meets the required standard. 1. Create an issue in the `prometheus/docs` repo using the [Blog Post Proposal template](https://github.com/prometheus/docs/issues/new?template=blog-post-proposal.yml). 2. Wait for feedback from maintainers or editors to confirm it’s a good fit. 3. Draft your post in Markdown and submit it as a pull request. 4. Go through the review process, where we’ll help refine the draft together. 5. Once it’s approved, we’ll merge and publish it on the blog. 🎉 6. Share your post on your socials and feel free to tag us so we can boost it too. ## Review process Every post should be reviewed before it goes live. Whoever reviews the pull request will check for both technical accuracy and editorial quality. This ensures that the content is both correct and accessible. In some cases, these might be done by different people, but often one reviewer can cover both. ## Why contribute? Contributing to the blog is a way to give back to the Prometheus community beyond code. It helps others learn from your experience and brings visibility to your work. Plus, non-code contributions like this count as real contributions. You’ll be joining the long list of people who’ve shaped Prometheus in meaningful ways. --- ## File: docs/visualization/browser.md --- title: Expression browser sort_rank: 1 --- The expression browser is available at `/graph` on the Prometheus server, allowing you to enter any expression and see its result either in a table or graphed over time. This is primarily useful for ad-hoc queries and debugging. For graphs, use [Grafana](/docs/visualization/grafana/) or [Console templates](/docs/visualization/consoles/). --- ## File: docs/visualization/consoles.md --- title: Console templates sort_rank: 4 --- CAUTION: Starting with Prometheus 3.0, console templates and libraries are no longer bundled with Prometheus. If you wish to use console templates, you must provide your own templates and libraries by specifying the `--web.console.templates` and `--web.console.libraries` command-line flags. This documentation page is maintained for historical reference and to demonstrate the capabilities of console templates. Please be aware that any referenced console libraries from the Prometheus 2.x branch are no longer maintained and may contain known security vulnerabilities (CVEs). Console templates allow for creation of arbitrary consoles using the [Go templating language](http://golang.org/pkg/text/template/). These are served from the Prometheus server. Console templates are the most powerful way to create templates that can be easily managed in source control. There is a learning curve though, so users new to this style of monitoring should try out [Grafana](/docs/visualization/grafana/) first. ## Getting started Prometheus comes with an example set of consoles to get you going. These can be found at `/consoles/index.html.example` on a running Prometheus and will display Node Exporter consoles if Prometheus is scraping Node Exporters with a `job="node"` label. The example consoles have 5 parts: 1. A navigation bar on top 1. A menu on the left 1. Time controls on the bottom 1. The main content in the center, usually graphs 1. A table on the right The navigation bar is for links to other systems, such as other Prometheis [1](/docs/introduction/faq/#what-is-the-plural-of-prometheus), documentation, and whatever else makes sense to you. The menu is for navigation inside the same Prometheus server, which is very useful to be able to quickly open a console in another tab to correlate information. Both are configured in `console_libraries/menu.lib`. The time controls allow changing of the duration and range of the graphs. Console URLs can be shared and will show the same graphs for others. The main content is usually graphs. There is a configurable JavaScript graphing library provided that will handle requesting data from Prometheus, and rendering it via [Rickshaw](https://shutterstock.github.io/rickshaw/). Finally, the table on the right can be used to display statistics in a more compact form than graphs. ## Example Console This is a basic console. It shows the number of tasks, how many of them are up, the average CPU usage, and the average memory usage in the right-hand-side table. The main content has a queries-per-second graph. ``` {{template "head" .}} {{template "prom_right_table_head"}} MyJob {{ template "prom_query_drilldown" (args "sum(up{job='myjob'})") }} / {{ template "prom_query_drilldown" (args "count(up{job='myjob'})") }} CPU {{ template "prom_query_drilldown" (args "avg by(job)(rate(process_cpu_seconds_total{job='myjob'}[5m]))" "s/s" "humanizeNoSmallPrefix") }} Memory {{ template "prom_query_drilldown" (args "avg by(job)(process_resident_memory_bytes{job='myjob'})" "B" "humanize1024") }} {{template "prom_right_table_tail"}} {{template "prom_content_head" .}}

MyJob

Queries

{{template "prom_content_tail" .}} {{template "tail"}} ``` The `prom_right_table_head` and `prom_right_table_tail` templates contain the right-hand-side table. This is optional. `prom_query_drilldown` is a template that will evaluate the expression passed to it, format it, and link to the expression in the [expression browser](/docs/visualization/browser/). The first argument is the expression. The second argument is the unit to use. The third argument is how to format the output. Only the first argument is required. Valid output formats for the third argument to `prom_query_drilldown`: * Not specified: Default Go display output. * `humanize`: Display the result using [metric prefixes](http://en.wikipedia.org/wiki/Metric_prefix). * `humanizeNoSmallPrefix`: For absolute values greater than 1, display the result using [metric prefixes](http://en.wikipedia.org/wiki/Metric_prefix). For absolute values less than 1, display 3 significant digits. This is useful to avoid units such as milliqueries per second that can be produced by `humanize`. * `humanize1024`: Display the humanized result using a base of 1024 rather than 1000. This is usually used with `B` as the second argument to produce units such as `KiB` and `MiB`. * `printf.3g`: Display 3 significant digits. Custom formats can be defined. See [prom.lib](https://github.com/prometheus/prometheus/blob/release-2.55/console_libraries/prom.lib) for examples. ## Graph Library The graph library is invoked as: ```
``` The `head` template loads the required Javascript and CSS. Parameters to the graph library: | Name | Description | ------------- | ------------- | expr | Required. Expression to graph. Can be a list. | node | Required. DOM node to render into. | duration | Optional. Duration of the graph. Defaults to 1 hour. | endTime | Optional. Unixtime the graph ends at. Defaults to now. | width | Optional. Width of the graph, excluding titles. Defaults to auto-detection. | height | Optional. Height of the graph, excluding titles and legends. Defaults to 200 pixels. | min | Optional. Minimum x-axis value. Defaults to lowest data value. | max | Optional. Maximum y-axis value. Defaults to highest data value. | renderer | Optional. Type of graph. Options are `line` and `area` (stacked graph). Defaults to `line`. | name | Optional. Title of plots in legend and hover detail. If passed a string, `[[ label ]]` will be substituted with the label value. If passed a function, it will be passed a map of labels and should return the name as a string. Can be a list. | xTitle | Optional. Title of the x-axis. Defaults to `Time`. | yUnits | Optional. Units of the y-axis. Defaults to empty. | yTitle | Optional. Title of the y-axis. Defaults to empty. | yAxisFormatter | Optional. Number formatter for the y-axis. Defaults to `PromConsole.NumberFormatter.humanize`. | yHoverFormatter | Optional. Number formatter for the hover detail. Defaults to `PromConsole.NumberFormatter.humanizeExact`. | colorScheme | Optional. Color scheme to be used by the plots. Can be either a list of hex color codes or one of the [color scheme names](https://github.com/shutterstock/rickshaw/blob/master/src/js/Rickshaw.Fixtures.Color.js) supported by Rickshaw. Defaults to `'colorwheel'`. If both `expr` and `name` are lists, they must be of the same length. The name will be applied to the plots for the corresponding expression. Valid options for the `yAxisFormatter` and `yHoverFormatter`: * `PromConsole.NumberFormatter.humanize`: Format using [metric prefixes](http://en.wikipedia.org/wiki/Metric_prefix). * `PromConsole.NumberFormatter.humanizeNoSmallPrefix`: For absolute values greater than 1, format using [metric prefixes](http://en.wikipedia.org/wiki/Metric_prefix). For absolute values less than 1, format with 3 significant digits. This is useful to avoid units such as milliqueries per second that can be produced by `PromConsole.NumberFormatter.humanize`. * `PromConsole.NumberFormatter.humanize1024`: Format the humanized result using a base of 1024 rather than 1000. --- ## File: docs/visualization/grafana.md --- title: Grafana support for Prometheus nav_title: Grafana sort_rank: 2 --- [Grafana](http://grafana.com/) is an open-source analytics and visualization platform used to monitor and analyze metrics from various data sources. It allows users to create, explore, and share interactive dashboards, supporting integrations with databases like Prometheus, InfluxDB, Elasticsearch, and more. Grafana is widely used for observability, providing alerting, plugin extensibility, and a flexible query editor for real-time data visualization. Note: The Grafana data source for Prometheus is included since Grafana 2.5.0 (2015-10-28). The following shows an example Grafana dashboard which queries Prometheus for data: [](/assets/docs/grafana_prometheus.png) ## Installing To install Grafana see the [official Grafana documentation](https://grafana.com/grafana/download/). ## Using By default, Grafana will be listening on [http://localhost:3000](http://localhost:3000). The default login is "admin" / "admin". ### Creating a Prometheus data source To create a Prometheus data source in Grafana: 1. Click on the "cogwheel" in the sidebar to open the Configuration menu. 2. Click on "Data Sources". 3. Click on "Add data source". 4. Select "Prometheus" as the type. 5. Set the appropriate Prometheus server URL (for example, `http://localhost:9090/`) 6. Adjust other data source settings as desired (for example, choosing the right Access method). 7. Click "Save & Test" to save the new data source. The following shows an example data source configuration: [](/assets/docs/grafana_configuring_datasource.png) ### Creating a Prometheus graph Follow the standard way of adding a new Grafana graph. Then: 1. Click the graph title, then click "Edit". 2. Under the "Metrics" tab, select your Prometheus data source (bottom right). 3. Enter any Prometheus expression into the "Query" field, while using the "Metric" field to lookup metrics via autocompletion. 4. To format the legend names of time series, use the "Legend format" input. For example, to show only the `method` and `status` labels of a returned query result, separated by a dash, you could use the legend format string `{{method}} - {{status}}`. 5. Tune other graph settings until you have a working graph. The following shows an example Prometheus graph configuration: [](/assets/docs/grafana_qps_graph.png) In Grafana 7.2 and later, the `$__rate_interval` variable is [recommended](https://grafana.com/docs/grafana/latest/datasources/prometheus/#using-__rate_interval) for use in the `rate`and `increase` functions. ### Importing pre-built dashboards from Grafana.com Grafana.com maintains [a collection of shared dashboards](https://grafana.com/grafana/dashboards/) which can be downloaded and used with standalone instances of Grafana. Use the Grafana.com "Filter" option to browse dashboards for the "Prometheus" data source only. You must currently manually edit the downloaded JSON files and correct the `datasource:` entries to reflect the Grafana data source name which you chose for your Prometheus server. Use the "Dashboards" → "Home" → "Import" option to import the edited dashboard file into your Grafana install. --- ## File: docs/visualization/perses.md --- title: Perses support for Prometheus nav_title: Perses sort_rank: 3 --- [Perses](https://perses.dev) is an open-source dashboard and visualization platform designed for observability, with native support for Prometheus as a data source. It enables users to create, manage, and share dashboards for monitoring metrics and visualizing data. Perses aims to provide a simple, flexible, and extensible alternative to other dashboarding tools, focusing on ease of use, community-driven development, GitOps capabilities and dashboard as code approach. Here is an example of a Perses dashboard querying Prometheus for data: [](/assets/docs/perses_prometheus.png) ## Installing To install Perses, see the official [Perses documentation](https://perses.dev/perses/docs/installation/in-a-container/). ## Using By default, Perses will be listening on port `8080`. You can access the web UI at `http://localhost:8080`. There is no login by default. ### Creating a Prometheus data source To learn about how to set up a data source in Perses, please refer to [Perses documentation](https://perses.dev/perses/docs/concepts/datasources). Once this connection to your Prometheus instance is configured, you are able to query it from the Dashboard and Explore views. ### Importing pre-built dashboards Perses is providing a set of pre-built dashboards that you can import into your instance. These dashboards are maintained by the community and can be found in the [Perses dashboard repository](https://github.com/perses/community-dashboards) --- ## File: docs/tutorials/alerting_based_on_metrics.md --- title: Alerting based on metrics sort_rank: 5 --- In this tutorial we will create alerts on the `ping_request_count` metric that we instrumented earlier in the [Instrumenting HTTP server written in Go](./instrumenting_http_server_in_go.md) tutorial. For the sake of this tutorial we will alert when the `ping_request_count` metric is greater than 5. Check out real world [best practices](../practices/alerting.md) to learn more about alerting principles. Download the latest release of Alertmanager for your operating system from [here](https://github.com/prometheus/alertmanager/releases). Alertmanager supports various receivers like `email`, `webhook`, `pagerduty`, `slack` etc through which it can notify when an alert is firing. You can find the list of receivers and how to configure them [here](/docs/alerting/latest/configuration/). We will use `webhook` as a receiver for this tutorial, head over to [webhook.site](https://webhook.site) and copy the webhook URL which we will use later to configure the Alertmanager. First let's setup Alertmanager with the webhook receiver. > alertmanager.yml ```yaml global: resolve_timeout: 5m route: receiver: webhook_receiver receivers: - name: webhook_receiver webhook_configs: - url: '' send_resolved: false ``` Replace `` with the webhook that we copied earlier in the alertmanager.yml file and run the Alertmanager using the following command. `alertmanager --config.file=alertmanager.yml` Once the Alertmanager is up and running navigate to [http://localhost:9093](http://localhost:9093) and you should be able to access it. Now that we have configured the Alertmanager with webhook receiver let's add the rules to the Prometheus config. > prometheus.yml ```yaml global: scrape_interval: 15s evaluation_interval: 10s rule_files: - rules.yml alerting: alertmanagers: - static_configs: - targets: - localhost:9093 scrape_configs: - job_name: prometheus static_configs: - targets: ["localhost:9090"] - job_name: simple_server static_configs: - targets: ["localhost:8090"] ``` Note that the `evaluation_interval`,`rule_files` and `alerting` sections were added to the Prometheus config. `evaluation_interval` defines the intervals at which the rules are evaluated, `rule_files` accepts an array of yaml files that defines the rules and the `alerting` section defines the Alertmanager configuration. As mentioned in the beginning of this tutorial we will create a basic rule where we want to raise an alert when the `ping_request_count` value is greater than 5. > rules.yml ```yaml groups: - name: Count greater than 5 rules: - alert: CountGreaterThan5 expr: ping_request_count > 5 for: 10s ``` Now let's run Prometheus using the following command. `prometheus --config.file=./prometheus.yml` Open [http://localhost:9090/rules](http://localhost:9090/rules) in your browser to see the rules. Next run the instrumented ping server and visit the [http://localhost:8090/ping](http://localhost:8090/ping) endpoint and refresh the page at least 6 times. You can check the ping count by navigating to the [http://localhost:8090/metrics](http://localhost:8090/metrics) endpoint. To see the status of the alert visit [http://localhost:9090/alerts](http://localhost:9090/alerts). Once the condition `ping_request_count > 5` is true for more than 10s the `state` will become `FIRING`. Now if you navigate back to your `webhook.site` URL you will see the alert message. Similarly Alertmanager can be configured with other receivers to notify when an alert is firing. --- ## File: docs/tutorials/instrumenting_http_server_in_go.md --- title: Instrumenting HTTP server written in Go sort_rank: 3 --- In this tutorial we will create a simple Go HTTP server and instrument it by adding a counter metric to keep count of the total number of requests processed by the server. Here we have a simple HTTP server with `/ping` endpoint which returns `pong` as response. ```go package main import ( "fmt" "net/http" ) func ping(w http.ResponseWriter, req *http.Request) { fmt.Fprintf(w,"pong") } func main() { http.HandleFunc("/ping", ping) http.ListenAndServe(":8090", nil) } ``` Compile and run the server ```bash go build server.go ./server ``` Now open `http://localhost:8090/ping` in your browser and you must see `pong`. [](/assets/docs/tutorial/server.png) Now let's add a metric to the server which will instrument the number of requests made to the ping endpoint. The counter metric type is suitable for this as we know the request count doesn’t go down and only increases. Create a Prometheus counter ```go type metrics struct { pingCounter prometheus.Counter } func newMetrics(reg prometheus.Registerer) *metrics { m := &metrics{ pingCounter: promauto.With(reg).NewCounter( prometheus.CounterOpts { Name: "ping_request_count", Help: "No of requests handled by Ping handler", }), } return m } ``` Next, let's update the ping Handler to increase the count of the counter using `metrics.pingCounter.Inc()`. ```go func ping(m *metrics) func(w http.ResponseWriter, req *http.Request) { return func(w http.ResponseWriter, req *http.Request) { m.pingCounter.Inc() fmt.Fprintf(w, "pong") } } ``` Then register the metrics (in this case, only one counter) with a Prometheus registry and expose the metrics. ```go func main() { reg := prometheus.NewRegistry() m := newMetrics(reg) http.HandleFunc("/ping", ping(m)) http.Handle("/metrics", promhttp.HandlerFor(reg, promhttp.HandlerOpts{})) http.ListenAndServe(":8090", nil) } ``` The `prometheus.MustRegister` function registers the pingCounter with the default registry. To expose the metrics, the Go Prometheus client library provides the promhttp package. `promhttp.Handler()` provides an `http.Handler` which exposes the metrics registered in the default registry. The sample code is now: ```go package main import ( "fmt" "net/http" "github.com/prometheus/client_golang/prometheus" "github.com/prometheus/client_golang/prometheus/promauto" "github.com/prometheus/client_golang/prometheus/promhttp" ) type metrics struct { pingCounter prometheus.Counter } func newMetrics(reg prometheus.Registerer) *metrics { m := &metrics{ pingCounter: promauto.With(reg).NewCounter( prometheus.CounterOpts{ Name: "ping_request_count", Help: "No of request handled by Ping handler", }), } return m } func ping(m *metrics) func(w http.ResponseWriter, req *http.Request) { return func(w http.ResponseWriter, req *http.Request) { m.pingCounter.Inc() fmt.Fprintf(w, "pong") } } func main() { reg := prometheus.NewRegistry() m := newMetrics(reg) http.HandleFunc("/ping", ping(m)) http.Handle("/metrics", promhttp.HandlerFor(reg, promhttp.HandlerOpts{})) http.ListenAndServe(":8090", nil) } ``` Run the example ```bash go mod init prom_example go mod tidy go run server.go ``` Now hit the localhost:8090/ping endpoint a couple of times and then send a request to localhost:8090/metrics to see the metrics. [](/assets/docs/tutorial/ping_metric.png) Here, the `ping_request_count` shows that the `/ping` endpoint was called 3 times. The default registry comes with a collector for Go runtime metrics, and that is why we see other metrics like `go_threads`, `go_goroutines`, etc. We have built our first metric exporter. Let’s update our Prometheus config to scrape the metrics from our server. ```yaml global: scrape_interval: 15s scrape_configs: - job_name: prometheus static_configs: - targets: ["localhost:9090"] - job_name: simple_server static_configs: - targets: ["localhost:8090"] ``` `prometheus --config.file=prometheus.yml` --- ## File: docs/tutorials/understanding_metric_types.md --- title: Understanding metric types sort_rank: 2 --- Prometheus supports four types of metrics: * Counter * Gauge * Histogram * Summary ## Counter Counter is a metric value that can only increase or reset i.e. the value cannot reduce than the previous value. It can be used for metrics like the number of requests, no of errors, etc. Type the below query in the query bar and click execute. `go\_gc\_duration\_seconds\_count` [](/assets/docs/tutorial/counter_example.png) The rate() function in PromQL takes the history of metrics over a time frame and calculates how fast the value is increasing per second. Rate is applicable on counter values only. ` rate(go\_gc\_duration\_seconds\_count[5m])` [](/assets/docs/tutorial/rate_example.png) ## Gauge Gauge is a number which can either go up or down. It can be used for metrics like the number of pods in a cluster, the number of events in a queue, etc. ` go\_memstats\_heap\_alloc\_bytes` [](/assets/docs/tutorial/gauge_example.png) PromQL functions like `max_over_time`, `min_over_time` and `avg_over_time` can be used on gauge metrics ## Histogram Histogram is a more complex metric type when compared to the previous two. Histogram can be used for any calculated value which is counted based on bucket values. Bucket boundaries can be configured by the developer. A common example would be the time it takes to reply to a request, called latency. Example: Let's assume we want to observe the time taken to process API requests. Instead of storing the request time for each request, histograms allow us to store them in buckets. We define buckets for time taken, for example `lower or equal 0.3`, `le 0.5`, `le 0.7`, `le 1`, and `le 1.2`. So these are our buckets and once the time taken for a request is calculated it is added to the count of all the buckets whose bucket boundaries are higher than the measured value. Let's say Request 1 for endpoint “/ping” takes 0.25 s. The count values for the buckets will be. > /ping | Bucket | Count | | --------- | ----- | | 0 - 0.3 | 1 | | 0 - 0.5 | 1 | | 0 - 0.7 | 1 | | 0 - 1 | 1 | | 0 - 1.2 | 1 | | 0 - +Inf | 1 | Note: +Inf bucket is added by default. (Since the histogram is a cumulative frequency 1 is added to all the buckets that are greater than the value) Request 2 for endpoint “/ping” takes 0.4s The count values for the buckets will be this. > /ping | Bucket | Count | | --------- | ----- | | 0 - 0.3 | 1 | | 0 - 0.5 | 2 | | 0 - 0.7 | 2 | | 0 - 1 | 2 | | 0 - 1.2 | 2 | | 0 - +Inf | 2 | Since 0.4 is below 0.5, all buckets up to that boundary increase their counts. Let's explore a histogram metric from the Prometheus UI and apply a few functions. `prometheus\_http\_request\_duration\_seconds\_bucket{handler="/graph"}` [](/assets/docs/tutorial/histogram_example.png) `histogram_quantile()` function can be used to calculate quantiles from a histogram `histogram\_quantile(0.9,prometheus\_http\_request\_duration\_seconds\_bucket{handler="/graph"})` [](/assets/docs/tutorial/histogram_quantile_example.png) The graph shows that the 90th percentile is 0.09, To find the histogram_quantile over the last 5m you can use the rate() and time frame `histogram_quantile(0.9, rate(prometheus\_http\_request\_duration\_seconds\_bucket{handler="/graph"}[5m]))` [](/assets/docs/tutorial/histogram_rate_example.png) ## Summary Summaries also measure events and are an alternative to histograms. They are cheaper but lose more data. They are calculated on the application level hence aggregation of metrics from multiple instances of the same process is not possible. They are used when the buckets of a metric are not known beforehand, but it is highly recommended to use histograms over summaries whenever possible. In this tutorial, we covered the types of metrics in detail and a few PromQL operations like rate, histogram_quantile, etc. --- ## File: docs/tutorials/visualizing_metrics_using_grafana.md --- title: Visualizing metrics using Grafana sort_rank: 4 --- In this tutorial we will create a simple dashboard using [Grafana](https://github.com/grafana/grafana) to visualize the `ping_request_count` metric that we instrumented in the [previous tutorial](./instrumenting_http_server_in_go.md). If you are wondering why one should use a tool like Grafana when one can query and see the graphs using Prometheus, the answer is that the graph that we see when we run queries on Prometheus is to run ad-hoc queries. Grafana and [Console Templates](https://prometheus.io/docs/visualization/consoles/) are two recommended ways of creating graphs. ## Installing and Setting up Grafana. Install and Run Grafana by following the steps from [here](https://grafana.com/docs/grafana/latest/installation/requirements/#supported-operating-systems) for your operating system. Once Grafana is installed and run, navigate to [http://localhost:3000](http://localhost:3000) in your browser. Use the default credentials, username as `admin` and password as `admin` to log in and setup new credentials. ## Adding Prometheus as a Data Source in Grafana. Let's add a datasource to Grafana by clicking on the gear icon in the side bar and select `Data Sources` > ⚙ > Data Sources In the Data Sources screen you can see that Grafana supports multiple data sources like Graphite, PostgreSQL etc. Select Prometheus to set it up. Enter the URL as [http://localhost:9090](http://localhost:9090) under the HTTP section and click on `Save and Test`. ## Creating our first dashboard. Now we have successfully added Prometheus as a data source, Next we will create our first dashboard for the `ping_request_count` metric that we instrumented in the previous tutorial. 1. Click on the `+` icon in the side bar and select `Dashboard`. 2. In the next screen, Click on the `Add new panel` button. 3. In the `Query` tab type the PromQL query, in this case just type `ping_request_count`. 4. Access the `ping` endpoint few times and refresh the Graph to verify if it is working as expected. 4. In the right hand section under `Panel Options` set the `Title` as `Ping Request Count`. 5. Click on the Save Icon in the right corner to Save the dashboard.