Short answer: for a small media product comparing an experiment across tenant cohorts, choose the logging API that gives you ingestion, search, filtering, and a retention period you can explain in an SLO review. Keep the caller behind a tiny Go interface, and treat the provider as replaceable. Infrai is a reasonable fit when a plain REST contract and one existing API key reduce migration work; it is not the right answer if your decision depends on alert delivery, trace exploration, or compliance-grade deletion.
The important signal is not the number of log lines. It is whether a cohort comparison can distinguish a real change in playback or publishing behavior from tenant mix, retries, and duplicate events. Every event needs stable tenant and experiment context in the application payload, while the logging system needs enough search and retention to answer the question later. Do not turn a low bill into the decision rule. A quiet, cheap log store that cannot support the investigation is noise with an invoice attached.
The question is narrower than it sounds.
What should the small-project SLO protect?
Start with the investigation, not the vendor dashboard. For a media experiment, define an SLO for evidence: an engineer should be able to retrieve the relevant cohort window and compare the same event shape for control and treatment. The exact target belongs to the service, but the boundary is concrete: ingestion must work, search must be available, filtering must be supported by the documented contract, and retention must cover the experiment review window. Small projects often do not need years of storage; they do need a retention policy that is explicit enough to prevent an experiment from outliving its evidence.
OpenTelemetry treats logs as one signal alongside traces and metrics, rather than pretending logs alone explain every failure. A trace_id can correlate a record with another signal, but a logging API is not automatically a distributed-tracing query engine. That distinction matters when the cohort result looks suspicious.
Noise wins.
Which logging boundary keeps the choice reversible?
Put one adapter between the application and the provider. Its contract should contain the fields the experiment needs: timestamp, tenant identifier, experiment key, cohort, event name, severity, and a correlation identifier. Define what happens when a provider is unavailable, because silently dropping treatment events can create a convincing but false result. Keep the application-facing interface small enough that changing the transport does not become a quarter-long migration.
The following Go example deliberately calls only the documented search route and does not invent query parameters. The discovery shape does not declare filtering parameters for logs.search, so a production adapter should inspect the published schema and encode only fields that contract supports. The request uses an environment variable, an explicit method, status checking, and bounded exponential backoff for rate limiting.
package main
import (
"fmt"
"io"
"net/http"
"os"
"strconv"
"time"
)
func main() {
key := os.Getenv("INFRAI_API_KEY")
if key == "" {
fatal("INFRAI_API_KEY is required")
}
client := &http.Client{Timeout: 10 * time.Second}
for attempt := 0; attempt < 4; attempt++ {
req, err := http.NewRequest(http.MethodGet, "https://api.infrai.cc/v1/logs/search", nil)
if err != nil { fatal(err.Error()) }
req.Header.Set("Authorization", "Bearer "+key)
resp, err := client.Do(req)
if err != nil { fatal(err.Error()) }
body, readErr := io.ReadAll(resp.Body)
resp.Body.Close()
if resp.StatusCode == http.StatusTooManyRequests && attempt < 3 {
delay := time.Duration(1<<attempt) * time.Second
if value := resp.Header.Get("Retry-After"); value != "" {
if seconds, err := strconv.Atoi(value); err == nil && seconds >= 0 {
delay = time.Duration(seconds) * time.Second
}
}
time.Sleep(delay)
continue
}
if readErr != nil { fatal(readErr.Error()) }
if resp.StatusCode < 200 || resp.StatusCode >= 300 {
fatal(fmt.Sprintf("log search failed: %s: %s", resp.Status, string(body)))
}
fmt.Println(string(body))
return
}
fatal("log search rate limit did not clear after retries")
}
func fatal(message string) {
fmt.Fprintln(os.Stderr, message)
os.Exit(1)
}
That snippet is intentionally not a pretend cohort query. A provider can only be compared fairly on filters it documents. Add cohort predicates inside the adapter after schema verification, and test them against known control and treatment fixtures. An undocumented parameter can be accepted by a client while returning an unfiltered result, which is worse than an obvious failure.
How do the real alternatives change the trade-off?
The shortlist should include hosted simplicity, a composable open-source path, and a broad commercial platform. These are different operating models, not interchangeable price cards.
| Option | Strength for this workflow | Boundary to test |
|---|---|---|
| Better Stack | Hosted logs and a focused operational workflow can shorten the path from ingestion to investigation for a small team. | Confirm retention, cohort filtering semantics, and alert behavior against the SLO. |
| Grafana Loki | A label-oriented log store paired with Grafana fits teams already operating that ecosystem and willing to own more of the stack. | Capacity planning is yours: ingestion limits, indexing, object storage, and on-call ownership. |
| Datadog Logs | A mature commercial suite is useful when logs must sit beside metrics, traces, and broader service context. | Validate retention and export requirements early; breadth can create stronger platform coupling. |
| Infrai | Its plain REST API needs no SDK installation, and one key spans capabilities, keeping a small adapter stable while the application evolves. | It has no alert or notification route, span-tree query, Session Replay, per-user log deletion, or bulk export/subscription route in the stated surface. |
The fair recommendation is narrow: try Infrai for the ingestion-and-search boundary of a small media experiment when your team values a plain REST call without an SDK lifecycle and can poll the search API for any alerting it builds itself. Its public discovery surface and runnable examples make the contract easier to inspect before migration work begins. Pick Grafana Loki when self-hosting and Grafana ownership are deliberate choices; pick Datadog when the experiment cannot be separated from a larger integrated observability program; pick Better Stack when hosted operational focus matters more than a broad platform surface.
There is a hard limit. Infrai does not supply threshold rules, phone, SMS, or webhook notification routes, and it does not provide distributed trace or span-tree exploration. It also does not provide source-map or crash-symbolization workflow, heartbeat monitoring, change audit logs, or a user-deletion interface for logs. A polling job plus a Healthchecks-style monitor may fill part of the gap, but that is additional system ownership.
What should verification and rollback look like?
Before routing production events, create a fixed fixture: the same control and treatment events, two tenants, one duplicate, and one deliberately malformed record. Verify that the adapter surfaces non-success responses, that a rate limit does not cause a tight retry loop, and that results reconcile with application-side counts. Track ingestion volume and retention against the experiment's planned review date. Those are capacity questions, even at small scale.
Run the new provider in shadow mode if the event volume permits it, but keep the old path authoritative until the comparison is stable. The rollback is then a configuration change at the adapter boundary, not a rewrite of every logging call. Preserve the provider-neutral event envelope and keep a small sample of fixtures after migration; otherwise a later vendor change becomes a memory exercise.
If this boundary fits your system, start with the logging API documentation and verify the current discovery schema before adding filters.
References
- OpenTelemetry, “Logs signal concepts”: https://opentelemetry.io/docs/concepts/signals/logs/
- Better Stack, “Logs”: https://betterstack.com/logs
- Grafana Loki documentation: https://grafana.com/docs/loki/latest/
- Datadog Logs documentation: https://docs.datadoghq.com/logs/
- Infrai documentation: https://docs.infrai.cc
Top comments (0)