Earticle

Modern cloud applications often operate as unmodified third-party services or legacy code, where direct instrumentation for observability is infeasible. This paper investigates whether a minimal black-box observability pipeline can still provide actionable insights in such contexts. We compose a standard stack—Envoy proxy, OpenTelemetry Collector, Prometheus, Jaeger, and Grafana—to collect metrics and traces without modifying application code, and we apply it to two representative workloads: a lightweight demo service and the OWASP Juice Shop. Our evaluation shows that proxy-only instrumentation captures meaningful demand and latency signals, that exported spans faithfully reflect traffic bursts visible in proxy metrics, and that distributed traces reveal endto- end error paths (e.g., 404 failures). These findings indicate that a carefully orchestrated open-source stack can approximate the diagnostic value of white-box instrumentation. The contributions of this work are a reproducible pipeline design and an empirical assessment demonstrating how such a configuration can reduce mean-time-to-detect (MTTD) failures and support service-level objective monitoring under synthetic load scenarios.

In this study we evaluate a production-style OpenTelemetry (OTel) pipeline on Google Kubernetes Engine (GKE) Autopilot under a sustained trace workload, instrumenting end-to-end ingestion→processing→export and scraping Collector self-telemetry and spanmetrics with Prometheus over a 30-minute run. The Collector averaged 573 spans/s accepted and 561 spans/s exported, yielding 97.84% within-window export efficiency and peaking near 924 spans/s. A brief saturation interval (150 s) produced a queue peak of 6.38, short drops (peak 3.49 spans/s, ~358 total), and p95 inflation to 116 ms; median latency remained low (p50 ≈ 12.9 ms) and recovered after pressure subsided. Resource footprint was modest (≈0.36 CPU cores, 0.21 GiB memory, sub-Mbps network), indicating headroom. We document integration pitfalls (OTLP endpoint/protocol) and show that queue growth and exporter errors anticipate p95 tails. The study contributes reproducible methodology, quantitative evidence of cloud-scale OTel scalability, and operator guidance for capacity planning and alert design.

The rise of cloud-native infrastructures has accelerated the adoption of OpenTelemetry as the leading standard for monitoring system performance. OpenTelemetry's well-established utility in software observability gives way to significant limitations when applied to hardware and real-time systems. This paper explores the challenges of integrating OpenTelemetry with hybrid cloudhardware environments, drawing on real-world use cases such as the Israel-Lebanon smart device sabotage. By highlighting performance deficiencies, protocol incompatibilities, and security vulnerabilities, we illustrate how OpenTelemetry's design shortcomings diminish its utility in hardware-intensive applications. We offer recommendations for improving device compatibility and mitigating cybersecurity threats. The document seeks to provide an exhaustive analysis and a strategy for enhancing telemetry in hybrid settings.