tj-scale 1.0.2 → 1.1.0

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: bfa02cccd18ac22e845267ddac5835d60c620e793e65aa34b648d1cc7889eab3
-  data.tar.gz: 28a78e5c2643a400910aaca6d535f191f521c1633a8eaab48d28365aa40835e6
+  metadata.gz: 76a39f424b8bf07fbe1cd0812fa63833e403ce9c5983639e6f2644db2700b798
+  data.tar.gz: 78b517bd5a20e91d617dfbeddea44d085e1808442c24840034252b2140af286f
 SHA512:
-  metadata.gz: a269ea3a6087b6bdf54f40a6ac98960d7e70219049ec02dea5d7de592277fba106c5e77769277bd04b3623e356ad90a03926cb0bfcc7edef0867f37ef1bc11d3
-  data.tar.gz: e2ed378beb3196a9e9508132f04fea691a828ee6359650b8bb8e6daa96c8693199cbb091e06c8ee1d9aa31353596f7af305c23fbe7703ecbf8a35c9fceb78bb7
+  metadata.gz: 8995d5a220b907b77126f766c9f2c7b382cd445c8bd4f3da3b20509e072ef26e84092ee16462a0218693c211d44ad3f65769a10b421c639bdf0d02386a844a59
+  data.tar.gz: d534b2ceb99df75e41b4ee9b2495e00d5e0a105e2cdf9d3c579ef6202242d8ec953a1f71d8026a9f06359d6a03ba8c16dbc4123ac4dde9768dd34cb685d4a686

data/CHANGELOG.md

@@ -7,13 +7,37 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 
 ## [Unreleased]
 
+## [1.1.0] (tj-scale) - 2026-06-12
+
+### Changed
+
+- **Monitor process is now auto-detected from Heroku's `DYNO` env var**: `web.1`
+  monitors web and `worker.1` monitors worker, so one app monitors both process
+  types with no Procfile env prefixes or extra config. `TJ_SCALE_MONITOR_PROCESS`
+  still pins a single process type when set explicitly; off-Heroku (no `DYNO`)
+  the default remains `worker`. Non-web/worker dynos (`release.*`, `run.*`,
+  `scheduler.*`) never start the metrics loop.
+- `target_process` (payload) follows the auto-detected process, so web samples
+  land on web scale rules and worker samples on worker rules automatically.
+
+### Added
+
+- **Custom process types**: any Heroku process type (e.g. `bulk-worker.1`) now
+  runs the monitor and reports job metrics under its own `target_process`, not
+  just `web`/`worker`. Platform dynos (`release`, `run`, `scheduler`, `console`,
+  `rake`) are excluded.
+- **Per-process Sidekiq queue filter**: `TJ_SCALE_SIDEKIQ_QUEUES_<PROCESS>`
+  (process name upcased, non-alphanumerics → `_`, e.g.
+  `TJ_SCALE_SIDEKIQ_QUEUES_BULK_WORKER=low`) overrides the global
+  `TJ_SCALE_SIDEKIQ_QUEUES` for that process, so a bulk fleet can scale on its
+  own queue's backlog while the worker fleet scales on the rest.
+
 ## [1.0.2] (tj-scale) - 2026-06-12
 
 ### Changed
 
 - README fully updated for the `tj-scale` name: install/build/publish instructions,
   repository URLs (`Untechnickle/tj-scale-gem`), and generic example app names.
-- Supersedes 1.0.0 and 1.0.1, which are yanked (same code, stale docs/description).
 
 ## [1.0.1] (tj-scale) - 2026-06-12
 

data/README.md

@@ -153,7 +153,7 @@ Then `bundle install`.
 
 3. **No extra `require`** is needed in `application.rb`: the gem registers a **Rails Railtie** and loads with Rails. Ensure your app already bundles its job backend — **`delayed_job_active_record`** or **`sidekiq`** (the gem auto-detects which one is loaded, or set `TJ_SCALE_JOB_BACKEND` explicitly).
 
