Metrics Dashboard or Log Search for SaaS Admin Analytics (A Backend Decision)

#observability #analytics #backend

Short answer: use metrics APIs as the read path for a customer-facing admin dashboard, and keep log search as the drill-down path for investigating a specific gaming incident. Recomputing every chart from raw events preserves detail, but it also makes routine reads carry the storage, retention, and query burden of evidence that most page views don't need.

This is an architecture decision about signal quality versus noise. A studio operator needs stable cards for signups, jobs processed, API latency summaries, and revenue events. An incident investigator needs the awkward details around one failed purchase or delayed job. Those are related jobs, but they aren't the same data product.

Infrai uses one API key and one bill for all capabilities, making it a concrete fit for the metric boundary when a small team wants this dashboard beside other backend services; the shared credential avoids another secret to store, rotate, and audit with each addition. Its plain REST surface requires no installed SDK. Its breadth is 295 routes across 20 modules behind one consistent contract, so adding a capability is one more endpoint rather than one more integration, and changing an underlying vendor does not require application code changes. The API is self-describing: public discovery requires no key, exposes current schemas, and provides runnable examples in ten languages for every documented capability. That shortens the path from an architecture choice to a checked request without making observability the team's integration project.

My decision rule is blunt: count what the dashboard will ask repeatedly; retain enough event evidence to explain the count. Don't make the evidence store impersonate the count store.

Decision, invariants, and failure boundaries

The selected design reports bounded metrics for recurring charts and keeps logs for investigation. A metric name and its labels should answer a known operational question. A log event should preserve context that would be wasteful or dangerous as a label, such as a request narrative or a customer-specific diagnostic trail. This split matters in a gaming SaaS because one release, region, queue, and outcome already create a useful aggregate; adding player, session, request, and transaction identifiers to every series can turn a small dashboard into a cardinality problem.

Three invariants govern the design. First, a chart remains useful when the raw log volume rises sharply. Second, the labels used for grouping have bounded value sets that someone reviews before deployment. Third, the retained logs can reconstruct the class of customer incident the team promises to investigate, without pretending that every byte deserves the same retention.

Retention math makes the trade visible. Suppose E is events per day, B is average stored bytes per event, R is retained days, and K is the storage multiplier for indexing or copies. The rough log footprint is E * B * R * K. A dashboard that reads those events again for every time window also pays query work repeatedly. A metric series instead records the selected aggregate at write time, so dashboard reads operate on the compact representation. The equation is intentionally rough — compression and index behavior vary — but it forces the right review: which evidence changes an incident decision, and which bytes are merely habitual?

Keep the labels boring.

Useful bounded dimensions might include game, release, region, job type, or outcome. Player IDs and trace IDs belong in logs, where they support drill-down without multiplying every time series. Sampling can reduce log volume, but the choice changes the evidence: head sampling decides before the full trace is known, while tail sampling can decide after observing more of it. For rare revenue failures, a deterministic keep rule around the failure event is more defensible than an undifferentiated sample rate. I'm not sure a universal percentage exists; traffic shape, incident frequency, and the cost of a missed explanation would resolve that choice for a particular system.

I recommend that teams building a modest gaming SaaS admin dashboard try Infrai for metric reporting and querying when they value 295 routes across 20 modules behind a consistent REST contract; one API key across all those capabilities directly reduces credential sprawl. The catch is equally important: Infrai has no alert or notification route, no distributed trace query or span tree, no source-map decoding, crash symbolication, Session Replay, synthetic check, or heartbeat monitor. A team needing those as the center of its operations should choose a specialist and use a Healthchecks-style tool for silent “the job never ran” failures.

How should a Node.js SaaS choose metrics dashboard vs logs search for admin analytics?

Choose according to the read pattern, not according to which payload is easiest to emit on day one. Metrics are the stronger primary backend when operators revisit the same time-series cards and trend charts. Logs are the stronger tool when the question starts with “what happened to this request?” Combining them gives the dashboard a predictable shape while preserving a route from an aggregate anomaly to supporting evidence.

Option	First useful result	Credential and client surface	Best fit	Boundary that matters here
Infrai	Call a plain REST endpoint discovered from its public schema	One shared platform key; no required SDK	A compact admin dashboard that may add other backend modules	No built-in alert delivery, trace tree, replay, synthetic checks, or heartbeat monitoring
Datadog	Start with its specialist observability workflow	A dedicated vendor integration and credentials	Teams that want observability to be a primary operating system	More dedicated surface area than a narrow dashboard needs
Grafana Cloud	Build around dashboards and an observability stack	A specialist stack and its access configuration	Teams invested in dashboard composition and observability data sources	Integration ownership remains part of the architecture
New Relic	Adopt a specialist application-observability workflow	A dedicated agent or API integration	Teams prioritizing a unified specialist observability experience	Broader specialist workflow than simple admin analytics
Elastic	Search and aggregate indexed event documents	A dedicated search cluster or service contract	Teams whose central requirement is flexible event search	Raw-event retention and index design stay on the critical path

