You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hi there, thanks for a very useful project. I noticed an issue running this alongside NGINX with VTS.
We expose the VTS status reports on a virtual server running on port 8080, with IP whitelisting to ensure they can only be accessed from localhost, for security. This is using the following NGINX config (vhost_traffic_status_zone is specified elsewhere):
server {
listen 8080;
server_name localhost;
# Allow localhost (for health checks)
allow 127.0.0.1;
deny all;
# Expose VTS metrics (only on localhost for security)
location = /vts/format/html {
# Exposes vhost traffic status as a HTML report
vhost_traffic_status_display;
vhost_traffic_status_display_format html;
}
location = /vts/format/json {
# Exposes vhost traffic status as a JSON report (the HTML format
# relies on this URL to retrieve data)
# vts exporter also scrapes from this URL
vhost_traffic_status_display;
vhost_traffic_status_display_format json;
}
}
We then run the VTS exporter via the Docker Hub image (digest 8d14166508a5b19ccfd8d75b8933c52f327c7ba5fe728267cd6dc2eb869fd049), specifying NGINX_STATUS=http://localhost:8080/vts/format/json. This URL works fine with curl, but when trying to retrieve metrics, the exporter logs fetchHTTP failed parse "http://localhost:8080/vts/format/json": first path segment in URL cannot contain colon.
This is potentially to do with a change to URL parsing in Go 1.8, although I've not investigated fully: golang/go#19297
Our workaround for now is just to move the vts endpoints to a virtual server listening on port 80, but it'd be really useful to be able to use a different port. Thanks!
The text was updated successfully, but these errors were encountered:
server {
listen 9090;
server_name localhost;
location = /vts/format/html {
# Exposes vhost traffic status as a HTML report
vhost_traffic_status_display;
vhost_traffic_status_display_format html;
}
location = /vts/format/json {
# Exposes vhost traffic status as a JSON report (the HTML format
# relies on this URL to retrieve data)
# vts exporter also scrapes from this URL
vhost_traffic_status_display;
vhost_traffic_status_display_format json;
}
}
logs
Using default tag: latest
latest: Pulling from sophos/nginx-vts-exporter
88286f41530e: Already exists
356cc8ae0daf: Pull complete
6d7f6aaa8b5f: Pull complete
fbdfa9725ab4: Pull complete
Digest: sha256:8d14166508a5b19ccfd8d75b8933c52f327c7ba5fe728267cd6dc2eb869fd049
Status: Downloaded newer image for sophos/nginx-vts-exporter:latest
2017/08/08 02:03:19 Starting nginx_vts_exporter (version=0.4, branch=fix-docker-error, revision=0f3dbb44a86340d65bf3d6abbcc0ee88663cb419)
2017/08/08 02:03:19 Build context (go=go1.8, user=Administrator@LS--20151110SAS, date=20170316-03:16:26)
2017/08/08 02:03:19 Starting Server at : :9913
2017/08/08 02:03:19 Metrics endpoint: /metrics
2017/08/08 02:03:19 Metrics namespace: nginx
2017/08/08 02:03:19 Scraping information from : http://localhost:9090/vts/format/json
Hi there, thanks for a very useful project. I noticed an issue running this alongside NGINX with VTS.
We expose the VTS status reports on a virtual server running on port 8080, with IP whitelisting to ensure they can only be accessed from localhost, for security. This is using the following NGINX config (
vhost_traffic_status_zone
is specified elsewhere):We then run the VTS exporter via the Docker Hub image (digest
8d14166508a5b19ccfd8d75b8933c52f327c7ba5fe728267cd6dc2eb869fd049
), specifyingNGINX_STATUS=http://localhost:8080/vts/format/json
. This URL works fine with curl, but when trying to retrieve metrics, the exporter logsfetchHTTP failed parse "http://localhost:8080/vts/format/json": first path segment in URL cannot contain colon
.This is potentially to do with a change to URL parsing in Go 1.8, although I've not investigated fully: golang/go#19297
Our workaround for now is just to move the vts endpoints to a virtual server listening on port 80, but it'd be really useful to be able to use a different port. Thanks!
The text was updated successfully, but these errors were encountered: