Settings: system and telemetry

Console → Settings (visible to admin and monitor) is organized into sub-tabs. This page covers the System and Telemetry sub-tabs; for web search see Web search, for SSO see Configure SSO enterprise login, for billing see Configure model pricing and view monthly costs, for audit see Audit and security configuration.

System (#settings/system)

An operations diagnostics panel that reads like kubectl describe / htop: shows this gateway instance's build / runtime identity, upstream health, and real-time memory diagnostics.

• Build / runtime identity: version number, build information, instance identifier, etc., used during troubleshooting to confirm "which build and which instance is running".

• License information: the panel for the current license (LICENSE_KEY) — plan (Professional / Enterprise), billing cycle (monthly / yearly), total memory, instance count limit, per-instance memory, license number, and the online validation's last online time and last result (valid / invalid). Two alert states: grace period (the last online validation was judged invalid, with a countdown of remaining grace days; on expiry it downgrades to the free edition, prompting you to renew or change the key as soon as possible); cluster over limit (reconciliation detected instance count / total memory exceeding the licensed quota — alert only, the gateway keeps serving, prompting you to reduce instances or raise the quota). For the free edition and activation, see Licensing and authorization status.

• Upstream health: per-instance readings of admission resources + per-upstream bad-link status, so on failure, opening the console immediately locates which upstream is problematic:

  • The status conclusion is shown to the right of the panel title (green dot = all upstreams healthy; yellow/red dot = number of affected/saturated upstreams); the bad-link budget and judgment threshold are displayed side by side as badges.
  • Upstream table: lists only affected upstreams (bad-link count > 0 or saturated), showing per row the upstream name, bad-link count (current / budget), and status (saturated = red, counting = yellow), and appears only during failures.
  • Per-instance admission table: one row per instance — in-flight connections, queue depth, processing passes, fd usage, database connection pool (open/limit and waiting columns, hover for per-pool breakdown), bad links. Pool waiting > 0 is a precursor signal of the login cliff — the data plane is squeezing DB connections. In multi-instance mode, the cluster total is appended as a small footnote below the table.
  • Multi-instance (Redis) mode: each instance broadcasts its above summary every 3 seconds (including its own connection-pool readings); the endpoint does cluster-level aggregation — bad-link counts are summed per upstream, saturation is saturated if any instance is saturated, and additive readings such as in-flight connections / queue depth / passes are summed; fd usage and connection pool are process-level readings where summing is meaningless, so they only appear in the per-instance table. On Redis read failure, it degrades to the local view of the instance hit. Memory (single-instance) mode semantics are unchanged.
  • The data source is the read-only endpoint /console/api/upstream-health (polled every 3 seconds); counts are real-time in-flight values, cleared as soon as a request ends, with no failure memory.

• Memory diagnostics: RSS / current usage / limit + a usage bar; decomposes the OOM trigger value into anonymous memory (RSS) + page cache + a small residual, exposing "the gap you can't see just by looking"; plus two diagnostic bars for memory-pressure level and heap-return health, turning abstract numbers into readable judgments.

• Diagnostic download: one-click export of a diagnostic bundle (protoflux-diagnostic-<timestamp>.tar.gz, which archive tools on any OS can double-click to unpack directly), for offline analysis of memory or admission issues. Files in the bundle:

  File	Contents
  meta.txt	Build / runtime identity + allocator configuration
  heap.txt	jemalloc heap profile
  jemalloc-stats.json	Allocator statistics
  upstream-health.json	Upstream bad-link / saturation snapshot + connection budget / fd usage (multi-instance mode: cluster aggregation + per-instance detail)

  Each section is collected independently — if a section's collection fails, only a note is written into that file, without affecting the whole bundle.

For environment variables related to memory admission and spill, see Environment variable reference → Memory admission and spill; for upstream fault isolation and fd budget configuration, see Listening and request limits and Upstream connection retry and routing affinity on the same page; for troubleshooting abnormal memory increases, see Troubleshoot from symptoms.

Telemetry (#settings/telemetry)

One switch: Issue reporting — whether to allow this gateway to send issue and crash reports to Sentry.

• Takes effect immediately when off (both frontend and backend): the backend stops reporting (events are dropped before sending, performance sampling set to 0); the frontend no longer initializes Sentry for new browser sessions, and already-open sessions are forcibly rejected by the tunnel endpoint.
• Persistence: the setting is written to the database (the issue_reporting key in the config_settings table) and survives restarts.
• Multi-instance sync: in Redis mode, synced to other nodes via a config reload broadcast.
• This switch only controls issue reporting and does not affect the gateway's own functionality; changes on this page are admin-only.

The Sentry DSN baked into the image is determined by environment variables such as SENTRY_DSN / SENTRY_FRONTEND_DSN (see Environment variable reference); this switch is a one-click master switch on top of that, without needing to change environment variables or restart.

FAQ

Q: Can monitor change the telemetry switch? No. The Settings page is visible to monitor (read-only); modification operations (including the telemetry switch) are admin-only.

Q: What do I lose by turning off issue reporting? Only stops sending issue/crash reports to Sentry; gateway operation, logs, and statistics are unaffected.

Q: Upstream health shows an upstream is "saturated" — what happens to requests? If the model has other available upstreams, requests automatically route to a healthy upstream; if all candidate upstreams are saturated, requests immediately return 503 + Retry-After rather than queue indefinitely. Saturation judgment is purely real-time in-flight counting — the moment an upstream recovers it is immediately fully usable, with no manual un-banning.

Q: Why is the "Diagnostic download" button grayed out? Two cases: non-admin roles cannot export; or the current instance has no jemalloc heap profiler (only Linux container builds have it), in which case /debug/diagnostic-bundle returns 501 anyway, and the button is disabled to avoid misleading.

Next: Console login and roles for page permissions; Environment variable reference for Sentry-related variables; Audit and security configuration for audit.