2GT-RichandClaude Opus 5
deb71363c9
The two follow-ups left open by v0.23.17. One is a real fix; the other turned out to need explaining rather than fixing. **Redis had no memory ceiling.** v0.23.17 stopped the poller from growing Redis without bound, but nothing stopped anything else from doing so, and the host had no protection either way. Redis now runs with a 512 MB cap (REDIS_MAXMEMORY). The eviction policy is the part worth care. `allkeys-lru` would be actively dangerous here: BullMQ job data carries no TTL, so an LRU sweep across all keys could discard queued work with no trace. `volatile-lru` evicts only keys that set an expiry — which is exactly the poller's caches and in-flight claims, all of which are safe to lose because losing one merely causes an earlier re-poll. Verified rather than assumed: sampled BullMQ job keys report ttl=-1 and poller cache keys 528-3408s. If pressure ever exhausts the volatile keys Redis refuses writes instead of evicting queue state, which is loud and survivable. **The 14% fast-poll failure rate is not a bug.** Current rate across all devices and job kinds is 0% over 1,462 attempts. The historical 230,707 failures were genuine device downtime: device_availability records 324 outages totalling ~1,003 hours across four lab devices, which at a 30-second cadence and two attempts per cycle predicts ~240,700 failures — within 4% of what was recorded. Nothing to fix; retention had simply been hoarding an accurate count. It did expose real waste, though. Periodic polls no longer retry in-job, because the schedule already is the retry: a device that did not answer is unlikely to answer a second later, and each extra attempt occupies a worker for up to the job timeout. On a fleet with several devices down that doubled the capacity they consumed — the same capacity the rest of the fleet was short of in #114. It also doubled the recorded failure count, which is how ~1,000 hours of downtime came to look like 231k distinct faults. User-initiated full syncs keep their retries. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
37 lines
1.3 KiB
Bash
37 lines
1.3 KiB
Bash
# Host ports (maps to the nginx container)
|
|
HTTP_PORT=80
|
|
HTTPS_PORT=443
|
|
TZ=UTC
|
|
|
|
# Browser origins allowed to call the API (comma-separated). Required in production.
|
|
# Docker Compose defaults this for local https://localhost access; override for your domain.
|
|
# CORS_ORIGIN=https://manager.example.com,http://localhost:3000
|
|
|
|
# Database
|
|
DB_PASSWORD=mikrotik_secure_pw
|
|
|
|
# JWT Authentication (change to a long random string)
|
|
JWT_SECRET=changeme_use_a_long_random_secret_at_least_32_chars
|
|
|
|
# Device password encryption key (must be exactly 32 characters)
|
|
ENCRYPTION_KEY=changeme32byteslongencryptionkey
|
|
|
|
# InfluxDB
|
|
INFLUXDB_TOKEN=mytoken123456789
|
|
INFLUXDB_ORG=mikrotik-manager
|
|
INFLUXDB_BUCKET=metrics
|
|
INFLUXDB_ADMIN_PASSWORD=admin_password_123
|
|
|
|
# ─── Poller tuning (see GET /api/system/poller) ──────────────────────────────
|
|
# Raise concurrency if `headroom` in the poller health endpoint drops near 1.0 —
|
|
# below that the queue grows every cycle and devices go stale.
|
|
# POLLER_CONCURRENCY=12
|
|
# POLLER_JOB_TIMEOUT_MS=45000
|
|
# POLLER_INTERVAL_MS=30000
|
|
# POLLER_JOB_RETENTION_SEC=3600
|
|
# POLLER_JOB_RETENTION_COUNT=5000
|
|
|
|
# Redis memory ceiling. Only TTL-bearing keys are evicted (volatile-lru), so
|
|
# queued jobs are never discarded; the cap exists to protect the host.
|
|
# REDIS_MAXMEMORY=512mb
|