Prometheus rule linter

Overview

pint

pint is a Prometheus rule linter.

Usage

There are two modes it works in:

  • CI PR linting
  • Ad-hoc linting of a selected files or directories

Pull Requests

It currently supports git for which it will find all commits on the current branch that are not present in parent branch and scan all modified files included in those changes.

Results can optionally be reported using BitBucket API to generate a report with any found issues. Each issue will create an inline annotation in BitBucket with a description of the issue. Exit code will always be zero when this is used, the report itself will indicate if checks passed or not.

Ad-hoc

Lint specified files and report any found issue.

You can lint selected files:

pint lint rules.yml

or directories:

pint lint path/to/dir

or both:

pint lint path/to/dir file.yml path/file.yml path/dir

Quick start

Requirements:

  1. Build the binary:

    git clone https://github.com/cloudflare/pint.git
    cd pint
    make build
  2. Run a simple syntax check on Prometheus alerting or recording rules file(s).

    ./pint lint /etc/prometheus/*.rules.yml
  3. Configuration file is optional, but without it pint will only run very basic syntax checks. See CONFIGURATION.md for details on config syntax. Check examples dir for sample config files. By default pint will try to load configuration from .pint.hcl, you can specify a different path using --config flag:

    ./pint --config /etc/pint.hcl lint /etc/prometheus/rules/*.yml
Issues
  • checks: series: add ignore_recordingrules option

    checks: series: add ignore_recordingrules option

    Add a new option ignore_recordingrules to the series check that will make it ignore errors when checking for the existence of metrics iff they are part of the same pull/merge request.

    This improves the series check for the CI use-case significantly because pull/merge requests might add new recording rules together with alerting rules, and without this option the series check will fail when they won't be found. With this option, pint would look at the newly added recorded rules as well.

    opened by GiedriusS 5
  • reporter: add GitHub support

    reporter: add GitHub support

    Add GitHub reporter support. All of the problems in the summary are submitted as (multi-)line comments on a given pull request. Add some small tests to try out this functionality. I have also done some ad-hoc tests.

    Also, exit with 1 when there are problems with severity Bug or higher. This is so that it would be possible to run pint ci in Jenkins so that it would report problems on GitHub & exit with 1 to indicate that a step has failed. All of the users which depend on the exit code being 0 can simply ignore the errors with ||: in Bash.

    cc @prymitive

    opened by GiedriusS 5
  • too many open files

    too many open files

    Hello, thx for linter!

    We have repository with prometheus-alerts:

    $ find conf -type f | wc -l
    263
    

    When we run linter we got error:

    ./pint --config rules.hcl lint conf/test
    ...
    level=fatal msg="Execution completed with error(s)s" error="open conf/test/file.yml: too many open files"
    

    update if we run without config parameters, its work fine:

    ./pint lint conf/test
    ...
    level=info msg="File parsed" path=conf/test/file.yml rules=1
    
    opened by juev 4
  • GitHub reporter support

    GitHub reporter support

    Hello! Thanks for this software. It would be ideal to support GitHub, not just BitBucket as a platform where detected issues could be reported. What do you think? Would you be open to accepting pull requests implementing such a feature?

    opened by GiedriusS 4
  • Using yaml anchors results in false positives e.g yaml/parse

    Using yaml anchors results in false positives e.g yaml/parse

    Hi @prymitive ! Thank you for pint, it looks really good!

    We (SRE at Wikimedia Foundation) are evaluating it for our Prometheus alerts currently and ran into a potential issue around YAML anchors.

    Consider the following:

    groups:
    - name: certmanager
      rules:
      - &CertManagerCertExpirySoon
        alert: CertManagerCertExpirySoon
        expr: certmanager_certificate_expiration_timestamp_seconds - time() < (9 * 24 * 3600)
        for: 5m
        labels:
          team: sre
          severity: warning
        annotations:
          summary: "Certificate {{ $labels.namespace }}/{{ $labels.name }} in is about to expire"
          description: "The certificate {{ $labels.name }} in namespace {{ $labels.namespace }} is {{ $value | humanizeDuration }} from expiry. It should have been refreshed 9 days before expiry"
          runbook: https://wikitech.wikimedia.org/wiki/Kubernetes/cert-manager
      - <<: *CertManagerCertExpirySoon
        expr: certmanager_certificate_expiration_timestamp_seconds - time() < (7 * 24 * 3600)
        labels:
          team: sre
          severity: critical
    

    Running pint lint will result in a yaml/parse error:

    incomplete rule, no alert or record key (yaml/parse)                                                                                                                               
    ||     expr: certmanager_certificate_expiration_timestamp_seconds - time() < (7 * 24 * 3600)
    

    Even though the alert does have alert clause after resolving anchors. What do you think ?

    opened by filippog 3
  • RFE: Allow selecting alerting rules based on whether or not they have a 'for:'

    RFE: Allow selecting alerting rules based on whether or not they have a 'for:'

    Prometheus alerting rules can have a 'for:'. In our environment, all alert rules with a for: should have an additional label, and all alert rules without it should lack that label. It would be nice if Pint could check for things like this or otherwise distinguish between for and for-less alert rules (who knows, someone might have a rule that no alerts should use for:).

    As an extra bonus feature it would be nice if the for: duration was available for lint checks in some way, or you could verify that some label had the same duration as the for:. Our additional label should actually have the same duration value as the for: (we use it in alert messages to say how long ago the alert condition started to be true), and I can imagine that some people might want to require either minimum or maximum for: durations.

    opened by siebenmann 3
  • Bump github.com/prometheus/common from 0.34.0 to 0.35.0

    Bump github.com/prometheus/common from 0.34.0 to 0.35.0

    Bumps github.com/prometheus/common from 0.34.0 to 0.35.0.

    Commits

    Dependabot compatibility score

    Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.


    Dependabot commands and options

    You can trigger Dependabot actions by commenting on this PR:

    • @dependabot rebase will rebase this PR
    • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
    • @dependabot merge will merge this PR after your CI passes on it
    • @dependabot squash and merge will squash and merge this PR after your CI passes on it
    • @dependabot cancel merge will cancel a previously requested merge and block automerging
    • @dependabot reopen will reopen this PR if it is closed
    • @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
    • @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
    dependencies go 
    opened by dependabot[bot] 2
  • Only show bug/warning level problems

    Only show bug/warning level problems

    Hi, Is it possible to only make it print bug and warning messages?

    For example, I have the following ouput: level=info msg="Problems found" Bug=8 Information=228 Warning=4

    But I would only be interested in the bugs and warnings.

    Thanks

    opened by kovaxur 2
  • Bump github.com/golangci/golangci-lint from 1.43.0 to 1.44.0 in /tools/golangci-lint

    Bump github.com/golangci/golangci-lint from 1.43.0 to 1.44.0 in /tools/golangci-lint

    Bumps github.com/golangci/golangci-lint from 1.43.0 to 1.44.0.

    Release notes

    Sourced from github.com/golangci/golangci-lint's releases.

    v1.44.0

    Changelog

    • 32cf48ed Add "grouper" linter (#2497)
    • 63f150ea Add decorder linter (#2453)
    • 55358972 Add errchkjson linter (#2362)
    • e3d0247e Add maintidx linter (#2435)
    • d2093896 Add support for multiple outputs (#2386)
    • efb35995 Bump github.com/ashanbrown/forbidigo from 1.2.0 to 1.3.0 (#2487)
    • 6e2e51d8 Bump makezero to v1.1.0 (#2490)
    • e788757b Ensure that the Issues key in JSON format is a list (#2358)
    • eaed228d Print error text in tag content for more readable junit report (#2460)
    • b5d8e698 Return error if any linter fails to run (#2471)
    • ec58c481 Show deprecated mark in the CLI linters help (#2350)
    • 68f530a8 add containedctx linter (#2382)
    • c53eb78a asciicheck: bump to v0.1.1 (#2510)
    • ae537189 bodyclose: bump to HEAD (#2508)
    • ba3453d2 build(deps): bump actions/cache from 2.1.6 to 2.1.7 (#2383)
    • 80659f85 build(deps): bump github.com/BurntSushi/toml from 0.4.1 to 1.0.0 (#2491)
    • 8bc95624 build(deps): bump github.com/breml/bidichk from 0.2.0 to 0.2.1 (#2354)
    • f311ffd2 build(deps): bump github.com/breml/errchkjson from 0.2.0 to 0.2.1 (#2493)
    • ec2820c5 build(deps): bump github.com/esimonov/ifshort from 1.0.3 to 1.0.4 (#2436)
    • 83962f47 build(deps): bump github.com/fzipp/gocyclo from 0.3.1 to 0.4.0 (#2425)
    • 6ddb9071 build(deps): bump github.com/go-critic/go-critic from 0.6.1 to 0.6.2 (#2474)
    • a79803fa build(deps): bump github.com/kulti/thelper from 0.4.0 to 0.5.0 (#2492)
    • 9e129498 build(deps): bump github.com/ldez/tagliatelle from 0.2.0 to 0.3.0 (#2454)
    • 0ac5d371 build(deps): bump github.com/mattn/go-colorable from 0.1.11 to 0.1.12 (#2384)
    • 620bd9bb build(deps): bump github.com/mgechev/revive from 1.1.2 to 1.1.3 (#2517)
    • ecbb9c47 build(deps): bump github.com/nishanths/exhaustive from 0.3.6 to 0.6.0 (#2353)
    • fc888cf0 build(deps): bump github.com/nishanths/exhaustive from 0.6.0 to 0.7.11 (#2371)
    • 88d3ec0f build(deps): bump github.com/quasilyte/go-ruleguard/dsl (#2455)
    • 131ab76b build(deps): bump github.com/quasilyte/go-ruleguard/dsl (#2472)
    • 441d8443 build(deps): bump github.com/quasilyte/go-ruleguard/dsl (#2519)
    • 7d5bc8f0 build(deps): bump github.com/securego/gosec/v2 from 2.9.1 to 2.9.2 (#2372)
    • d0aead44 build(deps): bump github.com/securego/gosec/v2 from 2.9.2 to 2.9.3 (#2385)
    • 56f27d0a build(deps): bump github.com/securego/gosec/v2 from 2.9.3 to 2.9.5 (#2413)
    • 9bad615c build(deps): bump github.com/securego/gosec/v2 from 2.9.5 to 2.9.6 (#2516)
    • d29d9f12 build(deps): bump github.com/shirou/gopsutil/v3 from 3.21.10 to 3.21.11 (#2405)
    • b4a3bd8c build(deps): bump github.com/shirou/gopsutil/v3 from 3.21.11 to 3.21.12 (#2456)
    • ca8cd60f build(deps): bump github.com/spf13/cobra from 1.2.1 to 1.3.0 (#2426)
    • 4ca6a2fc build(deps): bump github.com/spf13/viper from 1.10.0 to 1.10.1 (#2424)
    • f960879b build(deps): bump github.com/spf13/viper from 1.9.0 to 1.10.0 (#2412)
    • 018befd3 build(deps): bump github.com/tommy-muehle/go-mnd/v2 from 2.4.0 to 2.5.0 (#2518)
    • 8cdecc96 build(deps): bump gitlab.com/bosi/decorder from 0.2.0 to 0.2.1 (#2473)
    • 4119132f build(deps): bump honnef.co/go/tools from 0.2.1 to 0.2.2 (#2370)
    • b845512b build(deps): bump mvdan.cc/gofumpt from 0.1.1 to 0.2.0 (#2373)
    • 107b8307 build(deps): bump mvdan.cc/gofumpt from 0.2.0 to 0.2.1 (#2427)
    • 49501691 bump bidichk from v0.1.1 to v0.2.0
    • a471733b bump github.com/yeya24/promlinter from v0.1.0 to HEAD (#2500)
    • 7f25fee1 bump varnamelen from v0.4.0 to v0.5.0 (#2369)
    • 1b535204 bump varnamelen to v0.4.0 (#2348)

    ... (truncated)

    Changelog

    Sourced from github.com/golangci/golangci-lint's changelog.

    v1.44.0

    1. new linters:
    2. updated linters:
      • asciicheck: bump to v0.1.1
      • bidichk: from 0.1.1 to 0.2.1
      • bodyclose: bump to HEAD
      • decorder: from 0.2.0 to 0.2.1
      • depguard: from 1.0.1 to 1.1.0
      • errchkjson: from 0.2.0 to 0.2.1
      • errorlint: bump to HEAD
      • exhaustive: drop deprecated/unused settings
      • exhaustive: from v0.2.3 to 0.7.11
      • forbidigo: from 1.2.0 to 1.3.0
      • forcetypeassert: bump to v0.1.0
      • gocritic: from 0.6.1 to 0.6.2
      • gocritic: support autofix
      • gocyclo: from 0.3.1 to 0.4.0
      • godot: add period option
      • gofumpt: from 0.1.1 to 0.2.1
      • gomnd: from 2.4.0 to 2.5.0
      • gomnd: new configuration
      • gosec: from 2.9.1 to 2.9.6
      • ifshort: from 1.0.3 to 1.0.4
      • ineffassign: bump to HEAD
      • makezero: to v1.1.0
      • promlinter: from v0.1.0 to HEAD
      • revive: fix enableAllRules
      • revive: from 1.1.2 to 1.1.3
      • staticcheck: from 0.2.1 to 0.2.2
      • tagliatelle: from 0.2.0 to 0.3.0
      • thelper: from 0.4.0 to 0.5.0
      • unparam: bump to HEAD
      • varnamelen: bump to v0.5.0
      • wrapcheck: update configuration to include ignoreSignRegexps
    3. documentation:
      • linters: improve pages about configuration
      • improve page about false-positive
      • nolintlint: fix wrong default value in comment
      • revive: add a more detailed configuration
    4. misc:
      • outputs: Add support for multiple outputs
      • outputs: Print error text in <failure> tag content for more readable JUnit output
      • outputs: ensure that the Issues key in JSON format is a list
      • Return error if any linter fails to run

    ... (truncated)

    Commits

    Dependabot compatibility score

    Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.


    Dependabot commands and options

    You can trigger Dependabot actions by commenting on this PR:

    • @dependabot rebase will rebase this PR
    • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
    • @dependabot merge will merge this PR after your CI passes on it
    • @dependabot squash and merge will squash and merge this PR after your CI passes on it
    • @dependabot cancel merge will cancel a previously requested merge and block automerging
    • @dependabot reopen will reopen this PR if it is closed
    • @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
    • @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
    dependencies go 
    opened by dependabot[bot] 2
  • Unable to disable some checks globally

    Unable to disable some checks globally

    Hi, I've noticed that at some point in time template {} check was enabled by default. Nevertheless, we'd like to disable alerts/template check for all our alerting rules. It looks like the only way to do it is to edit each rule and add pint disable comment which is not very useful for our volume. Is it possible to add the ability to ignore some checks globally?

    opened by pznamensky 2
  • RFE: Allow query/series to be disabled for only some series, or special-case ALERTS{}

    RFE: Allow query/series to be disabled for only some series, or special-case ALERTS{}

    We have some alert rules designed to detect large-scale issues and avoid flooding us with smaller alerts. As part of the alert rules, these alerts count active alerts using ALERTS{alertstate="firing"}. Normally we have no firing alerts, so when I run a pint check of our alert rules I get a query/series warning for this. I can disable this warning for the entire alert rule with # pint disable query/series, but the alert rule contains other series that I would like pint to check to make sure they exist. It would be nice if pint would either allow you to disable only a specific series in a rule instead of all of them, or alternately if it had a special case for the ALERTS series.

    (Or perhaps there's already a way to do this.)

    opened by siebenmann 2
  • Run Pint against Thanos Query

    Run Pint against Thanos Query

    It would be nice to enable the usage of Pint against the Thanos Query so that we can leverage the excellent pint functionalities when we're using a distributed monitoring solution or using components such as Thanos Ruler.

    I was looking into the code, and I guess that the only thing that is avoiding it, is because pint is getting the Prometheus config for the Prometheus API /api/v1/status/config.

    I've tested by running pint on my local machine and after to comment the code that is going through the config API, could be nice if we have the possibility to provide those values by config and skip the API in this case

    opened by nicolastakashi 1
  • Panic, slice index out of bounds

    Panic, slice index out of bounds

    I just got this panic:

    panic: runtime error: slice bounds out of range [:243] with capacity 242
    
    goroutine 1 [running]:
    github.com/cloudflare/pint/internal/reporter.ConsoleReporter.Submit(0xbb2440, 0xc00011e010, 0xc0012e8000, 0xd3, 0x143, 0xbbddd0, 0xc00026cab0, 0x2, 0x2)
    	/home/joaquin/projects/personal/github/pint/internal/reporter/console.go:71 +0x1073
    main.actionLint(0xc0001a7740, 0x2, 0x2)
    	/home/joaquin/projects/personal/github/pint/cmd/pint/lint.go:47 +0x56a
    github.com/urfave/cli/v2.(*Command).Run(0xc00016d440, 0xc0001a7600, 0x0, 0x0)
    	/home/joaquin/.asdf/installs/golang/1.16.3/packages/pkg/mod/github.com/urfave/cli/[email protected]/command.go:163 +0x4dd
    github.com/urfave/cli/v2.(*App).RunContext(0xc0002321a0, 0xbbd5f0, 0xc00011a010, 0xc000124000, 0x5, 0x5, 0x0, 0x0)
    	/home/joaquin/.asdf/installs/golang/1.16.3/packages/pkg/mod/github.com/urfave/cli/[email protected]/app.go:313 +0x810
    github.com/urfave/cli/v2.(*App).Run(...)
    	/home/joaquin/.asdf/installs/golang/1.16.3/packages/pkg/mod/github.com/urfave/cli/[email protected]/app.go:224
    main.main()
    	/home/joaquin/projects/personal/github/pint/cmd/pint/main.go:72 +0x106
    
    

    on this line: https://github.com/cloudflare/pint/blob/452a61ca4aaaca44bade5302879657454d233d06/internal/reporter/console.go#L71

    Seems like the check can fail sometimes

    opened by xocasdashdash 9
Releases(v0.22.2)
Owner
Cloudflare
Cloudflare
A sub module of EdgeGallery MECM which responsible for the app rule management

mecm-apprulemgr 介绍 Application rule manager 软件架构 软件架构说明 安装教程 xxxx xxxx xxxx 使用说明 xxxx xxxx xxxx 参与贡献 Fork 本仓库 新建 Feat_xxx 分支 提交代码 新建 Pull Request 特技 使

EdgeGallery 22 Jan 24, 2022
Prevent Kubernetes misconfigurations from ever making it (again 😤) to production! The CLI integration provides policy enforcement solution to run automatic checks for rule violations. Docs: https://hub.datree.io

What is Datree? Datree helps to prevent Kubernetes misconfigurations from ever making it to production. The CLI integration can be used locally or in

datree.io 5.6k Jun 23, 2022
Translate Prometheus Alerts into Kubernetes pod readiness

prometheus-alert-readiness Translates firing Prometheus alerts into a Kubernetes readiness path. Why? By running this container in a singleton deploym

Coralogix 19 Mar 7, 2021
A beginner friendly introduction to prometheus 🔥

Prometheus-Basics A beginner friendly introduction to prometheus. Table of Contents What is prometheus ? What are metrics and why is it important ? Ba

S Santhosh Nagaraj 1.6k Jun 27, 2022
Doraemon is a Prometheus based monitor system

English | 中文 Doraemon Doraemon is a Prometheus based monitor system ,which are made up of three components——the Rule Engine,the Alert Gateway and the

Qihoo 360 616 Jul 1, 2022
A set of tests to check compliance with the Prometheus Remote Write specification

Prometheus Remote Write Compliance Test This repo contains a set of tests to check compliance with the Prometheus Remote Write specification. The test

Tom Wilkie 92 Jun 7, 2022
Automating Kubernetes Rollouts with Argo and Prometheus. Checkout the demo URL below

observe-argo-rollout Demo for Automating and Monitoring Kubernetes Rollouts with Argo and Prometheus Performing Demo The demo can be found on Katacoda

null 32 Jun 15, 2022
📡 Prometheus exporter that exposes metrics from SpaceX Starlink Dish

Starlink Prometheus Exporter A Starlink exporter for Prometheus. Not affiliated with or acting on behalf of Starlink(™) ?? Starlink Monitoring System

DanOpsTech 64 Jun 25, 2022
A tool to dump and restore Prometheus data blocks.

promdump promdump dumps the head and persistent blocks of Prometheus. It supports filtering the persistent blocks by time range. Why This Tool When de

Ivan Sim 101 Jun 20, 2022
🦥 Easy and simple Prometheus SLO generator

Sloth Introduction Use the easiest way to generate SLOs for Prometheus. Sloth generates understandable, uniform and reliable Prometheus SLOs for any k

Xabier Larrakoetxea Gallego 1.2k Jun 25, 2022
Prometheus exporter for Chia node metrics

chia_exporter Prometheus metric collector for Chia nodes, using the local RPC API Building and Running With the Go compiler tools installed: go build

Kevin Retzke 35 Mar 27, 2022
Plays videos using Prometheus, e.g. Bad Apple.

prom_bad_apple Plays videos using Prometheus, e.g. Bad Apple. Inspiration A while back I thought this blog post and the corresponding source code were

Jacob Colvin 88 Jun 29, 2022
k6 prometheus output extension

xk6-prometheus A k6 extension implements Prometheus HTTP exporter as k6 output extension. Using xk6-prometheus output extension you can collect metric

Iván Szkiba 33 Jun 20, 2022
Generate Prometheus rules for your SLOs

prometheus-slo Generates Prometheus rules for alerting on SLOs. Based on https://developers.soundcloud.com/blog/alerting-on-slos. Usage Build and Run

Ganesh Vernekar 17 Oct 20, 2021
Nvidia GPU exporter for prometheus using nvidia-smi binary

nvidia_gpu_exporter Nvidia GPU exporter for prometheus, using nvidia-smi binary to gather metrics. Introduction There are many Nvidia GPU exporters ou

Utku Özdemir 106 Jun 28, 2022
NVIDIA GPU metrics exporter for Prometheus leveraging DCGM

DCGM-Exporter This repository contains the DCGM-Exporter project. It exposes GPU metrics exporter for Prometheus leveraging NVIDIA DCGM. Documentation

NVIDIA Corporation 149 Jun 28, 2022
Prometheus exporter for Amazon Elastic Container Service (ECS)

ecs_exporter ?? ?? ?? This repo is still work in progress and is subject to change. This repo contains a Prometheus exporter for Amazon Elastic Contai

Prometheus Monitoring Community 39 Jun 6, 2022
A simple tool who pulls data from Online.net API and parse them to a Prometheus format

Dedibox backup monitoring A simple tool who reads API from Online.net and parse them into a Prometheus-compatible format. Conceived to be lightweight,

Florian Forestier / Artheriom 4 Dec 1, 2021
Prometheus exporter for DeadMansSnitch

DeadMansSnitch Exporter Prometheus exporter for DeadMansSnitch information (snitches) Configuration Usage: deadmanssnitch-exporter [OPTIONS] Applic

WebDevOps 3 Apr 6, 2022