This chapter describes common steps for deploying Divolte Colector in production.
The distributions provided for Divolte Collector are:
Currently, there is no .deb distribution. This will be added in a next release.
In a production scenario, Divolte Collector is typically deployed behind a load balancer, both for fail-over and load balancing. For high availability, users need to ensure that the load balancing infrastructure is highly available. This can be achieved by specialized hardware load balancers or through DNS load balancing. The exact implementation of these are beyond the scope of this document.
Divolte Collector is semi-stateless. This means that it is not required that requests form the same client always go to the same instance; the event will be logged in all cases. Divolte Collector does however build up some soft state during operation for detecting duplicate events and caching parsed user agents. This means that there is benefit in stickyness, but it is not a requirement.
Divolte Collector keeps a short term memory for detecting duplicate requests. In order for this to work, exact duplicate requests need to always go to the same instance. Most load balancers can support this by setting up a routing policy that uses a hash of the requested URI to determine which instance to route the request to. When using duplicate detection, be sure to configure your load balancer to do this.
If possible, load balancers should use a so called consistent hashing scheme when performing URI hash based routing. This ensures that when a instance of Divolte Collector dies, the re-hashing amongst the remaining instances only minimally disrupts the event assignments. The benefit of this is that the duplicate memory kept by Divolte Collector nodes remains effective on the still running nodes.
Divolte Collector does not handle SSL in any way. SSL offloading needs to be done by a load balancer or a reverse proxy server. These systems are generally capable of offloading SSL and since there will always be a load balancer in front of Divolte Collector in production setups, it was decided not to add this functionality to the internal HTTP server.
When using nginx as a reverse proxy and load balancer in front of Divolte Collector, you can use this snippet for configuring nginx:
upstream divolte {
hash $request_uri consistent;
server divolte1.internaldomain:8290;
server divolte1.internaldomain:8290;
}
server {
listen 80;
server_name tracking.example.com;
location / {
proxy_pass http://divolte;
proxy_redirect off;
proxy_buffering off;
proxy_set_header Host $http_host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_pass_header Server;
}
# redirect server error pages to the static page /50x.html
#
error_page 500 502 503 504 /50x.html;
location = /50x.html {
root /usr/share/nginx/html;
}
}
server {
listen 443 ssl;
server_name tracking.example.com;
location / {
proxy_pass http://divolte;
proxy_redirect off;
proxy_buffering off;
proxy_set_header Host $http_host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_pass_header Server;
}
ssl_certificate /etc/nginx/star.example.com.pem;
ssl_certificate_key /etc/nginx/star.example.com.key;
ssl_session_cache shared:SSL:1m;
ssl_session_timeout 5m;
ssl_ciphers HIGH:!aNULL:!MD5;
ssl_prefer_server_ciphers on;
# redirect server error pages to the static page /50x.html
#
error_page 500 502 503 504 /50x.html;
location = /50x.html {
root /usr/share/nginx/html;
}
}