Every message of every WebSocket conversation, in both directions - decompressed, decoded, named, tagged and searchable, with nothing to instrument and no line of application code to change.

Four days ago Spider learned to split a Server-Sent Events stream into one communication per event. WebSocket is the other half of that story, and the harder one. It is done. 💪

Until this week, telling us something was wrong meant writing an email. Which meant describing the screen you were on, the version you were running, which agent you had selected and what you had clicked just before it went wrong. Nobody does that. So the mail arrives as "the waterfall looks odd" and we burn two round trips working out where you were standing.

Network-View now has a Send feedback button in the bottom-left rail, above Help. It opens a panel, you write a sentence, you press send. What we receive already carries the version, the screen, the selection and your last twenty actions.

Every event on every stream, captured, timed, named, tagged and searchable - without instrumentation, without proxies, without touching a line of application code.

After HTTP/1.x, PostgreSQL, Redis, gRPC, Kafka and HTTP/2, I'm happy to announce the next thing Spider Analyzer decodes natively: Server-Sent Events.

This one is not a new protocol so much as a new shape. SSE is ordinary HTTP - one GET, one 200, one Content-Type: text/event-stream - and then the response never ends. That shape is exactly what a request/response analyzer is worst at, and it is why, until now, one of the most interesting parts of a modern application was also the least visible part. 💪

Spider has always shown you traffic as IP addresses and resolved hostnames. On a stable topology that's fine. On Kubernetes it's a lie by omission: a deployment with twenty replicas is twenty addresses, a pod restart is a "new machine", and a service's ClusterIP tells you nothing about who is behind it. You end up merge-replicas-ing your way to an approximation of what Kubernetes already knows exactly.

As of this release, every captured TCP session, packet and communication - HTTP, PostgreSQL, Redis, gRPC, Kafka - carries the real Kubernetes workload of both endpoints: namespace, kind, name, the node it ran on. Not a guess from a hostname pattern. The object Kubernetes itself would name.

Spider captures everything on the wire. Until now, none of it left the instance except as search results a human pulled through the UI.
As of this release, a team can turn its own traffic into metrics and push them to whatever OTLP/HTTP collector it already runs - the Prometheus and Grafana you have, not a new dashboard to learn.

Deep, protocol-level visibility into your HTTP/2 traffic - every stream, every body, every header - without instrumentation, without proxies, without touching a line of application code.

After HTTP/1.x, PostgreSQL, Redis, gRPC and Kafka, I'm happy to announce the next protocol natively decoded by Spider Analyzer: HTTP/2.

This one is different from the others. HTTP/2 does not get its own menu entry, its own index or its own feature flag - it lands directly in the HTTP view, next to your HTTP/1.x traffic, with the same fields, the same templates, the same tags and the same transcoding. Because as far as your application is concerned, it is HTTP. Only the wire changed. 💪

This version introduces:

• Redis, gRPC and Apache Kafka live parsing, each behind its own feature flip,
• TLS key capture from Go's crypto/tls, and standard pcapng key-logs that decrypt in Wireshark,
• automatic correlation across every protocol, with one click from a communication to the whole chain it belongs to,
• arm64 support on every image, Gocipher's eBPF TLS capture included,
• a licence that pauses capture when it degrades instead of revoking the product,
• and every known CVE with a published fix closed across the whole shipped set.

Spider has been able to draw a request's whole journey for a long time: pick a set of communications and you get a waterfall, a sequence diagram and a map of what talked to what, across every protocol at once.

There was a catch, and it was the first thing anyone hit. All of that needs somebody to have told Spider which field carries the identifier. On a fresh deployment, nobody had. So the most persuasive thing Spider does was the one thing it could not do cold, and the first twenty minutes of an evaluation went to writing tag rules instead of looking at traffic.

As of this release, a Whisperer created with the defaults extracts a correlation identifier from its first captured packet, and any communication carrying one is one click away from its whole chain.

Spider now runs on arm64. Every container image is a multi-arch manifest, so a helm install on a Graviton, Ampere or Apple-silicon-hosted cluster pulls arm64 images without you changing anything.

Getting there was mostly boring. Fifty-odd Go and Node services cross-compile to arm64 without incident - you add a platform to the build and move on. One component did not, and it is the one that makes Spider interesting: Gocipher, the agent that extracts TLS master secrets with eBPF.

Spider's whole pitch is unusual enough that people do not quite believe it until they see it: capture network traffic from a Kubernetes pod, decrypt the TLS, and reconstruct the conversation - without touching a line of application code. No SDK, no sidecar baked into the image, no instrumentation.

Telling someone that is one thing. Watching it happen is another. So there is now a demo where you can watch it happen yourself, live, at spider-analyzer.io/demo.