Totally new user to OpenZiti. I went through the quickstart tutorial, and then proceeded to deploy a controller and router in a publicly accessible Linux cloud VM. I’ve installed a tunneller client on my home (Linux) laptop and have defined a Ziti service so that I am able to SSH to the cloud VM using the service’s Ziti “hostname” and have the traffic flow over the overlay (as opposed to directly on the Internet).
I was looking for a way to see active Ziti “sessions”, which for me means tunnels/flows currently set up and in use, and I thought that the Sessions > Sessions window in the Ziti Console, or the ziti edge list sessions command would give me that, but they both return an empty list, even though I have an active SSH connection to my Cloud VM via the Ziti overlay. Based on this thread, it also seems like “sessions” is NOT what I am looking for.
Therefore, my question is: what are (non-API) sessions exactly? And in which circumstances would I reasonably expect to see actual stuff in the ZAC or output of the ziti edge list sessions command?
Hi @techstone, welcome to the community and to OpenZiti!
Sounds to me like you're looking for ziti fabric list circuits. That is only going to show you circuits that are persistent. For a dynamic view of connections like HTTP which start and end very fast you'll want to leverage the metrics reporting from OpenZiti and aggregate the dials/data in some sort of data lake where you can query and put all those pieces together. hth
Oh and as for sessions - I minimized that actual question because soon enough sessions aren't going to be as important as I understand it. I'm not on the path forward at the moment, but I do believe they are becoming less important soon with upcoming changes (is my understanding).
Sounds to me like you're looking for ziti fabric list circuits .
You're absolutely right; this is what I was looking for.
That is only going to show you circuits that are persistent.
I was focusing on my desire to see the persistent SSH connection, but that's a really good point regarding the ephemeral nature of HTTP connections.
Going back to my original question then, simply out of curiosity: what is the nature of the "sessions" that can be listed in ZAC/ziti edge list sessions? I searched through the documentation and found this diagram. Is the Session (per service) in the diagram what is referred to as a "session"? It seems to me like these session events would be quite short lived, correct? I think what confuses me a bit is that the ZAC dashboard has a metric for identities, services, routers, etc., and it also has a metric for sessions, so I interpret that to mean that sessions are quite an important concept, yet the dashboard shows them at zero (in my case), whereas all other items are at one or more. So I was looking for the "significance" of sessions here, but couldn't figure it out. Do I gain much from understanding what sessions are, or should I just let this one go?
I run my own small OpenZiti overlay and for me, it's not something I have ever had to focus on, personally. I also see I used "session" in my previous reply but i MEANT "api-session" before... That's my bad. I help a lot of people on discourse and I've never had to ask them to list their sessions unless something dreadful is happening.
It's been useful in the past for production users, when some process goes crazy and creates thousands of sessions or those sessions don't end up cleaning up and hang around for too long and things like that. So they are useful at times for sure but in all my time looking at OpenZiti consoles and CLI comands they aren't something I've ever actually used much myself. I'm not the session/api-session expert though so maybe I'm missing out too!
session is an authorization token to dial or bind a service. each session is attached to an api-session. In the legacy implementation sessions were stored in the database and synced to ERs. Because of identity+service cardinality it created various scalability issues.
If you're using internal OIDC auth or ziti 1.7+ sessions are just JWTs. This change removes the need to store them in the database and sync them to ERs. But this also means that you wouldn't be able to list them with CLI.
Thank you both! The way I understand what you wrote, I don't think shouldn't concern myself with sessions that much. They're more of an implementation detail and it seems other metrics will be a whole lot more valuable for troubleshooting purposes than sessions.
on the path forward at the moment, but I do believe they are becoming less important soon with upcoming changes (is my understanding).
