401 Unauthorized since last week

[aserrallerios]

Hello,

When I run:

docker run -p 8000:8000 giantswarm/prometheus-pingdom-exporter:latest server user pass apikey

I got:

2019/07/10 09:28:06 Listening on port 8000
2019/07/10 09:28:06 Error getting checks 401 Unauthorized: No credentials provided
2019/07/10 09:28:16 Error getting checks 401 Unauthorized: No credentials provided

It was working a week ago. Nothing changed on our side.

The credentials are still valid:

curl -H 'App-Key: {apikey}' -H 'Authorization: Basic {encoded user:pass}' https://api.pingdom.com/api/2.1/probes

Could something have changed recently? Can I get additional debug output somehow?

[jramst]

We have run into the same issue as well. The exporter started reporting this error in three separate environments on 2019-07-04 around 13:50 CEST.

So far, I've managed to see that the docker image seems to be utilizing an older release of the library go-pingdom (https://github.com/russellcardullo/go-pingdom/) which uses an older version of the Pingdom api (https://api.pingdom.com/api/2.0), but direct calls using Postman, with the same credentials, to the older version of the API still gives valid responses.

[pmauduit]

Same issue as well, taking contact with the pingdom support did not really help

[pmauduit]

if needed you can use the camptocamp docker image to fix the issue:

camptocamp/prometheus-pingdom-exporter:20190610-1

In fact the codebase already integrates a sufficiently recent version of the pingdom-go module (from my understanding), but the giantswarm image has not been updated for 3 years on docker-hub.

[bohdanlykhitkoexp]

This issue still exist!
Also, camptocamp/prometheus-pingdom-exporter always returned:
Error getting checks 403 Forbidden: Invalid application key
when API key works good using curl.
Do anyone know any other pingdom exporters for prometheus?

[pmauduit]

Error getting checks 403 Forbidden: Invalid application key

Since we are still using it in production, you might have an issue with the way you configured it. I just relaunched the container on one of our setups to check if something changed recently, and we don't have any of these 403 you mentioned.