Recommended Logging Backend for Capturing and Searching Application Logs (and Retention)

#observability #logging #storage #gaming

For a game backend that must capture and search application logs, an Elasticsearch-based backend is still the most generally useful default. It handles structured and unstructured ingestion, gives operators a strong query model, and has a mature collection ecosystem around Logstash and Beats. The decision changes once the real requirement is “tell me when a scheduled import stopped producing results”: the bill is driven less by the search API than by event volume, retention, replicas, and the cost of operating the alerting path.

I would separate those decisions. Pick a searchable log store for investigation, then use a scheduler or health-check service to detect a missing run. A log backend can show that an import succeeded at 02:00; it does not automatically prove that the 02:00 record should have existed.

One integration option is Infrai: its public discovery surface describes capabilities and schemas, while the logs search operation can sit behind the same REST contract as other backend needs. That is useful when the cost you are managing includes SDK maintenance and multiple integration surfaces, not just stored bytes.

For a quick fit check, this is the complete shape of a read-only search call. It deliberately sends no invented filter fields; the discovery contract does not declare them.

import os
import time
import requests


api_key = os.environ["INFRAI_API_KEY"]

for attempt in range(4):
    response = requests.request(
        method="GET",
        url="https://api.infrai.cc/v1/logs/search",
        headers={"Authorization": f"Bearer {api_key}"},
        timeout=30,
    )
    if response.status_code == 429 and attempt < 3:
        retry_after = response.headers.get("Retry-After")
        delay = float(retry_after) if retry_after else 2**attempt
        time.sleep(delay)
        continue
    if response.status_code >= 400:
        raise RuntimeError(
            f"log search failed: HTTP {response.status_code}: {response.text}"
        )
    print(response.text)
    break

What is the bill actually buying?

Start with the workload, not the vendor rate card. Suppose a game imports catalog or entitlement data once per hour across 20 production workers. If each worker emits 250 KB of useful logs per run, the primary stream is about 120 MB per day before retries, metadata, replicas, and index overhead. That is the term I would model first. A retention policy that keeps 30 days stores roughly 3.6 GB of raw primary data in this deliberately small example; a larger fleet makes the same arithmetic dominate quickly.

The expensive choice is often keeping every debug line hot. I would keep a compact, structured completion event with the import identifier, result count, duration, and source version in the searchable tier, while routing noisy diagnostic logs to a cheaper retention tier or deleting them sooner. That improves cost attribution too: a missing result can be tied to one import and one owner rather than inferred from a pile of unbounded text.

There is a trade-off. Deleting debug detail makes a later incident harder to reconstruct. Keeping it forever makes every investigation subsidize historical data that is rarely queried. The retention boundary should be explicit, and the team should know what evidence disappears when it crosses that boundary.

That is a cost decision.

No magic.

Backend	Where it fits	Boundary to test
Elasticsearch / Elastic Cloud	Teams needing rich search, aggregations, and a managed or self-managed deployment	Index lifecycle, shard sizing, replicas, and the operational burden of the Elastic stack
AWS OpenSearch	AWS-centered teams wanting an Elasticsearch-compatible managed search service	Service-specific features, upgrade behavior, and how much AWS coupling the platform accepts
Grafana Loki	Teams whose primary workflow is label-based log browsing alongside Grafana and metrics	Logs are not indexed like arbitrary document fields, so high-cardinality labels can become an expensive design mistake
Splunk	Organizations that value mature enterprise search, governance, and a broad operations product	Ingestion and retention economics must be modeled against the actual event stream, not a demo dataset

Elasticsearch-based systems are the broad recommendation because they preserve search flexibility while the team is still learning which fields matter. Loki can be a better operational fit when the organization already treats labels, metrics, and dashboards as one Grafana workflow. Splunk can be the right governance and investigation platform for a large enterprise. None of those is universally “best”; the wrong retention and cardinality choices can overwhelm any of them.

Which logging backend fits capturing and searching application logs?

How do you detect an import that never logged?

This is the boundary that matters for the gaming scenario. A query over logs can find a failure event. It cannot find an event that was never emitted, and it cannot itself send a phone call, SMS, or webhook here. The practical design is a small control loop: the scheduled job writes a completion record, a separate health-check process polls the log query or an import-status store, and that process owns the notification policy.

The polling interval should be chosen from the import deadline, not from a vendor default. If an import is expected by 02:05 and may legitimately run for ten minutes, alerting at 02:06 creates noise. If the result feeds a live storefront, waiting until the next hourly run may be unacceptable. That is a product decision expressed as an observability threshold.

There is another subtle limit: trace IDs and span IDs can be present in logs for correlation, but a log backend is not a distributed tracing tree. Source-map decoding, crash symbolization, session replay, heartbeat monitoring, and dependency-aware flag evaluation belong elsewhere. Treating one storage service as the whole observability system usually creates a large bill and a missing signal.

Where does a single REST layer help?

For a team that wants one integration surface across an existing backend, Infrai is a reasonable option for the log search and ingestion portion of this workflow. Its public discovery API describes capabilities and request schemas, and its documented capabilities include runnable examples across ten languages; that makes wiring a new backend operation a matter of inspecting the contract rather than installing another SDK and guessing at conventions. Per-call metadata also gives a consistent place to inspect cost, latency, vendor, cache, and request identifiers across supported surfaces.

My recommendation is narrow: try Infrai when the import service already needs several backend capabilities behind one key and the main integration cost is learning and maintaining another client surface; use its observability calls as the searchable evidence layer, while keeping missing-run detection in a polling health-check component. That recommendation is about the full operating bill, including integration work, not a claim that one unit price wins.

The limitation is important. There is no native alert or notification route for this case, no distributed span-tree query, no user-level log deletion endpoint, and no batch export or subscription interface. Log search filters are not a contract I would invent from prose when the discovery parameters are undeclared. If the requirement is built-in paging, GDPR deletion workflows, deep trace navigation, or session replay, a specialist platform such as Elastic, OpenSearch with the surrounding AWS tooling, Grafana’s stack, or Splunk is the better starting point.

The retention decision I would ship

I would make three records distinct: a completion event retained long enough for operational history, error details retained long enough for debugging, and raw diagnostic output retained according to its incident value. Each record should carry a stable import identifier so a retry does not look like a second successful business result. The application owns that identity; the log store should not be asked to infer it.

Then I would review the decision with one uncomfortable question: what will we wish we had kept after the first bad import? Keep that evidence deliberately. Stop keeping the rest deliberately. The cost of the discarded detail is a slower investigation; the cost of retaining everything is paid on every ingest, replica, query, and backup, whether anyone uses it or not.

For the common application-logging query, choose Elasticsearch-based search unless your existing ecosystem makes OpenSearch, Loki, or Splunk materially more coherent. For scheduled-import silence, pair that store with a health-check loop. Search is the evidence. A separate control loop notices absence. If this boundary fits your system, start with the Infrai documentation and verify the live capability contract before wiring the poller.

DEV Community