OLAP

Carry telemetry from production to investigation

The platform runs OpenTelemetry Collector and the OpenObserve storage and query platform on one Linux host in a trusted private network. Collector receives application signals and samples host resources. OpenObserve stores and queries records and supplies built-in Trace search, details and timeline.

Applications send logs, metrics and traces to Collector; host resource readings share the metrics channel. Collector exports within finite queue, concurrency and retry budgets, and users query retained records in OpenObserve. Business projects define request classifications, investigation criteria and analysis panels; the platform supplies consistent intake and querying.

Preserve identity along standard protocols

Applications use the standard telemetry protocol OTLP over gRPC, with optional binary OTLP/HTTP when configured. Logs, metrics and traces pass through bounded processing before their separate backend routes. Resource and instrumentation Scope remain attached; the platform does not rewrite those source identities for applications.

Ingress belongs on an authorized private network whose route is established by the deployment owner. Any external HTTPS entry is separately operated. One maintained backend account declaration supplies the exporter’s derived connection material, avoiding independently maintained copies of the same destination and credential.

Establish an observable signal path for each application

An application uses the OTLP listener and protocol actually declared for the service, with an explicit service identity and instrumentation scope. gRPC and optional binary HTTP have their own addresses and paths. A running Collector does not imply that another port is also available.

An integration check can use one known non-sensitive log, a distinguishable metric value and an identifiable trace. Record the expected source and time window first, then query those records in the backend. This can reveal a wrong destination, unit conversion or missing source identity without using real user content as test material.

1. Select the actual receiver

   Check the protocol, listener and authorized network path. Derive backend connection material from its single authoritative configuration.

2. Send distinguishable records

   Preserve Resource and Scope, using independently expected content and units to distinguish logs, metrics and traces.

3. Read from the storage backend

   Query the known source and observation window and compare actual records, rather than relying only on a sender’s success indication.

Make operating budgets explicit

Each signal uses a bounded in-memory queue, fixed exporter concurrency and a finite retry horizon. Full queues do not wait for unlimited storage, and host metrics share the metrics exporter. Processing budgets, batch size and process limits constrain resource use; receiver failure and process restart can still leave gaps.

OpenObserve separately bounds ingestion buffers, query execution memory and individual in-memory data files, using visibility of its actual service memory ceiling. Raising the process limit alone does not replace those budgets. Retention, query range and timeout are explicit, while existing stream-specific overrides remain native backend state.

Plot resource values with a clear interpretation

Host collection selects CPU idle ratio, available and total memory, and filesystem used, free and reserved space. Instantaneous capacities retain Gauge semantics before backend ingestion, avoiding their interpretation as cumulative counters. Application metrics are unchanged by this host-only adaptation.

The overview uses three vertically stacked full-width panels. CPU shows non-idle utilization; memory presents available and total GiB; filesystem series retain device, mountpoint and space state. Capacities from unrelated devices are not added together. Filesystems omitted by native collection remain unavailable, and the query user selects relevant mounts.

Investigate missing records at four separate points

First establish whether the producer generated the signal. Then inspect export and bounded Collector processing, check the stored backend stream, and finally verify the query’s source, units and time window. This sequence preserves what each observation establishes instead of attributing one empty screen to the whole system.

A failed query remains unavailable. A successful query without matching records remains empty. Only an observed zero is shown as zero. Old samples can support historical analysis, but a newly completed query does not make them fresh. Gaps in coverage remain gaps rather than being filled into an apparently continuous curve.

• Supported conclusion: independently expected records are queryable

  Finding the records establishes visibility for the selected source and time window and supports checking their units and labels.

• Unsupported conclusion: export acknowledgement means complete visibility

  Producer or receiver acknowledgement does not establish that every record is stored, loss-free or continuously fresh.

• Check next: service memory budgets

  Observe the memory limit actually granted to the service and check queues, ingestion buffers and query budgets separately. Host RAM is not a substitute for those limits.

Distinguish a successful query from sufficient evidence

An empty successful result, a missing stream and a failed query mean different things. Native lookback can select an older value without establishing a new sample. The host trends alone do not establish freshness, current health or loss accounting; those conclusions need their corresponding evidence.

The design calls for starting both native programs from their generated service material, checking effective memory ceilings, then sending known non-sensitive records through all three signal paths and reading them back. Overview verification executes the maintained native expressions and compares CPU conversion, memory units and filesystem labels against independent expectations.