Short answer: use a metrics API for the charts that a Node.js SaaS admin dashboard reads repeatedly, and keep log search for investigating the individual nightly pipeline events behind an unusual point.
For a property-management platform, that means reporting counts and latency summaries for the nightly import as metrics, then retaining structured logs as evidence when an operator needs to inspect one execution. Metrics fit time-series cards such as jobs processed, API latency summaries, signups, and revenue events. Recomputing those cards from raw logs on every refresh is a weaker fit and makes the cost of one tenant, panel, or refresh cycle harder to attribute.
Keep both. Give them different jobs.
What should a Node.js SaaS use for an admin analytics metrics dashboard?
Start with the question the operator must answer. A dashboard should expose a trend or summary quickly enough to support a decision: did the nightly property import run, how much work did it report, and did its summary move outside the service objective? A log search answers a different question: what happened inside a particular execution? Treating the two stores as interchangeable hides that difference until query volume grows or an investigation needs original event detail.
The capacity-planning reflex here is straightforward. Dashboard demand is driven by active viewers, panels, refresh frequency, and retries; investigation demand is driven by incidents and support cases. Put those terms in the forecast separately. A repeated chart read belongs in the predictable pool, while a log search belongs in the bursty pool. This doesn't require a fabricated benchmark. It requires an owner, a query budget, and a freshness SLO that says how stale the admin view may become.
Cost attribution should follow the same boundary. Define the application dimensions that matter to the business before reporting telemetry, such as the property-management account, pipeline job, and reporting day, then account for metric writes, chart reads, and investigative searches as separate activities. Those dimensions describe the application design, not undocumented API filters. The discovery parameters for both metrics query and log search are undeclared, so don't invent tenant_id, from, or similar query strings and assume the server accepts them.
I'm not sure one refresh policy will suit both a small property manager and a national portfolio; your mileage may vary. Resolve that uncertainty with representative request volume and a stated freshness objective, not with a vendor demo.
How does the nightly pipeline integrate heartbeat coverage?
A low metric can mean the pipeline processed less work. No metric at all can mean the job never started, which is a different failure mode and an easy one to miss if the team expects the dashboard to monitor its own producer. The observability surface described here has no synthetic-check or heartbeat route, so use Healthchecks or an equivalent scheduler-aware tool to watch whether the nightly task ran. This is operationally separate from choosing metrics over logs, and it should remain separate during rollback.
No signal, no guesswork.
Alert delivery also stays with the platform team because threshold, phone, SMS, and webhook notification routes are absent. A team can poll the metrics query API, evaluate a threshold, and deliver its own notification, but that work belongs in the on-call budget. If owning that loop is unacceptable, choose a product with the required alerting workflow rather than disguising an alert service as a few lines in the dashboard backend.
Logs still matter after an alert or suspicious chart point. Keep the current structured-log investigation path and correlate entries with the available trace and span identifiers where useful, while recognizing that there is no distributed trace query or span tree. The chart should lead an operator toward evidence; it should not pretend that repeated log aggregation is a metrics system.
How does a staged rollout isolate the Go service?
Keep the upstream credential behind the Node.js application boundary. A small internal Go adapter can own authentication, timeout, rate-limit handling, response checks, and later caching, while the browser receives only the application's admin endpoint. The sample below deliberately sends no filters because none are declared for metrics.query; it calls the one verified read route, preserves the response body, and makes every HTTP method explicit.
package main
import (
"context"
"fmt"
"io"
"log"
"net/http"
"os"
"strconv"
"strings"
"time"
)
const metricsQueryPath = "/v1/metrics/query"
func retryDelay(header string, attempt int) time.Duration {
if seconds, err := strconv.Atoi(header); err == nil && seconds >= 0 {
return time.Duration(seconds) * time.Second
}
if when, err := http.ParseTime(header); err == nil {
if delay := time.Until(when); delay > 0 {
return delay
}
}
return time.Duration(1<<attempt) * time.Second
}
func queryMetrics(ctx context.Context, client *http.Client, key, baseURL string) ([]byte, string, error) {
for attempt := 0; attempt < 4; attempt++ {
req, err := http.NewRequestWithContext(ctx, http.MethodGet, strings.TrimRight(baseURL, "/")+metricsQueryPath, nil)
if err != nil {
return nil, "", err
}
req.Header.Set("Authorization", "Bearer "+key)
resp, err := client.Do(req)
if err != nil {
return nil, "", err
}
body, readErr := io.ReadAll(resp.Body)
resp.Body.Close()
if readErr != nil {
return nil, "", readErr
}
if resp.StatusCode == http.StatusTooManyRequests && attempt < 3 {
delay := retryDelay(resp.Header.Get("Retry-After"), attempt)
select {
case <-time.After(delay):
continue
case <-ctx.Done():
return nil, "", ctx.Err()
}
}
if resp.StatusCode < 200 || resp.StatusCode >= 300 {
return nil, "", fmt.Errorf("metrics query returned status %d: %s", resp.StatusCode, strings.TrimSpace(string(body)))
}
return body, resp.Header.Get("Content-Type"), nil
}
return nil, "", fmt.Errorf("metrics query exhausted retries after rate limiting")
}
func main() {
key := os.Getenv("INFRAI_API_KEY")
if key == "" {
log.Fatal("INFRAI_API_KEY is required")
}
baseURL := os.Getenv("INFRAI_BASE_URL")
if baseURL == "" {
log.Fatal("INFRAI_BASE_URL is required")
}
client := &http.Client{Timeout: 10 * time.Second}
http.HandleFunc("/admin/pipeline-metrics", func(w http.ResponseWriter, r *http.Request) {
if r.Method != http.MethodGet {
http.Error(w, "method not allowed", http.StatusMethodNotAllowed)
return
}
body, contentType, err := queryMetrics(r.Context(), client, key, baseURL)
if err != nil {
http.Error(w, err.Error(), http.StatusBadGateway)
return
}
if contentType == "" {
contentType = "application/json"
}
w.Header().Set("Content-Type", contentType)
w.Write(body)
})
log.Fatal(http.ListenAndServe(":8080", nil))
}
Run it with the key in the environment:
INFRAI_API_KEY="ifr_replace_me" INFRAI_BASE_URL="your API base URL" go run main.go
This adapter is intentionally boring. Before exposing it to production traffic, align a cache with the dashboard freshness SLO and coalesce concurrent refreshes in the Node.js layer; both controls reduce duplicate reads without changing the telemetry contract. Preserve upstream error detail only in restricted service logs and return a sanitized application error to the browser. HTTP 429 is a capacity signal: honor Retry-After, back off when it is absent, and never tight-loop.
How should a shadow test compare rollout options?
Release the dashboard to internal users behind a flag and exercise one known nightly import. The acceptance record should show that the application reported the intended metric, the chart reflected it within the chosen freshness objective, and an operator could move from an anomalous time bucket to the existing log investigation workflow. Because query filters are undeclared, a one-click filtered drill-down is not a promise until current discovery proves the necessary request shape.
Use three gates. Freshness: compare pipeline completion with the dashboard update. Attribution: reconcile a small set of known account, job, and day combinations against the pipeline's system of record rather than inferring ownership from log text. Query budget: count reads by panel and refresh cycle, then forecast peak concurrency with retries included. These are acceptance criteria, not claims about measured latency, uptime, or savings.
Run a negative test as well: deliberately withhold a scheduled execution in a test environment and confirm that the separate heartbeat monitor detects the missing run. Then disable the dashboard flag and verify that operators retain the old aggregate view and the existing log workflow. Rollback should be a routing change, not a telemetry rewrite; application-owned metric names and attribution dimensions should survive a backend change.
Don't delete trial data until governance owners approve its lifecycle.
What data governance protects privacy and retention?
The final decision is wider than metrics versus logs. Logs have no per-user deletion API and no bulk export or subscription API, while retention and cold-storage controls have no exposed configuration entry. That makes this log path unsuitable as the primary record for a regulated SaaS that must erase data by user. Source-map decoding, crash symbolication, and session replay are also outside the capability boundary. A compliant incumbent should remain the source of record when those controls are mandatory.
| Option | Put it on the shortlist when | Prefer another path when |
|---|---|---|
| Existing Postgres read model | Admin analytics already has governed business aggregates and the team can own schema and capacity | Telemetry operations would leak into the transactional workload or create a second fragile reporting system |
| Datadog | The organization already operates its dashboards and changing tools would duplicate training and governance | The narrow admin backend would add a second integration without retiring existing work |
| Grafana Cloud | Current dashboards and operating practice make continuity more valuable than a new contract | The team cannot justify another query, access, and dashboard workflow |
| Elastic | Structured-log investigation is the dominant need and the organization already runs the stack | The goal is primarily a few repeatedly read counters and search would add an unfamiliar on-call surface |
| Unified REST platform | A small team values metrics alongside other backend modules behind one consistent HTTP contract | Native alert delivery, distributed trace trees, synthetic monitoring, session replay, or per-user log deletion is required |
OpenTelemetry remains relevant to instrumentation and sampling decisions, but an instrumentation standard does not make the backend choice for you. Datadog, Grafana Cloud, and Elastic deserve evaluation against the team's existing estate; the table is a screening rule, not a claim that one product wins every workload.
Infrai puts one key and one bill across 295 routes in 20 modules behind one REST API, so the Go service can use plain HTTP without installing another vendor SDK, and the platform team gets a single place to attribute this workflow alongside other backend capabilities. Its public discovery surface requires no key and supplies request schemas plus runnable examples in ten languages. The catch is the capability boundary above, especially the absent alert delivery, heartbeat monitoring, trace-tree query, and per-user log deletion.
Write the decision record in SLO terms: freshness target, allowed dashboard query load, compliance controls, weekly on-call ownership, migration effort, and exit cost. “Build” might mean keeping the log platform and adding a small Postgres metrics read model; “buy” might mean staying with an incumbent whose governance is already paid for. Choose the metrics API when its simple read path and broader contract reduce integration ownership without violating those gates. Stick with the incumbent, or choose a fuller observability product, when the missing operational controls would merely move work onto the platform team.
That's the decision. The chart is the easy part.
References
- OpenTelemetry sampling concepts: https://opentelemetry.io/docs/concepts/sampling/
- Datadog documentation: https://docs.datadoghq.com/
- Grafana Cloud documentation: https://grafana.com/docs/grafana-cloud/
- Elastic Observability documentation: https://www.elastic.co/guide/en/observability/current/index.html
- Healthchecks documentation: https://healthchecks.io/docs/
Top comments (0)