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.

Can Spider Analyzer show who publishes and who subscribes on MQTT topics?

Yes. Spider decodes MQTT 3.1.1 and 5.0 over TCP, one communication per exchange: a client PUBLISH with its PUBACK or its PUBREC, PUBREL and PUBCOMP handshake, every broker delivery to a subscriber, CONNECT, SUBSCRIBE, UNSUBSCRIBE and DISCONNECT, each carrying the client id, username and protocol version, and on MQTT 5 the user properties, response topic and correlation data. The topic map then draws which clients publish to which topic and which subscribers receive it, and flags what is wrong: a subscriber granted a lower QoS than it asked for, a failed or silent subscription, an orphan topic nobody reads, a QoS 1 or 2 publish that never got its acknowledgement, and broker errors such as rejected credentials. Payloads are decoded as JSON, protobuf, CBOR, Avro or Sparkplug B, and topic templates and tags apply as on every other protocol. MQTT over TLS on port 8883 is decrypted with the same captured TLS keys as the rest of the traffic when at least one end runs OpenSSL (Mosquitto, for instance), Node.js or Go. MQTT is included on every tier, BASIC included.

Can AI agents query Spider Analyzer?

Yes. Spider runs a remote MCP (Model Context Protocol) server at your Spider URL under /mcp, so an MCP-compatible agent such as Claude can search and aggregate the decrypted traffic, look at a single communication, list workloads and namespaces, and share a link to what it found. Agents sign in with OAuth 2.1 and see only what the signed-in user may see: the same teams, whisperers and access filters apply. It is read-only by default, payloads are opt-in and returned labelled as untrusted captured data, and tool results are size-bounded. Starting and stopping capture from an agent is a separate option that is off by default. The MCP server needs the TEAM tier or above. The spider and spider-mon CLIs and the two Claude Code plugins, which give an agent the same data model from a terminal, are available on every tier, BASIC included.

Which protocols does Spider Analyzer decode?

HTTP (1.x, 2 and 3), gRPC, Redis, PostgreSQL, MySQL and Kafka are reconstructed request by request, and WebSocket and Server-Sent Events message by message, in both directions, all correlated into a single timeline, on top of raw TCP session rebuild. DNS is decoded query by query over UDP, TCP, DNS over TLS (port 853) and DNS over QUIC (RFC 9250): one communication per query and response, kept as metadata, with unanswered queries marked No response and failed lookups carrying their DNS response code. DoT and DoQ are decrypted with the same captured TLS keys as the rest of the traffic, and DNS takes the same tag rules and templates as the other protocols. HTTP/3 is decoded from QUIC with the same captured TLS keys, including gRPC and SSE over HTTP/3, and is enabled per whisperer. MQTT 3.1.1 and 5.0 are decoded exchange by exchange, publish and acknowledgement, broker delivery to each subscriber, connect and subscribe, and a topic map shows who publishes to which topic and who receives it. HTTP traffic is also enriched for GraphQL, with operation name, type and template for queries, mutations and subscriptions over HTTP, WebSocket and SSE, and for Model Context Protocol calls, with method, tool name, session and outcome, also when answered over SSE. Only variable and argument names are recorded, never their values. 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 Spider Analyzer decode HTTP/3 and QUIC?

Yes. HTTP/3 (RFC 9114) over QUIC, with QPACK header compression, becomes the same communication record as HTTP/1.x and HTTP/2, with the same views, filters, tags, templates, stats and exports. gRPC over HTTP/3 becomes gRPC communications and Server-Sent Events over HTTP/3 become one communication per event; WebSocket over HTTP/3 is not decoded. Decryption stays passive, with no proxy, sidecar or code change: Gocipher captures the TLS 1.3 secrets from OpenSSL and Go processes, and the Gossiper reads the ClientHello random from the QUIC Initial packets so the keys can be matched to the UDP flow. It is verified with nginx on OpenSSL 3.5, curl (ngtcp2 and nghttp3 on OpenSSL 3.5) and Go quic-go; stacks that do their own TLS or link BoringSSL statically are out of reach. A QUIC connection that outlives its UDP flow, through NAT rebinding, client migration or an idle split, keeps being decoded under the same communication ids. HTTP/3 is off by default and enabled per whisperer, on UDP port 443 unless configured otherwise, and needs UDP capture on. Bodies are kept only when decrypted content saving is enabled. A connection whose handshake was not captured is skipped rather than decoded from the middle, and 0-RTT early data is not decrypted. Included on every tier, BASIC included.

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.