profile
viewpoint

influxdata/flux 452

Flux is a lightweight scripting language for querying databases (like InfluxDB) and working with data. It's part of InfluxDB 1.7 and 2.0, but can be run independently of those.

ecadlabs/tezos_exporter 9

A Prometheus metrics exporter for monitoring a Tezos node

juliusv/ansible_prometheus_demo 4

A demo setup of Prometheus using CloudAlchemy's Ansible roles

ccobb-nr/promql-compliance-tester 1

Compliance tests for vendor PromQL implementations outside of Prometheus

juliusv/crate_adapter 1

CrateDB Prometheus Adapter

juliusv/alertmanager 0

Prometheus Alertmanager

PR opened prometheus/prometheus

UI: Remove useless else-if

That else-if can never be reached.

Signed-off-by: Julien Pivotto roidelapluie@inuits.eu

<!-- Don't forget!

- If the PR adds or changes a behaviour or fixes a bug of an exported API it would need a unit/e2e test.

- Where possible use only exported APIs for tests to simplify the review and make it as close as possible to an actual library usage.

- No tests are needed for internal implementation changes.

- Performance improvements would need a benchmark test to prove it.

- All exposed objects should have a comment.

- All comments should start with a capital letter and end with a full stop.

-->

+0 -2

0 comment

1 changed file

pr created time in 44 minutes

GollumEvent

issue openedprometheus/alertmanager

How to disable Watchdog initial notification in Alertmanager

<!--

Please do *NOT* ask usage questions in Github issues.

If your issue is not a feature request or bug report use:
https://groups.google.com/forum/#!forum/prometheus-users. If
you are unsure whether you hit a bug, search and ask in the
mailing list first.

You can find more information at: https://prometheus.io/community/

-->

**I installed Alertmanager in my EKS cluster along with Prometheus and set up some alerts, they all working fine except one annoying alert that spin up every time which is the Watchdog notification that tells that the entire pipeline is working fine, I know it's an important alert but we have one receiver that accepts all kind of alerts, and it's really annoying to get notified at 12pm to only see that one alert i tried to et rid of it by redirecting it to a null receive but it doesn't work. **

Disable the Watchdog alert

The Watchdog alert keeps firing all the time

Environment

  • System information:

    EKS cluster v1.16

  • Alertmanager version:

    v0.21.0

  • Prometheus version:

    v2.21.0

  • Alertmanager configuration file:

config:
    global:
      resolve_timeout: 5m
    route:
      group_by: ['job']
      group_wait: 30s
      group_interval: 5m
      repeat_interval: 4h
      receiver: prometheus-msteams
      routes:
      - match:
          alertname: Watchdog
        receiver: prometheus-msteams
    receivers:
    - name: prometheus-msteams
      webhook_configs:
      - url: "http://prometheus-msteams:2000/alertmanager"
        send_resolved: true

created time in 2 hours

PR opened prometheus/docs

Add Vector to tools that export Prometheus metrics

Vector has both a Prometheus source and sink and a remote_write source and sink.

@brian-brazil

+1 -0

0 comment

1 changed file

pr created time in 2 hours

issue openedprometheus/haproxy_exporter

crashes on http.ListenAndServe (during accepting new connections)

Version: 0.11.0

Crashes for me every few hours during the ListenAndServe call, as it looks like when trying to accept new incoming connections

