Jenkins prometheus plugin not showing data on endpoint - jenkins

My Jenkins - 2.263.1(LTS) deployed through tomcat and i have installed Prometheus metrics plugin - 2.0.8 and restarted the service.
My jenkins base URL - http://jenkins-server:8080/jenkins
But my prometheus end-point - http://jenkins-server:8080/jenkins/prometheus not showing any metrics data.
I have added below in my prometheus.yml
- job_name: 'jenkins'
metrics_path: '/jenkins/prometheus'
scheme: http
static_configs:
- targets: ['jenkins-server:8080']
Currently LDAP authentication and Project-based Matrix Authorization configured. Also i have tried with domain credential password and token in my prometheus.yml but still it doesn't show the plugin generated data in my end-point. Just shows the blank page on my browsers(IE and Chrome).
basic_auth:
username: domain-user-id
password: 98qw37asdkdsjfeiq1dedsewe
Curl response
$ curl -v jenkins-server:8080/jenkins/prometheus
* Trying 206.25.26.27...
* TCP_NODELAY set
* Connected to jenkins-server (206.25.26.27) port 8080 (#0)
> GET /jenkins/prometheus HTTP/1.1
> Host: jenkins-server:8080
> User-Agent: curl/7.58.0
> Accept: */*
>
< HTTP/1.1 302
< Cache-Control: private
< Expires: Thu, 01 Jan 1970 00:00:00 GMT
< X-Content-Type-Options: nosniff
< Location: /jenkins/prometheus/
< Content-Length: 0
< Date: Wed, 17 Feb 2021 11:42:00 GMT
<
* Connection #0 to host jenkins-server left intact
$ curl -X GET jenkins-server:8080/jenkins/prometheus/
$ curl -X GET http://jenkins-server:8080/jenkins/prometheus/
Empty response for above commands. Please share some pointers to resolve this issue. thanks in advance.
#poshak, Generated access key and tired on my browser with https://jenkins_ipaddres:portnumber/jenkins/metrics/accesskey Now i can able to view the below.
Is these data is enough for promethues?

Try to generate Access Keys in the metrics section and access the url https://jenkins_ipaddres:portnumber/metrics/accesskey you would now be able to view the metrics.
Path to generate the Access Keys:
Jenkins > Manage Jenkins > Configure Systems > Metrics >> Add >> Generate >> Save
Thanks

It was an Jenkins Prometheus plugin issue. After upgrading it to 2.0.9 issue solved.

Related

Why my call for access token exchange from authorization code failed?

I am using the authentication code mode of Huawei account kit to login users to my app. To check the app server to account server behavior, I use the cURL command shown bellow to obtain the access token from the authorization code. But the following command would return an error.
curl -v -H "Content-Type:application/x-www-form-urlencoded" -d #body.txt -X POST https://oauth-login.cloud.huawei.com/oauth2/v3/token
the "body.txt" file contains the required information for the request:
grant_type=authorization_code&
code=DQB6e3x9zFqHIfkHR2ctp7htDs5tG5p6jXTkTCeoAAULtuS69PntuuD9pwqHrdXyvrlezuRc/aq+zuDU7OnQdRpImnvZcEX+RIOijYMXYu1j+zxpQ+W/J50Z7pY1qhyxZtavqkELY+6o2jSifaiIxC/MJc7KgqKV3jGn9kUIEZovSnM&
client_id=my_id&
client_secret=my_secrete&
redirect_uri=hms://redirect_uri
The command returns:
> POST /oauth2/v3/token HTTP/1.1
> Host: oauth-login.cloud.huawei.com
> User-Agent: curl/7.64.0
> Accept: */*
> Content-Type:application/x-www-form-urlencoded
> Content-Length: 430
>
* upload completely sent off: 430 out of 430 bytes
< HTTP/1.1 400 Bad Request
< Date: Mon, 23 Nov 2020 03:38:21 GMT
< Content-Type: application/json
< Content-Length: 67
< Connection: keep-alive
< Cache-Control: no-store
< Pragma: no-cache
< Server: elb
<
* Connection #0 to host oauth-login.cloud.huawei.com left intact
{"sub_error":20152,"error_description":"invalid code","error":1101}
What should I do to get this API call working using cURL as expected?
Authentication code must be urlencoded before sent. The command in the question used that code without urlencoding non-letter characters. Please use the same command with encoded authorization code as parameter to "code" to perform the request to acquire access token
Encoding could be done inline by if doing so is desired
curl --data-urlencode "para1=value1"
Please refer to: Link or using online tool such as : Link
Using other tools to acquire access token is possible as long as the parameters are properly encoded with %2x format.
According to the error information {"sub_error":20152,"error_description":"invalid code","error":1101}, the problem is caused by incorrect code parameters.
It is recommended that you can check whether the value of code in the request is the same as the Authorization Code obtained by the mobile app.
FOR Details,see docs.

Repository/image with invalid name in Sonatype Nexus3 Docker registry

Context
I am using the Docker registry feature in Sonatype Nexus3 (version 3.18.1-01 OSS) to store private Docker images.
A couple of days ago, images with invalid names ended up in the registry, causing multiple reoccurring errors with internal cleanup cron jobs within Nexus3. You can see the faulty repositories names in the v2/_catalog request output below.
$ curl https://registry.example.com/v2/_catalog -i
HTTP/1.1 200 OK
Date: Wed, 11 Mar 2020 12:55:29 GMT
Server: Nexus/3.18.1-01 (OSS)
X-Content-Type-Options: nosniff
Content-Security-Policy: sandbox allow-forms allow-modals allow-popups allow-presentation allow-scripts allow-top-navigation
X-XSS-Protection: 1; mode=block
Docker-Distribution-Api-Version: registry/2.0
Content-Type: application/json
Content-Length: 2941
{
"repositories": [
"MiniProfiler.EF6",
"MiniProfiler.Shared",
...
]
}
At this point, I do not know if these images were pushed in the registry by someone on my team or if they are the result of some unexpected blob store problem - I don't have any way to verify this. Interesting fact: there are NuGet packages named identically in another blob store within the same Nexus instance.
Troubleshooting steps
I have been trying to remove the faulty images from the registry by multiple means, all without success.
Nexus3 GUI
The faulty repositories are not displayed in the Docker registry browser in Nexus' GUI. Neither can they be found by using Nexus' search feature.
Nexus3 embedded OrientDB
I looked for the asset and component classes associated with the faulty repositories in OrientDB. Unfortunately, there are no assets or components with such names in Nexus's database.
Docker registry API v2
I also tried to delete them via the Docker registry API V2, but the invalid name format seems to be causing issues when I attempt to do any operation on the faulty repository.
$ curl https://registry.example.com/v2/MiniProfiler.EF6/manifests/latest -i
HTTP/1.1 400 Bad Request
Date: Wed, 11 Mar 2020 12:58:24 GMT
Server: Nexus/3.18.1-01 (OSS)
X-Content-Type-Options: nosniff
Content-Security-Policy: sandbox allow-forms allow-modals allow-popups allow-presentation allow-scripts allow-top-navigation
X-XSS-Protection: 1; mode=block
Docker-Distribution-Api-Version: registry/2.0
Content-Type: application/json
Content-Length: 165
{
"errors": [
{
"code": "NAME_INVALID",
"message": "invalid repository name",
"detail": [
{
"Name": "MiniProfiler.EF6"
},
{
"Reason": "invalid path component: MiniProfiler.EF6"
}
]
}
]
}
Docker CLI
As expected, the Docker CLI doesn't like the invalid name format either.
$ docker pull registry.example.com/MiniProfiler.EF6
invalid reference format: repository name must be lowercase
If I remove the capital letters from the image name, the registry returns a 404 Not Found error.
$ docker pull registry.example.com/miniprofiler.ef6
Using default tag: latest
Error response from daemon: manifest for registry.example.com/miniprofiler.ef6:latest not found: manifest unknown: manifest unknown
Questions
Has anyone ever encountered such problems with Nexus3? Has anyone ever encountered such problems with another Docker registry implementation?
If anyone has any troubleshooting steps to suggest, I'm pretty much open to anything at this point...
I will also be filing a bug with Sonatype to ensure this situation gets good visibility.

Configuring uWSGI to not interpret PATH_INFO

How can I configure uwsgi to pass in the request path unmodified as PATH_INFO? I.e. if there is a request https://example.com/foo%5F/../bar?x=y, I want PATH_INFO to be literally /foo/../%5Fbar, and not /_bar.
The uWSGI documentation says uWSGI is able to rewrite request variables in lot of advanced ways, but I am unable to find any way to set individual request variables, at least not without modifying the source code of uwsgi.
The reason I want to do is that I have a frontend application which takes user input and then sends a request to http://backend.app/get/USER_INPUT. Trouble is, there is an uwsgi in between, and when the user input is ../admin/delete-everything, the request goes to http://backend.app/admin/delete-everything!
(This uwsgi change I desire will not be the only fix; the frontend app should certainly validate user input, and the backend app should not offer /admin to the frontend app in the first place. But as a measure of defense-in-depth, I'd like my requests to pass uwsgi unmodified.)
I am running bare uWSGI without nginx, i.e. uwsgi --http 0.0.0.0:8000 --wsgi-file myapp/wsgi.py --master --processes 8 --threads 2.
For what it's worth, the backend app that looks into PATH_INFO is Django.
My previous answer holds true for the clients which do url parsing at the source. This answer is applicable, when you can actually get the correct request.
The wsgi.py is run by uwsgi and the application object is called as callable. This in case of Django is WSGIHanlder, which has below code
class WSGIHandler(base.BaseHandler):
request_class = WSGIRequest
def __init__(self, *args, **kwargs):
super().__init__(*args, **kwargs)
self.load_middleware()
def __call__(self, environ, start_response):
set_script_prefix(get_script_name(environ))
signals.request_started.send(sender=self.__class__, environ=environ)
print(environ)
request = self.request_class(environ)
response = self.get_response(request)
response._handler_class = self.__class__
status = '%d %s' % (response.status_code, response.reason_phrase)
response_headers = [
*response.items(),
*(('Set-Cookie', c.output(header='')) for c in response.cookies.values()),
]
start_response(status, response_headers)
if getattr(response, 'file_to_stream', None) is not None and environ.get('wsgi.file_wrapper'):
response = environ['wsgi.file_wrapper'](response.file_to_stream)
return response
I created a sample view to test the same
from django.http import HttpResponse
def index(request, **kwargs):
return HttpResponse("Hello, world. You're at the polls index. " + request.environ['PATH_INFO'])
def index2(request, **kwargs):
return HttpResponse("Hello, world. You're at the polls index2. " + request.environ['PATH_INFO'])
and registered them using below code
from django.urls import include, path
from polls.views import index2, index
urlpatterns = [
path('polls2/', index2, name='index2'),
path('polls2/<path:resource>', index2, name='index2'),
path('polls/', index, name='index'),
path('polls/<path:resource>', index, name='index'),
]
So what you need is overriding this class. Below is an example
import django
from django.core.handlers.wsgi import WSGIHandler
class MyWSGIHandler(WSGIHandler):
def get_response(self, request):
request.environ['ORIGINAL_PATH_INFO'] = request.environ['PATH_INFO']
request.environ['PATH_INFO'] = request.environ['REQUEST_URI']
return super(MyWSGIHandler, self).get_response(request)
def get_wsgi_application():
"""
The public interface to Django's WSGI support. Should return a WSGI
callable.
Allows us to avoid making django.core.handlers.WSGIHandler public API, in
case the internal WSGI implementation changes or moves in the future.
"""
django.setup()
return MyWSGIHandler()
application = get_wsgi_application()
After this can you can see the below results
$ curl --path-as-is "http://127.0.0.1:8000/polls/"
Hello, world. You're at the polls index. /polls/
$ curl --path-as-is "http://127.0.0.1:8000/polls2/"
Hello, world. You're at the polls index2. /polls2/
$ curl "http://127.0.0.1:8000/polls2/../polls/"
Hello, world. You're at the polls index. /polls/
$ curl --path-as-is "http://127.0.0.1:8000/polls2/../polls/"
Hello, world. You're at the polls index. /polls2/../polls/%
As you can see the change to PATH_INFO doesn't change which view is picked. As polls2 still picks index function
After digging a bit more, I realised there is another path and path_info variable. The class for the same is picked using path_info
So we update our function like below
class MyWSGIHandler(WSGIHandler):
def get_response(self, request):
request.environ['ORIGINAL_PATH_INFO'] = request.environ['PATH_INFO']
request.environ['PATH_INFO'] = request.environ.get('REQUEST_URI', request.environ['ORIGINAL_PATH_INFO'])
request.path = request.environ['PATH_INFO']
request.path_info = request.environ.get('REQUEST_URI', request.environ['PATH_INFO'])
return super(MyWSGIHandler, self).get_response(request)
After this change, we get the desired results
$ curl --path-as-is "http://127.0.0.1:8000/polls2/../polls/"
Hello, world. You're at the polls index2. /polls2/../polls/
So your problem has mostly nothing to do with uwsgi or Django as such. To demonstrated the issue, I created a simple flask app with a catch all handler
from flask import Flask
app = Flask(__name__)
#app.route('/', defaults={'path': ''})
#app.route('/<path:path>')
def catch_all(path):
return 'You want path: %s' % path
if __name__ == '__main__':
app.run()
Now when you run this and make a curl request
$ curl -v http://127.0.0.1:5000/tarun/../lalwani
* Rebuilt URL to: http://127.0.0.1:5000/lalwani
* Trying 127.0.0.1...
* TCP_NODELAY set
* Connected to 127.0.0.1 (127.0.0.1) port 5000 (#0)
> GET /lalwani HTTP/1.1
> Host: 127.0.0.1:5000
> User-Agent: curl/7.54.0
> Accept: */*
>
* HTTP 1.0, assume close after body
< HTTP/1.0 200 OK
< Content-Type: text/html; charset=utf-8
< Content-Length: 22
< Server: Werkzeug/0.15.2 Python/3.7.3
< Date: Fri, 26 Jul 2019 07:45:16 GMT
<
* Closing connection 0
You want path: lalwani%
As you can see that the server never had a chance to even know we requested this. Now lets do it again and ask curl not to tamper the url
$ curl -v --path-as-is http://127.0.0.1:5000/tarun/../lalwani
* Trying 127.0.0.1...
* TCP_NODELAY set
* Connected to 127.0.0.1 (127.0.0.1) port 5000 (#0)
> GET /tarun/../lalwani HTTP/1.1
> Host: 127.0.0.1:5000
> User-Agent: curl/7.54.0
> Accept: */*
>
* HTTP 1.0, assume close after body
< HTTP/1.0 200 OK
< Content-Type: text/html; charset=utf-8
< Content-Length: 31
< Server: Werkzeug/0.15.2 Python/3.7.3
< Date: Fri, 26 Jul 2019 07:48:17 GMT
<
* Closing connection 0
You want path: tarun/../lalwani%
Now you can see that my app did receive the actual path. Now let's see the same case in a browser, with app not even running
As you can even though my service is not even running but the browser itself refactored the call to /lalwani instead of /tarun/../lalwani. So there is nothing that could have been done at your end to even correct the issue, until unless you are using a client which supports disabling the url parsing at source

Trying to configure build agent to work with a proxy server

I'm trying to make my build agent work with an already configured proxy server.
The proxy server address is : http://MY_SERVER_DNS:8081
On my build machine inside the agent directory I created a .proxy file which contains the above proxy address and created the relevant environment variables (VSTS_HTTP_PROXY_USERNAME, VSTS_HTTP_PROXY_PASSWORD).
After a restart to the build agent service the indicator in VSTS goes red (instead of green).
A partial (most relevant I guess) agent log is attached:
{ Request = Method: GET, RequestUri: 'https://siemplify.visualstudio.com/_apis/connectionData?connectOptions=1&lastChangeId=-1&lastChangeId64=-1', Version: 1.1, Content: <null>, Headers:
{
User-Agent: VSServices/15.255.65000.0
User-Agent: (NetStandard; Microsoft Windows 6.3.9600)
User-Agent: VstsAgentCore-win7-x64/2.120.2
User-Agent: (Microsoft Windows 6.3.9600)
X-VSS-E2EID: 5aadb1b3-6269-4998-b258-4a5fcc1b9345
Accept-Language: en-US
X-TFS-FedAuthRedirect: Suppress
X-TFS-Session: 13f3aaa0-7f5c-40e1-8af0-0b5feb53d4bc
Expect: 100-continue
}, LoggingRequestId = ab31853f-a392-486f-b288-f9ca4bdee28c, Timestamp = 237057153 }
[2018-03-08 14:15:50Z INFO HttpTrace] Trace System.Net.Http.Response event:
{ Response = StatusCode: 400, ReasonPhrase: 'Bad Request', Version: 1.1, Content: System.Net.Http.StreamContent, Headers:
{
Connection: close
Date: Thu, 08 Mar 2018 14:15:32 GMT
Server: Microsoft-HTTPAPI/2.0
Content-Length: 324
Content-Type: text/html; charset=us-ascii
}, LoggingRequestId = ab31853f-a392-486f-b288-f9ca4bdee28c, TimeStamp = 237507550 }
[2018-03-08 14:15:51Z ERR VisualStudioServices] GET request to https://siemplify.visualstudio.com/_apis/connectionData?connectOptions=1&lastChangeId=-1&lastChangeId64=-1 failed. System.Net.Http.HttpRequestException: Error while copying content to a stream. ---> System.IO.IOException: Unable to read data from the transport connection. The connection was closed before all data could be read. Expected 324 bytes, read 0 bytes.
Any help would be greatly appreciated!
You could first upgrade your private build agent by right-click the agent pool, and then click Update all agents. The latest version of build agent is 2.129.1.
After updating the agent, try to follow the steps in the following link to run a v2 private agent behind a web proxy: VSTS, TFS 2018 RTM and newer:
Pass --proxyurl, --proxyusername and --proxypassword during agent configuration.
For example:
./config.cmd --proxyurl http://127.0.0.1:8888 --proxyusername "1" --proxypassword "1"
Make sure that the proxy file that you created doesn't have spaces around the proxy address which you mention in the proxy file. Make sure you trim it off.
More info here link

Terraform apply access denied error

So I was upgrading Terraform from 0.9.5 to 0.9.6 and I am now getting the following error when I run a jenkins job on a build slave with IAM permissions attached:
terraform096 apply -var db_snap_stamp=171120171217 -var db_snapshot=rds-dev-13102017 -var-file=env.tfvars -no-color
Error loading state: AccessDenied: Access Denied
status code: 403, request id: 288766CE5CCA24A0, host id: FOOBAR
The jenkins job does run terraform init before hand and on my local test server I am not seeing the error. On the local test server I am using an aws credentials file.
I have had a look through the release notes for 0.9.6 but I can't see which of the changes could be causing this ( https://github.com/hashicorp/terraform/issues/14423 maybe?).
Any ideas?
UPDATE
I turned on terraform debug and found that the 403 was happening on a s3 list object. The IAM role in use allows this in 0.9.5 but NOT in 0.9.6 - I tried giving the role admin access but no change:
-----------------------------------------------------
2017/11/17 15:01:47 [DEBUG] [aws-sdk-go] DEBUG: Response s3/ListObjects
Details:
---[ RESPONSE ]--------------------------------------
HTTP/1.1 403 Forbidden
Connection: close
Transfer-Encoding: chunked
Content-Type: application/xml
Date: Fri, 17 Nov 2017 15:01:47 GMT
Server: AmazonS3
X-Amz-Bucket-Region: eu-west-2
The S3 bucket in question does use KMS encryption but all that is set up in the init run prior:
terraform096 init -backend=true -get=true -input=false -backend-config="bucket=${BUCKET}" -backend-config="key=${ENV}.tfstate" -backend-config="region=eu-west-2" backend-config="profile=${AWS_PROFILE}" -backend-config="encrypt=true" -backend-config="kms_key_id=${KMS}"
So I raised this as an issue with Hashicorp and this does look like a bug - if anyone wants to keep an eye on the progress have a look here:
https://github.com/hashicorp/terraform/issues/16710

Resources