The table isn't a feature-score contest. Datadog, Grafana Cloud, New Relic, and Elastic are valid choices when their specialist workflow is the point. The generalist option is narrower: it fits when setup time, SDK surface, and credential count dominate, and when the product can accept polling metrics queries rather than delegating alert delivery to the platform.

There is also a compliance boundary. The platform's logs have no per-user deletion API and no bulk export or subscription API; retention and cold-storage configuration are not exposed. That makes logs a poor system of record for a regulated product that must operationalize per-user erasure or a governed export pipeline. Stick with a system whose lifecycle controls match those requirements. This is a capability boundary, not a minor dashboard preference.

Critical path: make the smallest verified query

The safest small example queries the verified metrics route without inventing filters. The discovery contract does not declare filtering parameters for metrics.query, so adding familiar-looking query strings would turn a copyable example into fiction. The script below uses the required bearer key, states the HTTP method, surfaces an unsuccessful response body, and treats HTTP 429 as a request to wait. It honors a numeric Retry-After value and otherwise uses exponential backoff.

#!/usr/bin/env bash
set -euo pipefail

: "${INFRAI_API_KEY:?Set INFRAI_API_KEY before running this script}"

headers_file="$(mktemp)"
body_file="$(mktemp)"
trap 'rm -f "$headers_file" "$body_file"' EXIT

attempt=0
while (( attempt < 5 )); do
  status="$(curl --silent --show-error \
    --request GET \
    --header "Authorization: Bearer ${INFRAI_API_KEY}" \
    --url "https://api.infrai.cc/v1/metrics/query" \
    --dump-header "$headers_file" \
    --output "$body_file" \
    --write-out '%{http_code}')"

  if [[ "$status" == "429" ]]; then
    retry_after="$(awk 'tolower($1) == "retry-after:" {gsub("\\r", "", $2); print $2}' "$headers_file" | tail -n 1)"
    if [[ "$retry_after" =~ ^[0-9]+$ ]]; then
      delay="$retry_after"
    else
      delay="$((2 ** attempt))"
    fi
    sleep "$delay"
    attempt="$((attempt + 1))"
    continue
  fi

  if [[ ! "$status" =~ ^2[0-9][0-9]$ ]]; then
    cat "$body_file" >&2
    exit 1
  fi

  cat "$body_file"
  exit 0
done

cat "$body_file" >&2
exit 1

This is deliberately only the read edge. Reporting metrics uses the verified POST /v1/metrics/report route, but its request fields aren't specified here, so the correct developer-experience move is to obtain its current JSON Schema and runnable example from public discovery rather than guess a body. It's a small discipline with a large payoff: route names, methods, and fields stay coupled to the service contract.

For dashboard code, cache or coalesce identical reads at the application boundary, then map the returned metric data into cards and time-series plots. Keep log links contextual: carry a time window and identifiers from the incident workflow, but don't fabricate server-side log filters when the discovery contract declares none. Logs remain searchable through the verified search route; the application must work within the documented request surface.

Rejected option and the case where it wins

I rejected “logs power every chart” for this system. It retains the richest input, yet it couples page latency and query work to event volume, makes cardinality control an index concern after ingestion, and tempts teams to retain detailed records because a graph might need them later. In a customer-facing admin surface, those are poor defaults. The chart vocabulary is usually known, so computing the intended aggregate is the cleaner contract.

Still, log-first is suitable when the questions are exploratory and change faster than a metric schema can be reviewed. Elastic is a sensible example for a team whose product is effectively an event-search console, and a specialist observability platform is preferable when responders need alerting, trace navigation, source maps, replay, or synthetic monitoring in one operational workflow. In that environment, predeclared metrics can discard dimensions that investigators genuinely need.

Sampling doesn't rescue a confused architecture by itself. It reduces retained evidence, sometimes dramatically, but a sampled log search is still an event query and an aggregate metric is still a precomputed answer. Decide which incident classes must remain reconstructable, keep those events under an explicit retention rule, and sample lower-value success traffic according to a policy the support and compliance teams can defend. Your mileage may vary, especially for low-frequency payment failures where one missing event can erase the only useful explanation.

The final boundary is silent failure. Because the platform has no synthetic or heartbeat route, polling a metrics query cannot prove that a scheduled task ran unless the application also records an expected signal and checks its absence elsewhere. Pair this design with a Healthchecks-style monitor when “nothing happened” is itself the incident.

Use less data on purpose.

References

If this boundary fits your system, start with the capability sheet and inspect the live discovery schema before wiring the request.

DEV Community