@pmate/log
v0.3.1
Published
Browser telemetry for PMate topic logs
Readme
@pmate/log
Browser telemetry written to separate log topics through log-api. A public intake key must first be registered for the exact service, environment, origins and topics. It is not an authentication credential and cannot write directly to Blockchain.
import { createLogger } from '@pmate/log'
const logger = createLogger({
endpoint: 'https://log-api.pmate.chat',
key: 'YOUR_PUBLIC_INTAKE_KEY',
serviceId: 'pmate:developers', environment: 'prod',
})
logger.append('application', { data: { event: 'search', results: 12 } })
logger.append('console', 'Background job finished')Creates PV events (including history navigation), CLS/FCP/INP/LCP/TTFB, and error events by default. Console capture is opt-in. Disable with pageViews, vitals, or errors: false. Initialize once per page; call close() on teardown. Web Vitals observers remain page-lifetime observers but stop emitting after close.
The queue holds at most 200 events by default (configurable up to 1,000), batches at most 50 events/48 KiB and attempts each event at most three times with the original ID/time. On hide/unload, queued topics and final Web Vitals are sent without waiting for an earlier batch, with at most 60,000 bytes outstanding per logger to stay within the browser keepalive limit; delivery is best effort, not guaranteed. Quotas are per public key, per log-api process. Console arguments are bounded and common credential keys are removed. URLs exclude query strings/fragments; use beforeSend(topic, entry) to redact application-specific data or return false to drop it. Never log credentials or request/response bodies.
Page views and performance facts
PV counts and performance measurements have different lifecycles. A slow or missing metric must not delay or create a page view, and changing rating thresholds must not require shipping a browser SDK or invalidate historical measurements.
The pv topic records one event on initial load, pathname navigation, and BFCache
restore, with path, pageViewId, and schemaVersion. The vitals topic records
available measurements separately: name, value, unit (ms, or score for
CLS), metricId, and navigationType, plus the originating path and
pageViewId. Ratings are computed by the consuming analysis layer, never sent by
this SDK. Zero is a real measurement; absent/invalid metrics are not synthesized.
Web Vitals measure a document lifecycle. Delayed measurements stay associated with the original document visit after an SPA route change; they must not be mistaken for measurements of the newly visible route. A BFCache restore starts a new visit. PV and vitals use the existing independent topic batches and retry IDs.
Managed event intake
Use eventKey and appId for service-bound event intake without login. serviceId
and environment are only required with the legacy key. Managed event traffic
uses /event/logs/batch. With an explicit vitals scope, the same key sends Web Vitals to the runtime chain. Other runtime diagnostics require a separate scoped key. Prefer the scenario API web.init({key, appId}) from @pmate/log-sdk/web in application code.
