Observability

If you run a trading system that cares about microseconds, you cannot afford the overhead of traditional observability. Sidecars consume CPU. Log shippers add latency. Metrics exporters create failure dependencies. And yet you still need to know when your exchange connections are dropping packets, when a syscall is running long, and when your TCP handshake to the venue is stalling. eBPF — extended Berkeley Packet Filter — solves this. It runs sandboxed programs inside the Linux kernel without modifying kernel source, loading modules, or touching application code. The kernel verifier rejects unsafe programs at load time. Goldman Sachs requires eBPF experience for production engineering roles. Their low-level systems engineering listing specifically asks for “experience with eBPF and tracing for observability in production” and “knowledge of RDMA or kernel networking internals beyond the socket API.” This is not a conference talk about future potential. It is a job requirement at one of the world’s largest financial institutions. ...

Observability is not optional in financial services. Regulators require audit trails. Operations teams need to diagnose production issues. Risk teams need to monitor transaction volumes and error rates in real time. A monitoring system that tells you “something is wrong” without telling you what, why, or when is worse than useless — it creates a false sense of security. We have built observability platforms for banks and fintechs that satisfy regulatory requirements while providing engineering teams with the diagnostic capability they need. The architecture is not about choosing between Datadog, Splunk, or Grafana. It is about designing the data model that makes your observability data useful for both compliance and operations. ...