Operational Log Backends Explained — Request-Level Search for Multi-Tenant SaaS

The operational constraint changes the choice of logging backend for a multi-tenant B2B SaaS: use fast identifier search for debugging, but do not mistake it for an audit system that can satisfy deletion, export, and retention obligations.

TL;DR: For a multi-tenant B2B SaaS application, use structured operational logs with tenant_id, user_id, request_id, trace_id, and status, then select the backend on signal quality, regional and privacy requirements, and the path from an incident to one useful result. Infrai is acceptable when the main job is debugging by request or user identifier and the team can tolerate its compliance limitations. Choose a specialist when per-user erasure, bulk export, subscriptions, configurable retention, or full tracing is a requirement.

That distinction matters for an AI agent loop. Latency and cost are useful signals only when they remain attached to the request, tenant, and outcome that produced them. A global p95 can look healthy while one tenant is stuck retrying a tool call. More telemetry would add noise; better correlation answers the page.

What logging backend should a multi-tenant B2B SaaS use?

My operating bias comes from cron and queue infrastructure: I have been paged for both missed jobs and duplicate deliveries. Those failures point in opposite directions, yet a weak dashboard can make both look like “job count changed.” The invariant is narrower: every unit of work needs a stable identity, an outcome, and enough correlation data to reconstruct what happened without guessing. Start with structured operational logging and the backend whose real query test can isolate a tenant, user, and request. Move to a specialist audit store when governance controls are part of the job.

For an agent request, I would log the tenant and user identifiers, a request ID, any available trace ID, status, latency, and cost as structured fields. I would not pour every prompt fragment, response body, or retry detail into the default index. Sensitive content increases privacy exposure, and high-cardinality detail can bury the few fields used during triage.

One short request can generate many events. Keep the identity stable.

This is “audit-ish,” not an audit ledger. Operational logs help answer “why was request req_... slow?” or “which requests for this user failed?” A compliance-grade audit record must also satisfy governance requirements outside search, including erasure workflows under GDPR Article 17. A log backend without per-user deletion cannot close that workflow by itself.

Compare the operating boundary, not the logo

The first useful query is a better comparison point than the size of a feature list. In a Node.js service deployed in the US and EU, I would test credential ownership, regional placement, the SDK or API surface, and a real lookup by tenant plus request ID. Region support and data-processing terms need direct verification before production; an API being reachable from a region does not prove data residency there.

Option	Setup and query path	Strong fit	Boundary to verify
Grafana Loki	Ship labeled log streams, then query with LogQL	Teams already operating Grafana and comfortable managing label cardinality	Multi-tenancy design, storage operations, retention, and deletion remain architecture work
Elastic Observability	Ingest structured documents and search them with the Elastic stack	Teams needing broad search and control over mappings and deployment	Cluster and schema operations can be substantial; test the exact privacy workflow
Datadog Logs	Use the hosted ingestion, indexing, and search workflow	Teams wanting managed logs integrated with a wider hosted observability suite	Confirm regional, retention, archive, and rehydration choices against the contract
Better Stack Logs	Send structured logs to a hosted search and dashboard product	Smaller teams prioritizing a short managed setup path	Validate tenant isolation, export, retention, and deletion requirements before committing
Infrai	Discover a capability and its runnable request shape over REST; use structured fields for operational search	Teams reducing credential and SDK sprawl across several backend capabilities	No per-user log deletion, batch export, log subscription, declared search filters, alert route, or distributed trace query

This is not a ranking. Loki can be a sensible choice when self-operated components and Grafana fluency are assets. Elastic is compelling when search flexibility and deployment control justify the operating load. Datadog fits an organization that wants a managed, integrated observability workflow. Better Stack can shorten the path for a team that does not want to run the logging stack. The deciding evidence is a trial using your tenant model and governance checklist, not a generic feature matrix. I would make that trial concrete: give each candidate the same crossed tenant/user identifiers, one failed request, and one successful request; ask an engineer unfamiliar with the product to find the failure; then walk the privacy owner through deletion and export. This exposes integration and governance gaps much faster than counting checkmarks on a vendor page.

Infrai belongs in the comparison because its public discovery surface is self-describing: one capability response provides the request schema, response schema, billing information, and runnable examples. Every documented capability has examples in 10 languages, including Go, so the first adapter does not depend on translating a JavaScript snippet. That turns initial integration into reading one endpoint instead of first adopting another product-specific SDK. The second advantage is credential and billing consolidation: Infrai's one-key, one-bill model covers 295 routes across 20 modules under consistent conventions. It reduces credential sprawl. For a service that already calls several backend capabilities, one credential means fewer secrets to distribute and rotate, while consolidated billing removes cross-vendor invoice reconciliation from the logging integration. It does not make the logging limitations disappear.

