Class: CollectorService
Defined in: core/collector.service.ts:22
Implements
OnModuleDestroy
Constructors
Constructor
new CollectorService(
storage,config,dataMasker?,tagService?,familyHashService?):CollectorService
Defined in: core/collector.service.ts:72
Parameters
storage
config
dataMasker?
DataMaskerService
tagService?
familyHashService?
FamilyHashService
Returns
CollectorService
Accessors
entryStream$
Get Signature
get entryStream$():
Observable<Entry>
Defined in: core/collector.service.ts:62
Observable that emits every entry right after it is persisted.
Returns
Observable<Entry>
Methods
collect()
collect<
T>(type,payload,requestId?):Promise<void>
Defined in: core/collector.service.ts:192
Collect an entry Uses discriminated union pattern - the type parameter determines the expected payload type
Type Parameters
T
T extends "query" | "request" | "exception" | "log" | "cache" | "event" | "job" | "schedule" | "mail" | "http-client" | "redis" | "model" | "notification" | "view" | "command" | "gate" | "batch" | "dump" | "graphql"
Parameters
type
T
payload
Extract<GraphQLEntry, { type: T; }> | Extract<RequestEntry, { type: T; }> | Extract<QueryEntry, { type: T; }> | Extract<ExceptionEntry, { type: T; }> | Extract<LogEntry, { type: T; }> | Extract<CacheEntry, { type: T; }> | Extract<EventEntry, { type: T; }> | Extract<JobEntry, { type: T; }> | Extract<ScheduleEntry, { type: T; }> | Extract<MailEntry, { type: T; }> | Extract<HttpClientEntry, { type: T; }> | Extract<RedisEntry, { type: T; }> | Extract<ModelEntry, { type: T; }> | Extract<NotificationEntry, { type: T; }> | Extract<ViewEntry, { type: T; }> | Extract<CommandEntry, { type: T; }> | Extract<GateEntry, { type: T; }> | Extract<BatchEntry, { type: T; }> | Extract<DumpEntry, { type: T; }>["payload"]
requestId?
string
Returns
Promise<void>
collectImmediate()
collectImmediate<
T>(type,payload,requestId?):Promise<Entry|null>
Defined in: core/collector.service.ts:256
Collect and save immediately (for critical entries like exceptions) Uses discriminated union pattern - the type parameter determines the expected payload type
Type Parameters
T
T extends "query" | "request" | "exception" | "log" | "cache" | "event" | "job" | "schedule" | "mail" | "http-client" | "redis" | "model" | "notification" | "view" | "command" | "gate" | "batch" | "dump" | "graphql"
Parameters
type
T
payload
Extract<GraphQLEntry, { type: T; }> | Extract<RequestEntry, { type: T; }> | Extract<QueryEntry, { type: T; }> | Extract<ExceptionEntry, { type: T; }> | Extract<LogEntry, { type: T; }> | Extract<CacheEntry, { type: T; }> | Extract<EventEntry, { type: T; }> | Extract<JobEntry, { type: T; }> | Extract<ScheduleEntry, { type: T; }> | Extract<MailEntry, { type: T; }> | Extract<HttpClientEntry, { type: T; }> | Extract<RedisEntry, { type: T; }> | Extract<ModelEntry, { type: T; }> | Extract<NotificationEntry, { type: T; }> | Extract<ViewEntry, { type: T; }> | Extract<CommandEntry, { type: T; }> | Extract<GateEntry, { type: T; }> | Extract<BatchEntry, { type: T; }> | Extract<DumpEntry, { type: T; }>["payload"]
requestId?
string
Returns
Promise<Entry | null>
flush()
flush():
Promise<void>
Defined in: core/collector.service.ts:403
Writes what has been buffered, one batch at a time.
Serialised on purpose. Every caller used to start its own write, so a
storage slower than the traffic was handed more and more at once —
measured at thirty concurrent batches against a store taking 300ms each,
with three thousand entries in flight at the peak. MAX_BUFFERED_ENTRIES
is what bounds how much NestLens holds, and entries already on their way
to the storage were outside it.
A second call waits for the one in flight and then writes whatever has accumulated since, so an awaited flush — a shutdown, a test — still writes everything. The timer and the full-buffer path skip instead of queueing: the flush in flight will take what they would have.
Returns
Promise<void>
getBufferSize()
getBufferSize():
object
Defined in: core/collector.service.ts:158
Whether NestLens is keeping up.
pending sitting near capacity means storage is slower than collection,
and dropped says how many entries that has already cost — the buffer
discards its oldest rather than growing without limit, so a rising number
here is the only place that loss is visible.
The performance page has documented a metrics endpoint calling
collector.getBufferSize() for some time and there was no such method: a
reader copying that example got a compile error.
Returns
object
capacity
capacity:
number
dropped
dropped:
number
pending
pending:
number
getRecordingCounts()
getRecordingCounts():
object
Defined in: core/collector.service.ts:174
What was recorded, and what was dropped on the way in.
"Nothing was recorded" and "nothing happened" look identical on the dashboard, and an application spent two days deciding which of the two it was looking at. Sampling and the filter each drop entries deliberately; saying how many turns that question into a glance.
Returns
object
droppedByBuffer
droppedByBuffer:
number
droppedByFilter
droppedByFilter:
number
droppedBySampling
droppedBySampling:
number
recorded
recorded:
number
getRecordingStatus()
getRecordingStatus():
object
Defined in: core/collector.service.ts:138
Get recording status
Returns
object
isPaused
isPaused:
boolean
pausedAt?
optionalpausedAt:Date
pauseReason?
optionalpauseReason:string
onModuleDestroy()
onModuleDestroy():
Promise<void>
Defined in: core/collector.service.ts:595
Lifecycle hook - cleanup on module destroy
Returns
Promise<void>
Implementation of
OnModuleDestroy.onModuleDestroy
pause()
pause(
reason?):void
Defined in: core/collector.service.ts:114
Pause recording
Parameters
reason?
string
Returns
void
resume()
resume():
void
Defined in: core/collector.service.ts:126
Resume recording
Returns
void
shutdown()
shutdown():
Promise<void>
Defined in: core/collector.service.ts:554
Stop flush timer and flush remaining entries
The last flush is given a deadline. A storage that has stopped answering
does not fail here — it simply never returns, and await on it means the
application never finishes shutting down: app.close() hangs, SIGTERM
does nothing, and the process waits for whatever eventually kills it.
Measured against a storage whose save never settles: healthy 1ms, a
throwing storage 302ms, a hanging one still going after six seconds.
A monitoring tool must not be the reason a deployment cannot roll. So the remaining entries get SHUTDOWN_FLUSH_TIMEOUT to reach storage, and after that they are given up — which is the right trade in the one situation where it applies, since a storage that is not answering was not going to keep them anyway.
Returns
Promise<void>