From 22e2917b18f9e0544d807a047117b06311f7083b Mon Sep 17 00:00:00 2001
From: Aleksei Lipniagov <alipniagov@gitlab.com>
Date: Thu, 18 Jul 2019 13:54:11 +0000
Subject: Fix pid providing for Prometheus

Use relative worker identifier for metrics (instead of Process.pid) and
identify when Unicorn/Puma/Sidekiq is used.
Previously, it was assumed that all metrics are gathered from Unicorn
due to hardcoded implementation which was incorrect.
---
 lib/prometheus/pid_provider.rb | 42 ++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 42 insertions(+)
 create mode 100644 lib/prometheus/pid_provider.rb

(limited to 'lib')

diff --git a/lib/prometheus/pid_provider.rb b/lib/prometheus/pid_provider.rb
new file mode 100644
index 00000000000..c92522c73c5
--- /dev/null
+++ b/lib/prometheus/pid_provider.rb
@@ -0,0 +1,42 @@
+# frozen_string_literal: true
+
+require 'prometheus/client/support/unicorn'
+
+module Prometheus
+  module PidProvider
+    extend self
+
+    def worker_id
+      if Sidekiq.server?
+        'sidekiq'
+      elsif defined?(Unicorn::Worker)
+        "unicorn_#{unicorn_worker_id}"
+      elsif defined?(::Puma)
+        "puma_#{puma_worker_id}"
+      else
+        "process_#{Process.pid}"
+      end
+    end
+
+    private
+
+    # This is not fully accurate as we don't really know if the nil returned
+    # is actually means we're on master or not.
+    # Follow up issue was created to address this problem and
+    # to introduce more structrured approach to a current process discovery:
+    # https://gitlab.com/gitlab-org/gitlab-ce/issues/64740
+    def unicorn_worker_id
+      ::Prometheus::Client::Support::Unicorn.worker_id || 'master'
+    end
+
+    # See the comment for #unicorn_worker_id
+    def puma_worker_id
+      match = process_name.match(/cluster worker ([0-9]+):/)
+      match ? match[1] : 'master'
+    end
+
+    def process_name
+      $0
+    end
+  end
+end
-- 
cgit v1.2.3