Skip to main content
BonData emits structured JSON logs from every service. Logs are shipped out of the cluster by Fluent Bit and aggregated in New Relic; runtime errors are tracked separately in Sentry; and platform metrics are scraped by an in-cluster Prometheus alongside a New Relic Kubernetes exporter.

​
What is logged

Every BonData service emits a structured record on the events that matter for an audit trail:
  • API requests: the HTTP method and path, the tenant and user the request was attributed to, the duration, the response status, and a request ID that ties together every downstream log line.
  • Authentication events: successful sign-ins, failed sign-ins, MFA challenges, session refreshes, and sign-outs.
  • Agent runs: the agent ID, the trigger, the user who started the run, the nodes that executed, and the final outcome.
  • Integration operations: when a credential is added, refreshed, used, or revoked.
  • Administrative actions: changes made in the management application, including tenant provisioning, role changes, and configuration updates.
All log records include a tenant identifier and the request ID, so an audit reviewer can reconstruct an end-to-end trail from a single log line.

​
Where logs live

In Cloud SaaS, logs are aggregated in New Relic. Retention follows the New Relic plan BonData operates under. Runtime errors are captured in Sentry (UI, API, and backend each in their own Sentry project) with stack traces and request metadata; PII filtering is enabled. In Cloud-Prem, the same log stream is available in the customer’s own account. EKS audit logs and CloudWatch Logs accumulate in the customer’s AWS account by default. Customers can additionally forward application logs to their own SIEM, Splunk, Datadog, Panther, and similar destinations are supported via a Fluent Bit output configuration.

​
AWS-side audit

For both deployment models, AWS CloudTrail records every API action against AWS resources, including every action taken by the BonData operator role in Cloud-Prem. CloudTrail is the customer’s primary audit surface for operator actions in their own AWS account.

​
Request IDs

A single request ID is injected at the ingress layer and propagated through every downstream service. The ID appears in API logs, agent run logs, integration call logs, and Sentry events, so any user-visible event can be traced through the system without correlating timestamps.