runtime: checkdead: find g 491671 in status 1 fatal error: checkdead: runnable g runtime stack: runtime.throw(0x9f811e, 0x15) /usr/local/go/src/runtime/panic.go:1116 +0x72 runtime.checkdead() /usr/local/go/src/runtime/proc.go:4407 +0x390 runtime.mput(...) /usr/local/go/src/runtime/proc.go:4824 runtime.stopm() /usr/local/go/src/runtime/proc.go:1832 +0x95 runtime.exitsyscall0(0xc000001500) /usr/local/go/src/runtime/proc.go:3268 +0x111 runtime.mcall(0x0) /usr/local/go/src/runtime/asm_amd64.s:318 +0x5b goroutine 1 [IO wait, 25002 minutes]: internal/poll.runtime_pollWait(0x7fb060191f18, 0x72, 0x0) /usr/local/go/src/runtime/netpoll.go:203 +0x55 internal/poll.(*pollDesc).wait(0xc0000b8918, 0x72, 0x0, 0x0, 0x9ef93b) /usr/local/go/src/internal/poll/fd_poll_runtime.go:87 +0x45 internal/poll.(*pollDesc).waitRead(...) /usr/local/go/src/internal/poll/fd_poll_runtime.go:92 internal/poll.(*FD).Accept(0xc0000b8900, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0) /usr/local/go/src/internal/poll/fd_unix.go:384 +0x1d4 net.(*netFD).accept(0xc0000b8900, 0xf0146b39697dc950, 0x1000000000000, 0xf0146b39697dc950) /usr/local/go/src/net/fd_unix.go:238 +0x42 net.(*TCPListener).accept(0xc000130ac0, 0x5fb30338, 0xc00004bb60, 0x4cf116) /usr/local/go/src/net/tcpsock_posix.go:139 +0x32 net.(*TCPListener).Accept(0xc000130ac0, 0xc00004bbb0, 0x18, 0xc000000180, 0x6c79fc) /usr/local/go/src/net/tcpsock.go:261 +0x64 net/http.(*Server).Serve(0xc00014a000, 0xaba1a0, 0xc000130ac0, 0x0, 0x0) /usr/local/go/src/net/http/server.go:2901 +0x25d net/http.(*Server).ListenAndServe(0xc00014a000, 0xc00014a000, 0x1) /usr/local/go/src/net/http/server.go:2830 +0xb7 net/http.ListenAndServe(...) /usr/local/go/src/net/http/server.go:3086 main.main() /app/haproxy_exporter.go:616 +0x1788 goroutine 491668 [IO wait, 1 minutes]: internal/poll.runtime_pollWait(0x7fb060191e38, 0x72, 0xffffffffffffffff) /usr/local/go/src/runtime/netpoll.go:203 +0x55 internal/poll.(*pollDesc).wait(0xc0006b1298, 0x72, 0x0, 0x1, 0xffffffffffffffff) /usr/local/go/src/internal/poll/fd_poll_runtime.go:87 +0x45

created time in 3 hours

issue openedprometheus/statsd_exporter

reliability: option to safe guard against cardinality explosion

prometheus doesn't support cardinality explosion by default, so when applications send a lot of metrics by mistake both statsd exporter and prometheus can get overwhelmed and lead to statsd exporter crashing due to memory or prometheus ingesting thousands of series and crashing or slow ingestion + slow queries.

So essentially I'm proposing a cli option to only maintain first N metric series received. and the rest to be simply dropped. Any thoughts on this area?

created time in 3 hours

pull request commentprometheus/client_java

Make DropwizardExports methods protected

Each of our service instances normally exports around 5K of metrics. Having those extra 4 quantiles making it 20K, and with 5 running instances reaches a hundred thousand which is not a problem but it requires slightly bigger Prometheus server instance to avoid crashing.

It would be nice to have a way to control how Dropwizard's histograms are presented in Prometheus, a protected method of some sort.

Alexey1Gavrilov

comment created time in 5 hours

issue commentprometheus/client_java

Split package in simpleclient.servlet and simpleclient.pushgateway

Basically you cannot build a modular Java application having a module which imports classes from both simpleclient.pushgateway and simpleclient.servlet modules

Here a repo reproducing the problem: https://github.com/Alexey1Gavrilov/java-module-issues/tree/master/promethues The compilation fails with the following error:

