@12-apps/observability-backend

中文文档
1.9.0发布于 2026/08/25MITTypeScriptESM + CJS构建来源已验证近 30 天下载 3.3万

Server-side error reporting on Sentry, attached to the logger rather than to call sites: a Winston transport that forwards error/warn, a PII scrub that redacts by key at any depth, and a flush for a deliberate exit. Off unless SENTRY_DSN is set, so dev, C

原始使用文档
文档目录6 节
  1. Why it exists
  2. Usage
  3. It is OFF unless a DSN is set
  4. PII
  5. Why it ships compiled
  6. Tests

@12-apps/observability-backend

Server-side error reporting on Sentry, for the one environment nobody can attach a debugger to.

It has a browser counterpart, @12-apps/observability-frontend. They are two packages rather than one because they share no code at all, only environment variables — this side is @sentry/node plus winston-transport, the other is @sentry/react plus React, and a single package would put a Winston transport in every SPA's dependency tree and React in every server's. They are independent (either runs without the other) but deliberately share SENTRY_ENVIRONMENT and SENTRY_RELEASE, so a browser event and the 500 behind it land in the same environment under the same build.

Why it exists

A production failure used to leave exactly one trace: a line on stdout inside a container, which dies with it and is reachable only over SSH. So the only way to learn why something broke was to reason about the source and guess — and a run of four consecutive wrong diagnoses is what that costs. The line that would have ended it on the first try existed the whole time; nobody could read it.

Usage

import { sentryTransport, flushReporter, scrub } from "@12-apps/observability-backend";

const reporter = sentryTransport();
const logger = winston.createLogger({
  transports: [consoleTransport, ...(reporter ? [reporter] : [])],
});

It hangs off the LOGGER, not off each call site. A shared logger is already the funnel — every feature's log.error goes through one Winston instance, so attaching here means a new module is covered the moment it logs, with nothing to remember. The alternative, a captureException beside every throw, is a rule that decays the first time someone forgets it.

Note the trap that implies: console.error does not reach the reporter. Winston is the funnel; anything written past it reaches a container's stdout and nowhere else.

exportwhat it does
sentryTransport()the winston-transport to install, or null when reporting is off
sentryEnabled()whether a DSN is configured for this process
flushReporter(timeoutMs?)wait for queued events; call before a deliberate exit
scrub(value)redact PII by key at any depth, for a context object folded into a message

flushReporter() matters more than it looks. The SDK batches and sends asynchronously, so log.error(…) followed by process.exit(1) tears the process down with the event still in memory — losing precisely the report worth having most, since a process that died on boot leaves nothing else behind.

It is OFF unless a DSN is set

No SENTRY_DSN, no transport, no network. Dev, CI and every test run stay silent and offline. Enabling is a deployment decision, never a code one — which is also what keeps a test suite's deliberate failures from filling an issue tracker.

variablenotes
SENTRY_DSNthe only required one. Write-only ingest.
SENTRY_ENVIRONMENTfalls back to NODE_ENV, then production
SENTRY_RELEASEwhich build an error came from
SENTRY_TRACES_SAMPLE_RATEdefaults to 0 — tracing is billed per span and answers "how slow", while this answers "what threw"

PII

scrub() redacts by KEY at any depth rather than pattern-matching values: a Brazilian CPF is eleven digits, and so are plenty of ids worth keeping. Ids and amounts survive on purpose — a scrub that eats them leaves every event undiagnosable.

It is not defensive decoration. The leak it was written for is a provider error that retains the upstream response body, which on a rejected payment carries the payer's name, e-mail and tax id. sendDefaultPii is held off regardless of DSN on top of that, so request bodies, cookies and IPs never ride along.

The transport also sends the message as a string rather than the raw meta object: Winston's formatter runs util.inspect(…, { depth: 5 }) over extra arguments, which is precisely how a provider payload would otherwise reach a third party.

Why it ships compiled

Unlike most packages in this repo, this one publishes dist (dual CJS+ESM with .d.ts) rather than TypeScript source. Two reasons, both load-bearing:

  1. Node refuses to strip types below node_modules (ERR_UNSUPPORTED_NODE_MODULES_TYPE_STRIPPING). A server importing this package from the registry gets a hard failure on raw .ts. It does not fail inside a workspace, where pnpm links the package and Node resolves a realpath outside node_modules — so the bug would first appear in a consumer, after publishing.
  2. CommonJS consumers exist. @12-apps/shared-helpers is CJS with classic moduleResolution, which ignores the exports map entirely and reads main/types.

Tests

pnpm --filter @12-apps/observability-backend test

Nothing reaches the network: the suite asserts the two safety properties — reporting can be switched off, and what it forwards is scrubbed.

版本与发布记录

@12-apps/observability-backend 共发布 16 个版本,首次发布于 2026/08/07;过去 12 个月发布了 16 个版本。最新版本附带 npm provenance 构建来源证明,可追溯到公开的 CI 构建记录。

版本发布日期距今
1.9.0latest2026/08/252 个月前
1.8.12026/08/212 个月前
1.8.02026/08/092 个月前
1.7.02026/08/092 个月前
1.6.02026/08/082 个月前
1.5.32026/08/082 个月前

关于 @12-apps/observability-backend 的常见问题

@12-apps/observability-backend 是什么?

Server-side error reporting on Sentry, attached to the logger rather than to call sites: a Winston transport that forwards error/warn, a PII scrub that redacts by key at any depth, and a flush for a deliberate exit. Off unless SENTRY_DSN is set, so dev, C

如何安装 @12-apps/observability-backend?

在项目目录运行 npm install @12-apps/observability-backend,或使用 pnpm add / yarn add / bun add。

@12-apps/observability-backend 支持 TypeScript 吗?

支持。包内自带 TypeScript 类型声明(package.json 声明了 types 入口),安装后即可获得类型提示,无需再安装 @types 包。

@12-apps/observability-backend 支持 ESM 还是 CommonJS?

同时提供 ES Module 与 CommonJS 入口,import 和 require() 都可以使用,打包工具会自动选择合适的版本。

@12-apps/observability-backend 需要什么版本的 Node.js?

package.json 的 engines 字段要求 Node.js >=22.0.0。版本不符时 npm 默认只给出警告,开启 engine-strict 后会拒绝安装。

@12-apps/observability-backend 可以商用吗?

@12-apps/observability-backend 使用 MIT 许可。宽松许可:允许商业使用、修改和再分发,通常只需在分发时保留原版权与许可声明。以上为概括,不构成法律意见,请以许可原文为准。

@12-apps/observability-backend 的下载量有多少?

根据 npm 官方下载统计,@12-apps/observability-backend 在 2026/10/04 – 2026/11/02 这 30 天内被下载 32,596 次,日均约 1,087 次。下载量会把 CI 构建、镜像同步和作为其他包依赖的安装一并计入,适合横向比较热度,不能直接等同于使用人数。

@12-apps/observability-backend 还在维护吗?

最新版本 1.9.0 发布于 2026/08/25(2 个月前);至今共发布 16 个版本,其中过去 12 个月发布了 16 个;首次发布于 2026/08/07。发布频率只是参考信号:功能稳定的工具可能很少需要更新,建议结合源码仓库的 issue 和提交记录判断。