Datadog Browser Logs

Web apps that already use the Datadog browser logs SDK (@datadog/browser-logs) can send their logs to KubeSense without changing a single logging call. The SDK posts to the KubeSense RUM endpoint through its proxy option instead of Datadog's intake, and the logs are stored with your other logs, so they show up on the Logs page.

The app team changes only the SDK's init (and, optionally, names a cluster). KubeSense runs the collector, the aggregator and ClickHouse.

How it flows

Browser (Datadog logs SDK)
   │  POST https://<KUBESENSE_RUM_HOST>/api/v2/proxy?ddforward=/api/v2/logs...
   ▼
Ingress / load balancer (HTTPS)
   ▼
KubeSense collector (kubecol, RUM port 34443)
   │  checks the client token, adds browser / OS / geo, builds kube_logs rows
   ▼
KubeSense aggregator (rum_logs source)  ── or straight to ClickHouse (destination: datastore)
   │  parsing and block rules, like every other log
   ▼
ClickHouse (kube_logs.logs)  →  Logs page

The collector answers every accepted upload with 202 right away and forwards the rows in the background, in batches.

1. What the app team changes

Two settings point the Datadog logs SDK at KubeSense: proxy and a KubeSense clientToken. The rest is standard Datadog SDK code, and logging calls stay as they are.

npm (recommended)

Use npm rather than the CDN: ad blockers often block Datadog's CDN.

npm install @datadog/browser-logs

import { datadogLogs } from '@datadog/browser-logs'

datadogLogs.init({
  clientToken: '<KUBESENSE_CLIENT_TOKEN>',
  site: 'datadoghq.com',
  proxy: 'https://<KUBESENSE_RUM_HOST>/api/v2/proxy',
  service: 'web-shop',
  env: 'prod',
  version: '1.4.2',
  sessionSampleRate: 100,
  forwardErrorsToLogs: true,
  forwardConsoleLogs: ['error', 'warn'],
})

// Optional: file the logs under one of your Kubernetes clusters
datadogLogs.setGlobalContextProperty('cluster', 'prod-eu')

datadogLogs.logger.info('checkout started', { cartId: 'c-42' })

CDN

Load https://www.datadoghq-browser-agent.com/us1/v6/datadog-logs.js and call DD_LOGS.init({ ... }) with the same options.

Cluster (optional)

The cluster context property names the Kubernetes cluster the logs belong to. It must be a cluster KubeSense already knows: one whose pods its sensors report, as listed in the Logs page's cluster selector. Any other name is ignored: the logs go under rum, and the name sent is kept in the cluster attribute. Without it, the logs go under rum.

Also check

• Content Security Policy: allow https://<KUBESENSE_RUM_HOST> in connect-src.
• One destination per init: with proxy set, logs go only to KubeSense, not to Datadog as well.
• Datadog RUM on the same page: point it at the same proxy URL, so its sessions and views reach KubeSense too and the logs link to them.
• SDK version: this was checked against the Datadog browser SDK v6.

2. What KubeSense sets up first

Three things must be in place before the app team starts. Without the last two, uploads are still answered 202, but the logs are discarded.

2.1 A RUM application and its client token

Create the application in Settings → RUM Application Management and give its client token to the app team. Its name becomes the logs' app name.

2.2 A public RUM endpoint with the proxy path

The RUM endpoint must be reachable from browsers over HTTPS. On the Ingress that already routes /rum/api/v1 to the collector, add /api/v2/proxy to the same backend:

- path: /api/v2/proxy
  pathType: Prefix
  backend:
    service:
      name: kubesense-kubecol
      port:
        number: 34443   # kubecol.rum.service.port

To check the route, send a request without a token:

curl -s -X POST "https://<KUBESENSE_RUM_HOST>/api/v2/proxy?ddforward=%2Fapi%2Fv2%2Flogs%3Fddsource%3Dbrowser"
# {"error":"Api Key header is missing"}   → 401: the collector answered, the route works

A 404, or the web app's HTML, means the path is not routed to the collector yet.

2.3 Tell the collector where the logs go

Enable RUM logs in the kubesense-server Helm values. Pick the destination:

• aggregator (recommended): the Vector aggregator writes kube_logs.logs, applying its parsing and block rules, like every other log.
• datastore: the collector writes kube_logs.logs itself.

Through the aggregator:

kubecol:
  rum:
    enabled: true
    logs:
      enabled: true
      destination: aggregator

aggregator:
  sources:
    rum_logs:
      enabled: true
      port: 6012        # the aggregator's rum_logs source; kubecol follows it

Straight to ClickHouse:

kubecol:
  rum:
    enabled: true
    logs:
      enabled: true
      destination: datastore

Then run helm upgrade as usual.

With destination: aggregator, the chart:

• adds a rum_logs HTTP source on the aggregator (port 6012 by default) and opens it on the aggregator Service (in-cluster only),
• adds a logs_rum_table_transform that feeds the existing unparsed_logs pipeline,
• keeps the attributes a browser log arrives with when its message also parses as JSON or logfmt,
• writes the collector's aggregator.url and rum_collector_config.logs.aggregator_port to match.

The render fails with a clear message if destination: aggregator is set but aggregator.sources.rum_logs.enabled is not, so the two sides cannot drift apart.

Collector tuning (optional)

The collector sends to the aggregator in batches of up to 1000 rows. The defaults suit most installs; override them under kubecol.config.aggregator:

3. Where the logs show up

Browser logs appear on the Logs page beside pod and OTel logs. Filter on Source = rum to see only them.

Everything else is in the log's attributes. Numbers are stored as numbers, so they can be compared, except ids (id, *.id, *_id, *Id, *ID) and very large whole numbers. Those are kept as text, exactly as sent.

• Origin (origin): logger, console, source (uncaught errors), network (failed requests) or report.
• Context: session.id, view.url, view.id, usr.*, account.*.
• Errors and requests: error.kind, error.message, error.stack, http.method, http.status_code, http.url.
• Added by KubeSense: browser, OS, device, IP, country and city.
• Your own context: what you pass to logger.info(message, {...}) or setGlobalContextProperty, with nested keys flattened, e.g. cart.id.

Timestamps

A log keeps its own date when it lies within the last 24 hours (or up to 1 hour ahead). One dated outside that window, or with a date that can't be read, is stored at the time KubeSense received it, and the date it was sent with is kept in the date attribute: check the device clock if logs show up at an unexpected time.

4. Troubleshooting

To query them directly:

SELECT timestamp, cluster, app_name, workload, level, body,
       string_attributes['origin'] AS origin
FROM kube_logs.logs
WHERE source = 'rum' AND timestamp > now() - INTERVAL 15 MINUTE
ORDER BY timestamp DESC
LIMIT 20;