The alert is most likely **not** caused by application request traffic, but by the logging pipeline emitting repetitive info/warn messages at high frequency. - The dominant messages in the issue context are exporter failures from OpenTelemetry (`OTLP LOG GRPC Exporter`, `OTLP TRACE GRPC Exporter`, `OTLP METRIC GRPC Exporter`) with **"data refused due to high memory usage"** and `UNAVAILABLE` retries. - There is also a repeated `Loading incluster config...` message and `No data/binaryData field in configmap`, which usually points to a misconfigured Kubernetes integration or controller loop that keeps reprocessing the same object. - The issue title says **"Too many info logs per minute in unknown-service"**, but the telemetry strongly suggests the noisy source is an instrumentation/exporter component or integration layer, not a normal business-service code path. Recommended fix: - **Break the log loop**: add deduplication / rate limiting around the repeated info log source (`Loading incluster config...`, configmap handling, exporter retry logging). - **Stop logging expected retries as info/warn**: downgrade repetitive retry/fallback messages to `DEBUG`, or emit them once with structured counters. - **Fix the root config issue**: if this is a Kubernetes integration, ensure the configmap contains the expected `data` or `binaryData` field and the controller is reading the correct namespace/object. - **Handle OTLP backpressure explicitly**: if the exporter is being refused because of memory pressure, tune batching/queueing and reduce log volume before export, otherwise the exporter retry path can amplify the log rate. Concrete places to check: - The code path that logs `Loading incluster config...` and configmap parsing errors. - OpenTelemetry exporter settings: batch size, queue limits, retry policy, memory limiter behavior. - Any alerting rule that counts *info* logs per minute should exclude known noisy system logs or cap per-source contributions. If you want, I can also give you a narrow query to identify the exact pod/container generating the most log volume.

Unlikely.

• Being on mobile can change request patterns or session churn, but it does not explain a sudden spike in info logs per minute by itself.
• The telemetry here points to backend log spam and exporter/config retries:
  • repeated OTLP exporter failures due to high memory usage
  • repeated Loading incluster config...
  • repeated No data/binaryData field in configmap
• If mobile traffic were the cause, I’d expect more:
  • request volume spikes on mobile-specific endpoints
  • higher 4xx/5xx rates tied to user-agent/session
  • downstream latency or error bursts, not a pure info-log-rate alert

What mobile could do:

• increase traffic enough to amplify an existing noisy loop
• trigger a code path that logs per request/session
• expose a mobile-only integration issue

But the root problem is still likely:

• a logging loop
• bad configmap/incluster config handling
• exporter backpressure causing repeated retries/logs

Best next check:

• compare log volume by resource.service.name / pod
• inspect whether the noisy messages correlate with a specific mobile endpoint or only with exporter/integration logs

Use a filter that excludes the noisy system components and surfaces the likely app traces.

kind == "span"
AND resource.service.name !in ("otel-collector", "opentelemetry-collector", "kafka", "valkey-cart", "jaeger")

If you want only request traces:

kind == "request"
AND resource.service.name !in ("otel-collector", "opentelemetry-collector", "kafka", "valkey-cart", "jaeger")

If you want to exclude all infrastructure/system-ish services more aggressively, use:

kind in ("span", "request")
AND resource.service.name !in ("otel-collector", "opentelemetry-collector", "kafka", "valkey-cart", "jaeger", "ad", "email", "fraud-detection")

If by “tracers” you mean trace-producing services rather than the tracing backend, tell me which service names you want to keep and I’ll tighten the query.

You're dealing with a Samsung OS update / OTA install problem, not an app issue.

• If One UI 8.0 is already downloading or staged, the practical way to stop it is to disable automatic updates, clear the updater’s data, and if needed remove the downloaded package.
• If the update has already entered the install/pending reboot phase, there may be no safe in-place cancel; you typically have to postpone by preventing the reboot and clearing the update cache.

Try this first:

1. Turn off auto download/install
   • Settings -> Software update -> Auto download over Wi‑Fi off
   • Also disable any “Install updates automatically” setting if present
2. Disable Samsung/Carrier updater apps
   • Settings -> Apps -> Show system apps
   • Find things like:
     • Software update
     • FOTA
     • com.wssyncmldm
     • com.sec.android.soagent
     • carrier update apps
   • Force stop them
   • If allowed, Disable them
3. Clear updater storage
   • In the same app info screen:
     • Storage -> Clear cache
     • Clear data
4. Delete any downloaded update package
   • Check Internal storage/Download
   • Also look for Android/data/... or Samsung update folders if accessible
   • Remove any .zip, .bin, or downloaded_update files
5. Avoid rebooting
   • If the update is staged, rebooting may trigger install

For Termux specifically:

• If One UI 8.0 would break your workflow, the most robust option is to freeze the current firmware state:
  • disable auto update
  • keep updater services disabled
  • avoid enrolling in beta/early access
• If you still have ADB access, I can give you commands to disable the update packages cleanly.

If you want, I can give you:

• tap-by-tap Samsung steps
• ADB commands
• or a rootless Termux-only workaround to block OTA components as far as Android allows.