-4. Deploy or run the server as usual. The monitoring thread starts only on **`web.1`** or **`worker.1`**, depending on `TJ_SCALE_MONITOR_PROCESS` (see below).
+4. Deploy or run the server as usual. The monitoring thread starts on **`web.1`** and **`worker.1`** automatically (process type auto-detected from Heroku's `DYNO`), so one app reports both web and worker metrics with no extra config. Set `TJ_SCALE_MONITOR_PROCESS` to pin a single process type (see below).
 
 ### 5. Configure environment variables
 
@@ -165,7 +165,7 @@ Configuration is **entirely via environment variables** (and Heroku **config var
 | `TJ_SCALE_API_URL` | Yes | Full URL of the Agent API ingest path: **`POST /api/v1/metrics`** or **`POST /api/v1/sys-logs`** (same handler). Example local: `http://127.0.0.1:5001/api/v1/metrics`. |
 | `TJ_SCALE_TARGET_APP` | No | Heroku app name to scale; defaults to **`HEROKU_APP_NAME`** if unset. |
 | `TJ_SCALE_TARGET_PROCESS` | No | `web` or `worker` to scale; defaults to `TJ_SCALE_MONITOR_PROCESS`. |
-| `TJ_SCALE_MONITOR_PROCESS` | No | `web` or `worker` — only that process’s **`.1`** dyno runs the reporter (default **`worker`**). |
+| `TJ_SCALE_MONITOR_PROCESS` | No | `web` or `worker` to pin the reporter to one process type. Default: auto-detected from `DYNO` (`web.1` reports web, `worker.1` reports worker); **`worker`** when `DYNO` is unset (non-Heroku). |
 | `TJ_SCALE_INTERVAL_SECONDS` | No | Seconds between posts (default **20**). |
 | `TJ_SCALE_JOB_BACKEND` | No | Queue backend for the **worker** reporter: `delayed_job`, `sidekiq`, or `auto` (default). `auto` uses Sidekiq when the `sidekiq` gem is loaded, otherwise Delayed Job. |
 | `TJ_SCALE_SIDEKIQ_QUEUES` | No | Sidekiq backend only: comma-separated queue names to count (empty = all queues). |
@@ -272,7 +272,7 @@ heroku config:set TJ_SCALE_API_TOKEN=your_api_token_here
 heroku config:set TJ_SCALE_API_URL=https://your-control-plane.example.com/api/v1/metrics
 ```
 
-The `DYNO` environment variable is automatically set by Heroku and is used to determine which dyno should run the monitoring loop (only `web.1` or `worker.1`, depending on `TJ_SCALE_MONITOR_PROCESS`).
+The `DYNO` environment variable is automatically set by Heroku and is used to determine which dynos run the monitoring loop: `web.1` and `worker.1` each report their own process type (override with `TJ_SCALE_MONITOR_PROCESS`).
 
 ### Example: web on `my-app-web`, workers on `my-app-workers`
 
@@ -307,7 +307,7 @@ Ensure both apps have the `web` / `worker` process types in the `Procfile` as ne
 
 ### Automatic Monitoring
 
-Once installed and configured, the gem starts monitoring on the first dyno of the configured process type (`web.1` or `worker.1`, see `TJ_SCALE_MONITOR_PROCESS`). The loop runs every `TJ_SCALE_INTERVAL_SECONDS` (default 20) and POSTs metrics to the configured API.
+Once installed and configured, the gem starts monitoring on the first dyno of each process type (`web.1` and `worker.1`; pin one with `TJ_SCALE_MONITOR_PROCESS`). The loop runs every `TJ_SCALE_INTERVAL_SECONDS` (default 20) and POSTs metrics to the configured API.
 
 ### Manual Usage
 
@@ -338,7 +338,7 @@ ENV['TJ_MAX_PRIORITY'] = '10'
 
 ## How It Works
 
-1. **Initialization**: When your Rails application starts, the `Railtie` checks if it's running on the first monitored dyno (`web.1` or `worker.1`, per `TJ_SCALE_MONITOR_PROCESS`)
+1. **Initialization**: When your Rails application starts, the `Railtie` checks if it's running on the first dyno of a monitored process type (`web.1` or `worker.1`, auto-detected from `DYNO`; `TJ_SCALE_MONITOR_PROCESS` pins one)
 2. **Background Thread**: If conditions are met, a background thread is started
 3. **Monitoring Loop**: Every N seconds (`TJ_SCALE_INTERVAL_SECONDS`), the thread POSTs a payload: on **worker** reporters it counts waiting jobs on the active backend; on **web** reporters it sends router queue time (middleware / env) plus request volume and average response time for the interval.
 4. **Job counting (worker reporters, Delayed Job backend)**: `pending_job_count` filters jobs based on:

data/lib/tj-scale.rb

@@ -11,8 +11,10 @@ require "tj_scale_ruby/models/tj_scale_ruby"
 # TJ Scale (the control plane) scales Heroku formation when ingested metrics cross rules
 # you configure there. This gem only **reports signals**; it never calls Heroku directly.
 #
-# **Where it runs:** A single background thread on **one** dyno — the first dyno of the
-# process you choose (`web.1` or `worker.1` via +TJ_SCALE_MONITOR_PROCESS+). Heroku sets +DYNO+.
+# **Where it runs:** A single background thread on the **first dyno of each process type**.
+# The process is auto-detected from Heroku's +DYNO+ (`web.1` monitors web, `worker.1` monitors
+# worker — so one app monitors both with no extra config). Set +TJ_SCALE_MONITOR_PROCESS+ to
+# pin a single process type instead; off-Heroku (no +DYNO+) the default is `worker`.
 #
 # **What it sends:** On each tick (+TJ_SCALE_INTERVAL_SECONDS+), it POSTs JSON to
 # +TJ_SCALE_API_URL+ (e.g. +/api/v1/metrics+ or +/api/v1/sys-logs+ — same handler on the
@@ -21,12 +23,12 @@ require "tj_scale_ruby/models/tj_scale_ruby"
 # includes +heroku_app+ and +target_process+; scaling limits (min/max dynos) live in the
 # control plane's settings, not in this gem.
 #
-# - **Worker monitor** (+TJ_SCALE_MONITOR_PROCESS=worker+): counts waiting jobs
+# - **Worker monitor** (on +worker.1+): counts waiting jobs
 #   (+job_count+, +queue_time_s+) on the configured queue backend — **Delayed Job** or **Sidekiq**,
 #   toggled with +TJ_SCALE_JOB_BACKEND+ (+delayed_job+ / +sidekiq+ / +auto+, the default, which
 #   prefers Sidekiq when loaded). Delayed Job needs +delayed_job_active_record+ and a shared DB;
 #   Sidekiq needs the +sidekiq+ gem and Redis (+TJ_SCALE_SIDEKIQ_QUEUES+ limits counted queues).
-# - **Web monitor** (+TJ_SCALE_MONITOR_PROCESS=web+): sends +queue_time_ms+ from Rack middleware
+# - **Web monitor** (on +web.1+): sends +queue_time_ms+ from Rack middleware
 #   (router queue via +X-Request-Start+) when +TJ_SCALE_ENABLE_QUEUE_TIME_MIDDLEWARE=1+, plus
 #   request volume and average +response_time_ms+ for the tick. Without middleware, set
 #   +TJ_SCALE_QUEUE_TIME_MS+ or the platform will not scale on queue time until data exists.
@@ -69,7 +71,8 @@ module TjScaleRuby
     end
   end
 
-  # True when this dyno should run the metrics loop (first of TJ_SCALE_MONITOR_PROCESS).
+  # True when this dyno should run the metrics loop: the first dyno (.1) of the
+  # monitored process type (auto-detected from DYNO, or TJ_SCALE_MONITOR_PROCESS).
   # Result is memoized; cleared by {.reset_configuration!}.
   def self.monitor_on_this_dyno?
     return @monitor_on_this_dyno if defined?(@monitor_on_this_dyno)

data/lib/tj_scale_ruby/configuration.rb

@@ -5,14 +5,21 @@ module TjScaleRuby
   class Configuration
     DEFAULT_INTERVAL_SECONDS = 20
     JOB_BACKENDS = %w[auto delayed_job sidekiq].freeze
+    # Any Heroku process type (web, worker, bulk-worker, …) is monitorable;
+    # platform dynos never run app monitoring.
+    PROCESS_NAME = /\A[a-z][a-z0-9_-]*\z/
+    NON_APP_PROCESSES = %w[release run scheduler console rake].freeze
 
     attr_reader :monitor_process, :interval_seconds,
       :min_priority, :max_priority, :job_backend, :sidekiq_queues
 
     def initialize(env = ENV)
-      @monitor_process = normalize_process(env["TJ_SCALE_MONITOR_PROCESS"]) || "worker"
+      @monitor_process = normalize_process(env["TJ_SCALE_MONITOR_PROCESS"]) ||
+        process_from_dyno(env["DYNO"]) || "worker"
       @job_backend = normalize_job_backend(env["TJ_SCALE_JOB_BACKEND"])
-      @sidekiq_queues = parse_list(env["TJ_SCALE_SIDEKIQ_QUEUES"])
+      @sidekiq_queues = parse_list(
+        env[sidekiq_queues_key(@monitor_process)] || env["TJ_SCALE_SIDEKIQ_QUEUES"]
+      )
       @interval_seconds = parse_positive_int(env["TJ_SCALE_INTERVAL_SECONDS"], DEFAULT_INTERVAL_SECONDS)
       @target_app = nonempty_string(env["TJ_SCALE_TARGET_APP"])
       @heroku_app_name = nonempty_string(env["HEROKU_APP_NAME"])
@@ -33,11 +40,24 @@ module TjScaleRuby
 
     private
 
+    # Auto-detect from Heroku's DYNO (web.1 → web, worker.1 → worker) so one app
+    # can monitor both process types without per-process env. Nil off-Heroku and
+    # for non-web/worker dynos (release.1, run.x, scheduler.x).
+    def process_from_dyno(dyno)
+      normalize_process(dyno.to_s.split(".").first)
+    end
+
     def normalize_process(value)
       p = value.to_s.strip.downcase
-      return nil if p.empty?
+      return nil if p.empty? || NON_APP_PROCESSES.include?(p)
+
+      PROCESS_NAME.match?(p) ? p : nil
+    end
 
-      %w[web worker].include?(p) ? p : nil
+    # Per-process Sidekiq queue filter, e.g. TJ_SCALE_SIDEKIQ_QUEUES_BULK_WORKER=low
+    # for a +bulk-worker+ process; falls back to TJ_SCALE_SIDEKIQ_QUEUES.
+    def sidekiq_queues_key(process)
+      "TJ_SCALE_SIDEKIQ_QUEUES_#{process.to_s.upcase.gsub(/[^A-Z0-9]/, '_')}"
     end
 
     # "delayed_job" | "sidekiq" | "auto" (default; detects from loaded gems).

data/lib/tj_scale_ruby/version.rb

@@ -2,5 +2,5 @@
 
 # Version module for TjScaleRuby gem
 module TjScaleRuby
-  VERSION = "1.0.2"
+  VERSION = "1.1.0"
 end

metadata

@@ -1,7 +1,7 @@
 --- !ruby/object:Gem::Specification
 name: tj-scale
 version: !ruby/object:Gem::Version
-  version: 1.0.2
+  version: 1.1.0
 platform: ruby
 authors:
 - Tanuj