> mvn compile
...
[ERROR] COMPILATION ERROR :
[INFO] -------------------------------------------------------------
[ERROR] the unnamed module reads package io.prometheus.client.exporter from both simpleclient.servlet and simpleclient.pushgateway
[ERROR] module simpleclient.pushgateway reads package io.prometheus.client.exporter from both simpleclient.servlet and simpleclient.pushgateway
[ERROR] module simpleclient.servlet reads package io.prometheus.client.exporter from both simpleclient.pushgateway and simpleclient.servlet
[ERROR] module simpleclient reads package io.prometheus.client.exporter from both simpleclient.servlet and simpleclient.pushgateway
[ERROR] /Users/agavrilov/Work/git/java-module-issues/promethues/src/main/java/module-info.java:[1,1] module javamodule.promethues reads package io.prometheus.client.exporter from both simpleclient.servlet and simpleclient.pushgateway
[INFO] 5 errors

A possible workaround for a modular application is to avoid importing from both in the one application module, ie have a two separate submodules requiring one of simpleclient.pushgateway or simpleclient.servlet.

Generally speaking splitting packages across .jar files should be avoided. This SO question is a good source of info.
I think it makes sense to rename the package in a major version update. Should not cause much troubles to the users.

Alexey1Gavrilov

comment created time in 5 hours

delete branch prometheus/golang-builder

delete branch : bump_version

delete time in 16 hours

push eventprometheus/golang-builder

prombot

commit sha ed3eecc326a73e0e3b9810f1865336d23b634544

Bump Go version Signed-off-by: prombot <prometheus-team@googlegroups.com>

view details

Ben Kochie

commit sha 8ba6e49b4d628d3d51a6f8a032d7cdd42c4c5f90

Merge pull request #102 from prometheus/bump_version Bump Go version

view details

push time in 16 hours

PR merged prometheus/golang-builder

Bump Go version
+16 -16

0 comment

5 changed files

prombot

pr closed time in 16 hours

pull request commentprometheus/prometheus

Consider status code 429 as recoverable errors to avoid resharding

Ah, any suggestions on how we should move ahead here?

Harkishen-Singh

comment created time in 18 hours

PR opened prometheus/golang-builder

Bump Go version
+16 -16

0 comment

5 changed files

pr created time in 19 hours

create barnchprometheus/golang-builder

branch : bump_version

created branch time in 19 hours

PR closed prometheus/golang-builder

Bump Go version
+16 -16

0 comment

5 changed files

prombot

pr closed time in 19 hours

delete branch prometheus/golang-builder

delete branch : bump_version

delete time in 19 hours

pull request commentprometheus/prometheus

Consider status code 429 as recoverable errors to avoid resharding

If there's a standard for how to respond to 429s via the Retry-After header I think we should support it. I'm hesitant to include an option for Max-Retries given the work we've put into remote write to attempt to never lose data, but not strongly opposed.

Harkishen-Singh

comment created time in a day

issue commentprometheus/pushgateway

Pushgateway HA

@ning1875 would you mind doing an readme in english of your project ?

ssup2

comment created time in a day

release prometheus/memcached_exporter

v0.8.0

memcached_exporter-0.8.0.aix-ppc64.tar.gz 5.80MB

memcached_exporter-0.8.0.darwin-amd64.tar.gz 6.14MB

memcached_exporter-0.8.0.dragonfly-amd64.tar.gz 6.21MB

memcached_exporter-0.8.0.freebsd-386.tar.gz 6.05MB

memcached_exporter-0.8.0.freebsd-amd64.tar.gz 6.23MB

memcached_exporter-0.8.0.freebsd-arm64.tar.gz 5.77MB

memcached_exporter-0.8.0.freebsd-armv6.tar.gz 5.77MB

memcached_exporter-0.8.0.freebsd-armv7.tar.gz 5.77MB

memcached_exporter-0.8.0.linux-386.tar.gz 6.07MB

memcached_exporter-0.8.0.linux-amd64.tar.gz 6.24MB

memcached_exporter-0.8.0.linux-arm64.tar.gz 5.81MB

memcached_exporter-0.8.0.linux-armv5.tar.gz 5.79MB

memcached_exporter-0.8.0.linux-armv6.tar.gz 5.79MB

memcached_exporter-0.8.0.linux-armv7.tar.gz 5.79MB

memcached_exporter-0.8.0.linux-mips.tar.gz 5.78MB

memcached_exporter-0.8.0.linux-mips64.tar.gz 5.90MB

