The question is slightly vague, but from the sound of it, I think you are asking if you can use svlogd to send syslog messages to another program besides rsyslogd. The answer is, any program that provided a syslog service would suffice. There is more than just rsyslogd that provides a syslog network service.
However, the way runit was intended to "natively" handle logging is probably backwards from what you are thinking.
The idea is that you have a service of some kind, and that service writes output through stdout or stderr. The runsv program will bring up svlogd and erect a pipe between your service and svlogd; all your service has to do is send data to stdout/stderr, svlogd will write directly to disk, and life is good. Because the pipe is maintained by runsv, should there be issues with the service going down, output is still captured and delivered to svlogd - so in theory, you don't loose logging data due to a service crash.
There is another program by the same author, socklog, that acts as a syslog front-end that funnels to a svlogd. Because there are a lot of programs that just assume that /dev/log is available, socklog provides this interface so that syslog data can be captured - it acts as a substitute syslog service. This is the opposite of what you are suggesting.
I'm not saying you shouldn't use syslog, I'm just saying that there's more than one way to do this. If you really want to shunt your output from svlogd back to syslog, then yes, any old syslog service will do just fine, but it may be worth considering going "all native" and ditching rsyslogd altogether, if your installation permits this.
