Stephane PAPAIX

Here is a how-to blog on using the Argo CD Agent 0.4.1 with the OpenShift GitOps 1.18 operator for OpenShift users that want to try it out. As a reminder the Argo CD Agent is Technical Preview and not intended for Production workloads. However for customers interested in using it in the future it is well worth checking out now in a lab environment and providing feedback. I'm really excited about this technology, the OpenShift GitOps Engineering team along with the broader Argo CD community have done a really great job with the underlying architecture. https://lnkd.in/gYw_jyic

52

🔥 Announcing Microsoft Sentinel Model Context Protocol (#MCP) server 👉 A fully managed cloud service built on an open standard that lets AI agents seamlessly access the rich security context in your Sentinel data lake. 💡 Blog: https://lnkd.in/dMsND_6b

185

5 commentaires

End-to-End Observability with OpenTelemetry in OpenShift In today’s cloud-native world, observability is not optional—it’s the backbone of resilience, performance, and trust in digital platforms. For organizations running workloads on Red Hat OpenShift, achieving true end-to-end observability goes beyond traditional monitoring. We need a unified approach that connects metrics, logs, and traces across applications, containers, service mesh, and platform infrastructure. This is where OpenTelemetry (OTel) becomes the game-changer. As a CNCF project and the emerging industry standard for telemetry, OpenTelemetry offers a vendor-neutral way to collect and correlate observability data. Instead of stitching together siloed tools, we can build a single telemetry pipeline that feeds into multiple backends like Prometheus, Grafana, Jaeger, Tempo, Loki, or commercial APM solutions. So how do we bring this to life in OpenShift? 1️⃣ Application Instrumentation Developers can use OTel SDKs or auto-instrumentation agents (Java, Python, Go, .NET) to capture spans, metrics, and logs directly from code. Context propagation ensures that requests flowing through microservices carry trace identifiers for full request visibility. 2️⃣ OpenTelemetry Collector At the heart of the architecture lies the OTel Collector, deployed natively in OpenShift via the OpenTelemetry Operator. It acts as the universal ingestion layer—receiving data via OTLP, enriching it with attributes (e.g., Kubernetes namespace, pod labels), applying sampling or filtering, and exporting to the chosen backends. Depending on scale, it can run as a sidecar, DaemonSet, or centralized deployment. 3️⃣ Service Mesh Integration For teams leveraging OpenShift Service Mesh (Istio), the Envoy sidecars automatically emit metrics and traces to the OTel Collector. This gives platform teams out-of-the-box visibility into service-to-service communication, latency, and error rates. 4️⃣ Visualization & Alerting Finally, the data flows into backends: Metrics → Prometheus + Grafana for golden signals (latency, errors, saturation, traffic). Traces → Jaeger or Tempo for distributed transaction analysis. Logs → Loki or Elastic for contextual debugging. Alerts → Alertmanager to proactively notify on anomalies. The result? A single pane of glass where developers, SREs, and business stakeholders can align on application health, performance bottlenecks, and user experience. Best practices: Start with high sampling in dev, optimize in prod. Use labels/namespace isolation for multi-tenancy. Secure telemetry pipelines with mTLS. Integrate into CI/CD pipelines for consistent instrumentation. Scale collectors with OpenShift HPA for resilience. As enterprises accelerate into AI-driven digital ecosystems, observability becomes the nervous system. By adopting OpenTelemetry within OpenShift, organizations gain end-to-end insights across apps, services, and infrastructure—without being locked to any single vendor.

23