feat(observability): Compute-driven logging, tracing, and dashboard - #507
Draft
Simone319 wants to merge 5 commits into
Draft
feat(observability): Compute-driven logging, tracing, and dashboard#507Simone319 wants to merge 5 commits into
Simone319 wants to merge 5 commits into
Conversation
Rework observability so it composes correctly across multiple computes, keying off compute state rather than the Logger/Tracer/Dashboard blocks poking a single implicit compute. - Logging is always on; retention is a compute-level setting (LambdaCompute `logRetention` prop, falling back to `defaults.logRetention`). The CDK `Logger` is a no-op placeholder and its `retention` option is removed. - App-wide default log level is a new `BlocksDefaults.logLevel`, stamped once as the `LOG_LEVEL` runtime config; a Logger's `level` still wins per instance. - Tracing is presence-gated: any `Tracer` in the app enables X-Ray on every compute via a new core tracer registry (`registerTracer`/`finalizeTracing`), run before dashboard finalize. `Compute.enableTracing()` is idempotent. - Dashboard is organized by compute with `computes?` (defaults to all, resolved at finalize) plus `logs`/`traces` display toggles. Health + logs always render; traces render when the compute is traced. Removed the deprecated `LoggerBBRef`/`TracerBBRef` types. Updates all Compute-subclass test stubs, rewrites bb-logger/bb-dashboard CDK tests for the new model, refreshes READMEs/DESIGN docs and API reports.
🦋 Changeset detectedLatest commit: 6b9dd27 The changes in this PR will be included in the next version bump. This PR includes changesets to release 24 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
…lity.ts Rename widgets.ts to observability.ts and fold the X-Ray tracing activation (previously inline in LambdaCompute.applyTracing) into it, so all of the compute's observability — tracing infra plus the dashboard health/logs/traces widget builders — lives in one module. The class body now delegates: applyTracing() calls applyXRayTracing(), keeping index.cdk.ts focused on the compute's core function + gateway wiring. No behavior or public API change (observability.ts is package-internal).
…is public Drop the `computes?: Compute[]` option from the public DashboardOptions. It leaked the internal `Compute` type before customers can construct a compute to pass. The dashboard still works: its finalizer always covers every compute in the app via getComputes() (complete today — one default compute), so behavior is unchanged. Add a TODO(multi-compute) in index.cdk.ts describing the intended behavior when the option returns: resolve `options.computes ?? getComputes(this)`, where an explicit list restricts/orders the rendered computes and omitting it keeps the cover-every-compute default. Update README/DESIGN/changeset and drop the explicit-computes test.
Drop the app-wide log-level knob entirely: log level is now set solely
per-Logger via the `level` option (default 'info').
- Remove `logLevel` from `BlocksDefaults` and both presets.
- Remove the central `registerConfig('LOG_LEVEL', ...)` in blocks-backend
setup, so no LOG_LEVEL config is stamped on computes.
- Remove the `process.env.LOG_LEVEL` fallback from the runtime Logger and
its env-var tests.
- Update bb-logger docs (DESIGN, README, JSDoc) and the observability
changeset to reflect the removal.
…pute-driven model Fix comments/JSDoc that described the pre-PR "Logger/Tracer attached to a compute" model, which no longer holds: logs are always captured per compute and tracing is fleet-wide presence-gated. - types.ts: rewrite the metrics JSDoc parenthetical and the ResolvedDashboardConfig note (logs always-on; traces fleet-wide; toggles). - widgets.ts: correct the per-compute logs/traces comments and drop the two dead resolveConfig() bullets (log-group / tracing resolution was removed). - index.mock.ts: stdout logging is per-compute, not a Logger-BB responsibility. - changeset: bump bb-logger and bb-tracer patch -> minor (both carry breaking pre-1.0 behavior changes, matching the other packages in this changeset).
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The model
Logging — always on; retention is a compute prop.
Every compute captures stdout to its own log group unconditionally — there is no "enable logging" step. Retention moves to the compute:
LambdaComputegains alogRetentionprop that overrides the stack-widedefaults.logRetention. The CDKLoggerbecomes a no-op placeholder, and itsretentionoption is removed. Any number of Loggers coexist freely.Log level — per-instance only.
Log level is set solely per
Loggervia theleveloption (default'info'). There is no app-wideBlocksDefaults.logLeveland noLOG_LEVELenv var — Blocks stamps no log-level config, and the runtimeLoggerno longer readsLOG_LEVEL. Multiple Loggers with different levels coexist without any shared config.Tracing — presence-gated, fleet-wide.
Creating any
Tracerin the app enables X-Ray on every compute. X-Ray provisions real, costed infrastructure, so it stays off until the app opts in by constructing a Tracer. Implemented with a core tracer registry:registerTracer()records presence,finalizeTracing()enables tracing on all computes at finalize (before the dashboard finalize).Compute.enableTracing()is idempotent, so multiple Tracers are safe.Dashboard — compute-state-driven, finalize-deferred.
DashboardOptionsgainslogs?: boolean/traces?: boolean(defaulttrue) — app-wide display toggles applied uniformly to every compute section. The dashboard covers every compute in the app (resolved at finalize, so construction order never matters); nocomputesselector is exposed yet, since it would leak the internalComputetype before customers can construct one to pass.Each compute renders a health section always, a logs section (unless
logs: false), and a traces section only when tracing is enabled on it (unlesstraces: false). Metrics remain app-scoped and are passed explicitly. The deprecatedLoggerBBRef/TracerBBReftypes are removed — the dashboard reads compute state directly.Loggerno longer reconfigures log retention; theretentionoption was removed fromLoggingOptions. SetlogRetentionon the compute instead.Tracernow enables X-Ray on all computes, not one.Loggerno longer reads theLOG_LEVELenv var; log level is set solely via the per-Loggerleveloption (default'info'). Blocks stamps no app-wide log-level config, andBlocksDefaultshas nologLevelfield.LoggerBBRef/TracerBBRefdashboard types.Testing
npm run build,npm run lint:deps,npm run check:api, and unit tests for all touched packages pass on Node 22 (core 758, bb-logger 57, plus blocks, bb-dashboard, bb-tracer, bb-lambda-compute, bb-async-job, bb-cron-job). e2e not run in this draft.