Zero-Code Instrumentation of an Envoy TCP Proxy Using eBPF(sergiocipriano.com)
46 pointsby sergiocipriano7 hours ago4 comments
  • otterley6 hours ago
    Could you not have gotten all this information by changing the Envoy log format to add the required fields? In your blog post, you show the default log format, and suggest that there was no way whatsoever to get this data from the logs. But according to the documentation, Envoy has rich support for many additional fields including detailed latency statistics.

    I wonder if you added complexity to the architecture when a simple log format change would have sufficed.

    • sergiocipriano6 hours ago
      To my knowledge, Envoy does not provide this type of information for TCP proxying. I wanted request/response latency, but the available metrics are limited to connection-level information
      • otterley6 hours ago
        Why aren’t you using HTTP proxying if the underlying protocol is HTTP?

        TCP proxying, in my experience, is typically only used for routing TLS or other non-HTTP TCP requests. In the former case, the proxy should not be able to observe the requests and responses.

        • sergiocipriano5 hours ago
          We currently only provide TCP load balancers, so HTTP-level proxying was not an option. Since the customer was not using TLS, this solution worked.
  • the_arun6 hours ago
    Great article! What is the name of tool used for writing the block diagram?
    • ethaligan6 hours ago
      Judging by the font embedded in the SVG file, it looks like it was created using Excalidraw. It's a great tool if you're looking for that hand-drawn aesthetic!
  • chrisweekly6 hours ago
    Great post, thanks for sharing! I appreciate all the details, including context for the problem, the complete setup, and the results. Bookmarked for future reference.
  • a0127 hours ago
    I was also on the verge of installing OBI to troubleshoot networking issue on one of our clusters. So maybe next time there’s a similar incident