memcached_exporter-0.8.0.linux-mips64le.tar.gz 5.72MB

memcached_exporter-0.8.0.linux-mipsle.tar.gz 5.65MB

memcached_exporter-0.8.0.linux-ppc64.tar.gz 5.91MB

memcached_exporter-0.8.0.linux-ppc64le.tar.gz 5.75MB

memcached_exporter-0.8.0.linux-s390x.tar.gz 6.26MB

memcached_exporter-0.8.0.netbsd-386.tar.gz 6.02MB

memcached_exporter-0.8.0.netbsd-amd64.tar.gz 6.20MB

memcached_exporter-0.8.0.netbsd-arm64.tar.gz 5.75MB

memcached_exporter-0.8.0.netbsd-armv6.tar.gz 5.75MB

memcached_exporter-0.8.0.netbsd-armv7.tar.gz 5.75MB

memcached_exporter-0.8.0.openbsd-386.tar.gz 6.02MB

memcached_exporter-0.8.0.openbsd-amd64.tar.gz 6.20MB

memcached_exporter-0.8.0.openbsd-arm64.tar.gz 5.75MB

memcached_exporter-0.8.0.openbsd-armv7.tar.gz 5.75MB

memcached_exporter-0.8.0.windows-386.tar.gz 6.12MB

memcached_exporter-0.8.0.windows-386.zip 6.22MB

memcached_exporter-0.8.0.windows-amd64.tar.gz 6.22MB

memcached_exporter-0.8.0.windows-amd64.zip 6.30MB

sha256sums.txt 3.67KB

released time in a day

issue closedprometheus/prometheus

2.23.0 Getting: x509: certificate relies on legacy Common Name field, use SANs or temporarily enable Common Name matching with GODEBUG=x509ignoreCN=0

<!--

Please do *NOT* ask usage questions in Github issues.

If your issue is not a feature request or bug report use:
https://groups.google.com/forum/#!forum/prometheus-users. If
you are unsure whether you hit a bug, search and ask in the
mailing list first.

You can find more information at: https://prometheus.io/community/

-->

What did you do? Upgraded Prometheus instance from 2.17.1 to 2.23.0 What did you expect to see? Configured jobs to run with TLS and self signed cert. What did you see instead? Under which circumstances? Prometheus reporting: Get "<REMOVED>": x509: certificate relies on legacy Common Name field, use SANs or temporarily enable Common Name matching with GODEBUG=x509ignoreCN=0 Environment Producation

  • System information:

Linux 4.14.138-rancher x86_64

  • Prometheus version:

prometheus, version 2.23.0 (branch: HEAD, revision: 26d89b4b0776fe4cd5a3656dfa520f119a375273) build user: root@37609b3a0a21 build date: 20201126-10:56:17 go version: go1.15.5 platform: linux/amd64

  • Alertmanager version:

    insert output of alertmanager --version here (if relevant to the issue)

  • Prometheus configuration file:

- job_name: ScrapeJob
  file_sd_configs:
  - files:
    - /etc/prometheus/configmaps/test/file.json
  scrape_interval: 1m
  metrics_path: /metrics
  scheme: https
  basic_auth:
    username: <removed>
    password: <removed>
  tls_config:
    ca_file: /etc/prometheus/secrets/ca/ca.pem
  • Alertmanager configuration file:
insert configuration here (if relevant to the issue)
  • Logs:
Seeing this on job status page: Get "<REMOVED>": x509: certificate relies on legacy Common Name field, use SANs or temporarily enable Common Name matching with GODEBUG=x509ignoreCN=0

closed time in a day

hartman17

issue commentprometheus/prometheus

2.23.0 Getting: x509: certificate relies on legacy Common Name field, use SANs or temporarily enable Common Name matching with GODEBUG=x509ignoreCN=0

Thank you for reaching us.

This is not a bug but a behaviour of golang: https://golang.org/doc/go1.15#commonname

If you do not know what it means, or how to change your GODEBUG env variable, it makes more sense to ask this question like this on the prometheus-users mailing list rather than in a GitHub issue. On the mailing list, more people are available to potentially respond to your question, and the whole community can benefit from the answers provided.

