Now, I installed rootsh on a test server and it works fine when called the normal way (sudo rootsh). However I want to invoke the rootsh also when the regular user uses.

I want since that non-root user is used for normal day to day activity. I just want to redirect all possible instances of su (sudo su -, sudo su, su - and su) redirected to rootsh, so that when that users changes to root, his activities are logged.

You might look at auditd instead. Which distro is this for, including version?

^What Turbocapitalist said. auditd is definitely better suited for this. There are quite a few example rules that come with the package. On Fedora-based systems, they are under /usr/share/audit/sample-rules. On Debian-based: see /usr/share/doc/auditd/examples. Particularly, see comments in 30-pci-dss-v31.rules and 30-stig.rules about putting pam_tty_audit.so into /etc/pam.d/su, /etc/pam.d/sudo.

That said, I can think of a possible partial rootsh solution. /etc/pam.d/su will usually include a call to pam_env.so. You can put into /etc/security/pam_env.conf something like
Note the use of @: RUSER is an environment variable, but PAM_RUSER isn't: it's a PAM item. This way the root environment after su - will have the variable RUSER containing the name of the user who was authenticated. Similarly to how you have access to SUDO_USER after sudo -i. Then it's a matter of putting the check for the said user at the end of /root/.bash_profile :
su without - won't run commands in /root/.bash_profile. It would execute commands in /root/.bashrc though, but depending on your configuration, it may be not appropriate to invoke the standalone rootsh from .bashrc. At the very least, it would require some testing on your part and possibly rewriting of /root/.bashrc, /root/.bash_profile and/or other shell startup files.

All of the above is highly speculative and not tested. You should keep another root terminal window open when trying this, just in case.

deleted

Is this user an admin? If not, why is he able to get to root?
I definitely agree that whatever a user does as root should be recorded and auditable.

One possible approach to your goal would be an alias for both su and sudo. Since the system looks at an alias before going to the actual command it seems pretty simple to set up an alias for both su and sudo that would invoke the rootsh when those commands are used.
You can look at "alias" to see how that would be done and in fact you likely have several aliases already defined for each user for things like grep, ls, which, etc. If ls and grep results are colored then you definitely are using an alias. Most of those aliases are defined in /etc/profile or one of the scripts in /etc/profile.d and become active as soon as they login or open a terminal.

Another approach would be to force the user to only use sudo where each command is already logged. They would not have the new root password and thus be forced to sudo everything.

The sudoers file can easily be configured to allow the sudoer access to only the actions they are expected to perform and block the use of sudo su. It can limit access by defined groups or by individual users and give different users or groups access to different commands.

I guess an alias is way too easy to circumvent whether by invoking it as \su, by specifying the absolute path /usr/bin/su or just by unalias su.

True
That is why I also suggested the access be restricted to sudo and never allowing the user to su to root. Sudo can give the access needed without compromising the entire system and logs everything done so the use of rootsh is probably not needed.

Yes, knowledge of proper sudo usage is rare and, apparently, hard to get accross to people. However, it might be part of the solution in this case. I'd aim for non-technical solutions first.