The proxy sits in between daemons and the Tideways backend, running on your infrastructure. The added benefit is that you can connect an unlimited number of hosts to Tideways this way.
To make use of the proxy the Tideways daemons on your servers must be configured to send their data to the proxy, only by providing the proxy address to the daemon using the
You can install the proxy through its Apt or Yum repository package name tideways-proxy, after setting up the package repository (documented in Setup)
# on Debian/Ubuntu sudo apt-get install tideways-proxy
# On CentOS/RedHat sudo yum install tideways-proxy
If you need a downloadable tarball please see the Downloads page.
Securly Deploying the Proxy
There are two concerns you should take care of to securly deploy the proxy in your infrastructure, so that traffic between daemons and proxy is encrypted and hidden.
- Setting up TLS certificate
- Restricting access to local network
The proxy server requires use of the TLS protocol, which in turn requires a certificate. By default, a self-signed certificate is generated and put under
/etc/tideways-proxy/proxy.crt with a coresponding private key
/etc/tideways-proxy/proxy.key. When generating the certificate, the proxy uses the value of
--hostname or the OS's hostname (the value of
/bin/hostname in linux) for subject common name.
Note that, by default self-signed certificates are not considered valid by many programs. To fix this copy the public certificate
/etc/tideways-proxy/proxy.crt to all machines running the daemon.
It's possible to make the certificate trusted at a program-level, by providing the certificate file to daemon via
Another option for the daemon to recognize the certificate, is to import the public certificate from
/etc/tideways-proxy/proxy.crt into the certificate store of the operating system of each server running the daemon. In a debian-based system for example, one could copy the public certificate file (not the private key) to
/usr/local/share/ca-certificates and then run
If you do not wanat to use the generated certificate but your own, you can put them into the
/etc/tideways-proxy directory or from a different location using
--cert for the certificate file, and
--private-key for the private key file.
By default the proxy is listening on port 8137 on localhost of the server you are starting it from. This must be changed to use a local network address that both daemons and proxy are apart of. Theoretically it is possible to use a public IP address that is available from the internet, since there exists no API to extract data, but we don't recommend it nevertheless.
The proxy can be configured further, via the following options:
--hostnameChanges the transmitted hostname from the system hostname to a custom defined one.
--debugLog more information into the logfile.
--logpoints to the logfile that should be used. The proxy init scripts use /var/log/tideways/proxy.log by default.
--versionShow proxy version and quit.
--listenThe address that the proxy will be listening on. The default is
--certThe existingTLS certificate file, or path for putting generated certificated. The default is
--private-keyThe TLS certificate's private key, or path for putting generated private key. The default is
You can add flags to the startup of the proxy service by adding a file
/etc/default/tideways-proxy with the variable
TIDEWAYS_PROXY_EXTRA="" defined with the flags of your choice.
TIDEWAYS_PROXY_EXTRA="--hostname=myserver --cert=$HOME/proxy.crt --private-key=$HOME/proxy.key --listen=22.214.171.124:8137"
If you want to change the location of the log file please use
How can I troubleshoot the proxy?
There exists a logfile in
/var/log/tideways/proxy.log if you are using the Ubuntu package or the tarball and invoke
You should make sure the directory
/var/log/tideways is added to logrotation, especially when you enable the
--debug flag. The tarball install script, Ubuntu/Debian and RPM packages do this by default by putting a rotation config file into