LoadSignal
Implemented by
Index
Properties
Methods
Properties
readonlyname
This signal's key in the reported SystemInfo, also used in logging — so it must be unique among the
signals of one ConcurrencySystem, which throws on a duplicate. The four built-in names (memInfo,
eventLoopInfo, cpuInfo, storageBackendInfo) land in the correspondingly named SystemInfo fields rather
than the loadSignalInfo bag; taking one over means switching that built-in off.
readonlyoverloadedRatio
Maximum ratio of overloaded snapshots in a sample before the signal
is considered overloaded. For example, 0.2 means the signal fires
when more than 20% of the sample window is overloaded.
Methods
getSample
Return snapshots for a recent time window (used for "current" status).
Parameters
optionalsampleDurationMillis: number
How far back to look, in milliseconds.
Returns LoadSnapshot[]
start
Start collecting snapshots, retaining at least the sample window named in the
context. Called when the ConcurrencySystem starts — which may be a restart, so drop anything measured before it.Parameters
context: LoadSignalStartContext
Returns Promise<void>
stop
Stop collecting snapshots. Called when the ConcurrencySystem shuts down.
Returns Promise<void>
A signal that reports whether a particular resource is overloaded. The ConcurrencySystem aggregates several of them — if any one reports overload, the system is overloaded.
The built-in signals cover memory, CPU, event loop and storage backend rate limits. Implement this interface to add your own (navigation timeouts, proxy health, …) and pass them via
loadSignals.custom; SnapshotStore does the time-windowed bookkeeping if you want it. Each built-in is also a public class, so one can be wrapped rather than reimplemented — construct it yourself and switch the default off withcpu: falseor friends.