Spider Analyzer

Common questions

Does Spider Analyzer require changes to my application code?

No. Spider captures the packets in the kernel with AF_PACKET, the same interface tcpdump uses, and reads TLS session keys with eBPF probes attached from outside the process. There is no SDK to import, no library to link, and no language-specific instrumentation. You deploy the agents from the UI and traffic starts appearing.

How does Spider decrypt TLS traffic without my private keys?

eBPF uprobes hook OpenSSL and Go binaries and read session keys out of process memory as each connection is established. Spider decrypts using the session key, so it never needs your server's private key, and it works with forward-secret cipher suites that make passive decryption impossible. The key is applied to the packets Spider already captured, which is what keeps the transport in the record alongside the plaintext.

Other eBPF tools decrypt TLS too. What is different about the way Spider does it?

The mechanism, and what it leaves behind. Kubeshark, Pixie and DeepFlow attach eBPF probes to the TLS library and copy the plaintext as the application reads or writes it, which is enough to read the request but leaves nothing of the connection underneath. Spider captures the packets and applies the session key to them, so the handshake, the certificate, a TLS alert and a connection that failed before any application data moved are all still there. Keyless TLS decryption is no longer rare in this category. Capturing the packets and then decrypting them is what makes those things recoverable.

Which protocols does Spider Analyzer decode?

HTTP, gRPC, Redis, PostgreSQL and Kafka are reconstructed request by request and correlated into a single timeline, on top of raw TCP session rebuild. Every protocol is decoded on the free BASIC tier, decrypted, transcoded and correlated into one timeline. BASIC is bounded by captured volume rather than by features: 1 TB per calendar month, after which capture pauses until the month resets and everything already captured stays fully searchable.

Does my traffic leave my cluster?

Not when you self-host, which every tier supports. Spider deploys into your own infrastructure via Helm and writes captured traffic to an Elasticsearch instance running there too, installed by the same chart. Floocus also runs a synthetic demo and a hosted sandbox for evaluation, both explicitly non-production.

Does Spider Analyzer only work with Kubernetes?

No. The capture agents ship as binaries or Docker images and run on any host with a Linux kernel, whether that is a Kubernetes pod, a virtual machine or a physical server. Kubernetes is where the Spider backend is deployed, not a limit on where Spider can see.

What infrastructure does Spider Analyzer need?

A Kubernetes cluster, and nothing else to prepare. One Helm install brings up the backend and its Elasticsearch together, and drives upgrades the same way, so there is no separate datastore to provision first. It needs neither a large infrastructure footprint nor deep Kubernetes expertise to run. The agents themselves need only a Linux kernel on the hosts you want to observe.

What is eBPF doing here, if the packets come from AF_PACKET?

Two jobs, neither of which is taking the packets. Uprobes read TLS and goTLS session keys out of process memory so the captured packets can be decrypted, and a second set of probes measures network usage across the whole cluster, which is what draws the service map with no configuration. The packets themselves are captured with AF_PACKET. Keeping those two apart matters: tools that capture with eBPF are reading buffers inside the application, which is a different thing from having the traffic.