Is it possible to get a copy of our Tailscale log stream into a service like CloudWatch or Humio, for eg. internal auditing?
It seems as if https://tailscale.com/kb/1011/log-mesh-traffic hints at the possibility, but it doesn’t really point to any more details, and https://tailscale.com/kb/1014/log-api appears to serve other use cases.
This is currently available for high-volume customers. We’re working on a nice API for streaming the collected diagnostic data from your nodes into your own logging system so that everyone can have it, but it needs more refinement first so it doesn’t become a support nightmare. 
Meanwhile, on Linux machines you can capture from syslog (journald). There are no more logs than what you see there.
Ahh ok, great – that should fit well enough for us then! Since we’re mostly working through a couple of relays with subnet routing, I assume that any “interesting” access patterns from connected clients will be visible in the relay logs?
Yes, that should work fine. Let us know if you need any help interpreting the logs!
Hi folks, I was looking for this same answer in part for the same use case as @JohanW and searching led me here.
I understand that logging network traffic is a non-trivial task and I bet that’s especially difficult when talking about subnet traffic passing through. That said, it looks like the traffic log patterns are missing a lot of traffic.
Does it happen to be logging based on samples taken every 10 seconds or so? It looks like the only traffic being reported in the logs is traffic that:
It might not intentionally be only picking up TCP traffic; that could be an artifact of the stateful nature of TCP over UDP and ICMP. Either way though, lots of traffic is flowing across the subnet bridge that is not being logged in the tailscale logs.
@JohanW, since you specifically were worried about that scenario, FYI. I suggest relying on a different method for capturing network traffic at that transition.
Separately from all of the above, the local logs are doing a good job of capturing the fact that traffic occurred between tailscale nodes, at least. It’ll be nice to get access to this API some day to not have to worry that we’re missing a log upload somewhere. (And your API will be better than what I’ve hacked together, 100%.)
This is correct. The default behaviour of the client right now is just to capture a “sample” of traffic, which is more useful for diagnostics than for an audit trail. In particular, we allow a higher frequency of messages for rejected requests than allowed ones, since you might need to see those logs when trying to debug ACL policies.
There are a few undocumented features for opening the firehose of connection logging, used by a few larger customers already, but we want to refine this a bit more before we open it up to everyone.
ᐧ