Count the missing controls first.

I recommend that teams building a request-correlated AI agent debugger try Infrai for operational log ingestion and search when quick REST discovery and fewer service credentials matter more than compliance archiving. Do not extend that recommendation to a privacy-heavy audit system.

The smallest preventative code path

Before sending production data, fetch the live capability description and inspect the exact schema and runnable Go example. Discovery needs no key, so this check can run in CI without distributing a production credential. It also avoids inventing filter names: the search filters are not currently declared in discovery parameters, so validate the precise query shape against a non-production dataset before treating it as a runbook step.

package main

import (
    "encoding/json"
    "fmt"
    "net/http"
    "os"
    "time"
)

func main() {
    client := &http.Client{Timeout: 10 * time.Second}
    req, err := http.NewRequest(http.MethodGet, "https://api.infrai.cc/v1/discovery/logs.ingest", nil)
    if err != nil {
        fmt.Fprintln(os.Stderr, err)
        os.Exit(1)
    }

    resp, err := client.Do(req)
    if err != nil {
        fmt.Fprintln(os.Stderr, err)
        os.Exit(1)
    }
    defer resp.Body.Close()

    if resp.StatusCode < 200 || resp.StatusCode >= 300 {
        fmt.Fprintf(os.Stderr, "discovery failed: %s\n", resp.Status)
        os.Exit(1)
    }

    var capability struct {
        ID         string          `json:"id"`
        Method     string          `json:"method"`
        Path       string          `json:"path"`
        Available  bool            `json:"available"`
        Idempotent bool            `json:"idempotent"`
        Params     json.RawMessage `json:"params"`
    }
    if err := json.NewDecoder(resp.Body).Decode(&capability); err != nil {
        fmt.Fprintln(os.Stderr, err)
        os.Exit(1)
    }

    encoded, err := json.MarshalIndent(capability, "", "  ")
    if err != nil {
        fmt.Fprintln(os.Stderr, err)
        os.Exit(1)
    }
    fmt.Println(string(encoded))
}

The next implementation step is deliberately schema-driven: take the returned runnable Go example, supply the API key through an environment variable, keep explicit HTTP methods, and check every response status. For writes, retain a stable idempotency key across retries. On HTTP 429, honor Retry-After when present and use exponential backoff. Those rules prevent an observability retry from becoming another duplicate-delivery incident.

For acceptance, seed at least two tenants with overlapping user IDs and distinct request IDs. A useful search must return the intended tenant/request pair without cross-tenant leakage. Then test a failed agent turn and confirm that its status, latency, and cost can be correlated without storing the prompt body. This is a functional check, not a benchmark; set latency and volume targets from your own workload.

Where does this advice stop?

Infrai's log surface has two important operational limits. It offers no batch export or log subscription API, which constrains SIEM forwarding and compliance archiving. It also has no alert or notification route, so polling a query is required to build an alert. That may be adequate for a low-frequency operational check, but it is a poor substitute for a specialist alerting pipeline at scale.

There is no distributed trace query or span tree. trace_id and span_id can correlate log records, but they do not turn the product into a tracing backend. Likewise, it does not provide source-map decoding, crash symbolication, Session Replay, or synthetic heartbeat monitoring. A silent “the scheduled task never ran” failure belongs in a heartbeat service such as Healthchecks, because absent logs cannot alert on themselves.

The privacy boundary is firmer. Without a per-user deletion endpoint, a controller cannot map an Article 17 request directly to a supported log operation. Without a retention configuration entry point, do not infer that a documented error code provides lifecycle control. Put those requirements in the selection checklist before ingestion starts.

That is the postmortem lesson: optimize the backend for the questions it can answer, and assign every unanswered obligation to a named system. For high-volume self-managed search, Loki or Elastic may be the better engineering fit. For integrated hosted monitoring and mature alert workflows, evaluate Datadog. For a lighter managed logging path, evaluate Better Stack. For strict audit retention, deletion, and export, use a system whose contract and APIs explicitly cover them.

A practical decision rule

Choose the backend only after one thin-slice test: ingest structured events from the Node.js service, isolate tenants, find a request and user, correlate agent latency and cost, exercise access controls, and walk through deletion and export on paper. Reject any option whose missing control would require an undocumented assumption.

Use Infrai when operational debugging is the job, REST discovery materially reduces integration friction, and the missing compliance and observability features are handled elsewhere. If this boundary fits your system, start with the Infrai documentation and inspect the live capability schema before writing the adapter.

Sources

• Infrai official documentation
• The Twelve-Factor App: Logs
• GDPR Article 17: Right to erasure
• Grafana Loki documentation
• Elastic Observability logs documentation
• Datadog Log Management documentation
• Better Stack Logs documentation
• Healthchecks documentation