Troubleshooting features

Ideas
1

These might exist, but I must say, I haven’t been able to figure out on my own, so I’m suggesting these here.

  1. Managing a server via a specific client (client ID or key exchange that allows the client to interact with the server).
    Pros: convenience, being able to manage from the client side can reduce friction of management.
    Cons: risky, allowing the API to perform ‘dangarous’ tasks, such as user generation or deletion. If this is the reason, then at least add ability to recieve a live log from the server for troubleshooting purposes.

  2. A CLI option to dump current settings as a config.kdl file, this will be helpful with troubleshooting. If a secret is involved, replace with a comment and the secret scrubbed.

  3. A CLI option to dump diagnstics, including config (see #2), versions, relevant environment values, DNS resolution of sync server, and when was the last response from that sync server.
    This diagnostics output should probably include some link to this forum or documentation about how to troubleshoot.

  4. Tying #1 and #3, a way to grab server diagnostics remotly from the client, including the fact that the data has been pulled remotely.

  5. A way to get verbose output/logging - both on the client side and on the server side.

2

What sort of management do you envision people needing to do often enough that this would be useful? Imo the cons severely outweigh the pros, and are more than what’s listed. Arguably, these features are up to the deployment mechanism (k8s, docker swarm, whatever)

This could be useful!

Been thinking about this today - now that GitHub issues have forms, we could require the output of some diagnostic command in order to open an issue.

We have ATUIN_LOG=debug on the client, and RUST_LOG=debug on the server. If you follow the docker-compose setup guide, this is already correctly setup for you: Docker | Atuin Docs

3
  1. First and formost: getting status and server stats. The name of the user currently connecting, how many users, when was each user last synced etc. - This provides a complete lifecycle test of connection to the server, authentication functioning well, as well as receiving meaningful data from the server.
  2. Diagnostics (as mentinoed in #4 above)
  3. User management: deleting, clearing users data.

Thanks for pointing to them, sorry to have missed those.

1 Like
4

Fwiw, we have a prometheus endpoint you can scrape where we expose a lot of this. I’d happily add more metrics, and improve the tracing.

5

I’ll take a look at that (I did setup a prometheus server not long ago - still under utilizer), but I’m thinking of being able to manage everyhing form a single mangement location - the cli of where, me - the admin of the server, is currently on.

I’m always thinking “how can I be the laziest and get as much detail as possible”

I completely understand if this rubs against the grain - as I’m coming from a single-user, with maybe a max of 3-5 total users for my server.

My suggestion comes from seeing how versatile the tools is already, and just having that 1st point would probably go a long way in assisting in making managing the self-hosted server much easier.

I also understand the risks, and so the Diagnostics and user management - these might be overkill, but that 1st one - of just diagnosing the connection and identifying who is logged in.

And if some role assigned to the user allows it - providing some basic stats as mentioned above.

Thanks for engaing, and sorry for being such a pain with these requests/ideas.