Sampling, ingestion, and retention control trace volume at different stages. They are related but are not interchangeable.

Sampling

Sampling decides which traces are forwarded. SDK sampling can make an early decision when a trace begins. The OpsRamp trace proxy can instead buffer spans, assemble a more complete trace, and evaluate trace-aware rules before forwarding. This enables decisions based on errors, latency, services, operations, or other fields observed anywhere in the trace.
Sampling reduces data volume before traces reach OpsRamp. Aggressive trace sampling can lower cost and noise, but it can remove the request-level span evidence needed to investigate rare problems. Metrics generated independently of the sampled trace stream, or before trace sampling is applied, can still reveal aggregate symptoms such as elevated latency, errors, or traffic changes. Metrics derived only from sampled spans represent the sampled traffic and may not capture every rare condition. Sampling rules can prioritize error and high-latency traces over routine successful traffic.

Ingestion

Ingestion occurs when OpsRamp accepts exported spans for the intended client. Configure the endpoint, protocol, credentials, and client identifier supplied for your deployment, then verify arrival using a representative request.
Client ingestion limits are usage-governance settings. OpsRamp monitors usage and sends warning or critical notifications; these limits do not block trace traffic. Use sampling to reduce forwarded trace volume.

Retention

Retention determines how long accepted spans remain available. Confirm your client’s retention period with the administrator and treat data outside that window as unavailable after expiry cleanup.
Changing retention affects the data lifecycle after ingestion. It does not recover previously sampled-out traces, and it should not be used as a substitute for a deliberate sampling strategy.