hartman17

comment created time in a day

issue openedprometheus/prometheus

2.23.0 Getting: x509: certificate relies on legacy Common Name field, use SANs or temporarily enable Common Name matching with GODEBUG=x509ignoreCN=0

<!--

Please do *NOT* ask usage questions in Github issues.

If your issue is not a feature request or bug report use:
https://groups.google.com/forum/#!forum/prometheus-users. If
you are unsure whether you hit a bug, search and ask in the
mailing list first.

You can find more information at: https://prometheus.io/community/

-->

What did you do? Upgraded Prometheus instance from 2.17.1 to 2.23.0 What did you expect to see? Configured jobs to run with TLS and self signed cert. What did you see instead? Under which circumstances? Prometheus reporting: Get "<REMOVED>": x509: certificate relies on legacy Common Name field, use SANs or temporarily enable Common Name matching with GODEBUG=x509ignoreCN=0 Environment Producation

  • System information:

Linux 4.14.138-rancher x86_64

  • Prometheus version:

prometheus, version 2.23.0 (branch: HEAD, revision: 26d89b4b0776fe4cd5a3656dfa520f119a375273) build user: root@37609b3a0a21 build date: 20201126-10:56:17 go version: go1.15.5 platform: linux/amd64

  • Alertmanager version:

    insert output of alertmanager --version here (if relevant to the issue)

  • Prometheus configuration file:

- job_name: ScrapeJob
  file_sd_configs:
  - files:
    - /etc/prometheus/configmaps/test/file.json
  scrape_interval: 1m
  metrics_path: /metrics
  scheme: https
  basic_auth:
    username: <removed>
    password: <removed>
  tls_config:
    ca_file: /etc/prometheus/secrets/ca/ca.pem
  • Alertmanager configuration file:
insert configuration here (if relevant to the issue)
  • Logs:
Seeing this on job status page: Get "<REMOVED>": x509: certificate relies on legacy Common Name field, use SANs or temporarily enable Common Name matching with GODEBUG=x509ignoreCN=0

created time in a day

pull request commentprometheus/prometheus

Small cleanup of API code.

My preference is also not to have small const like this.

However, invalidParamError is nice and I like it.

bwplotka

comment created time in a day

created tagprometheus/memcached_exporter

tagv0.8.0

Exports metrics from memcached servers for consumption by Prometheus.

created time in a day

delete branch prometheus/memcached_exporter

delete branch : grobie/cut-0.8.0

delete time in a day

PR merged prometheus/memcached_exporter

Release v0.8.0

Signed-off-by: Tobias Schmidt tobidt@gmail.com

+8 -1

0 comment

2 changed files

grobie

pr closed time in a day

push eventprometheus/memcached_exporter

Tobias Schmidt

commit sha 3d8ce192c21319731f1ac784af16a72468dcca5d

Release v0.8.0 Signed-off-by: Tobias Schmidt <tobidt@gmail.com>

view details

push time in a day

pull request commentprometheus/prometheus

Small cleanup of API code.

Why do you want to find the value of constant - the constant should be well named in all cases (:

So I can tell what the code is actually doing. Every indirection gets in the way of that, and greatly slows down my ability to read and understand code. For every single use of something that looks like a variable I need to spend effort to determine where the variable is defined and what logic is applied to it. Even if if turns out to be a constant in a particular case, I still need to check for shadowing, and add the values to the myriad of other information I need to keep mental track of when reading code.

Code that is self-contained on one line is much easier to understand.

What if I would remove the usage of those constants in test then? hugs

That wouldn't work for me, this PR seems to be adding indirection for the sake of adding indirection.

bwplotka

comment created time in a day

GollumEvent

push eventprometheus/memcached_exporter

Tobias Schmidt

commit sha 3d8ce192c21319731f1ac784af16a72468dcca5d

Release v0.8.0 Signed-off-by: Tobias Schmidt <tobidt@gmail.com>

view details

push time in a day

more