1) If you need to use web services, your web service can post events to Seq via HTTP/S - API docs are at: http://docs.getseq.net/docs/posting-raw-events (batching events is highly recommended in this scenario).
2) If you can avoid the literal interpretation of "web service" and instead just stand up another HTTP endpoint on the server that exposes the web services, you can install Seq to listen at a URL prefix like https://my-server/seq, which allows other services to listen on other endpoints like https://my-server/... Documentation on setting this up is here: http://docs.getseq.net/docs/storage-paths-and-urls#section-the-listen-uri
3) Again in the case of Seq, if you're sending events via Serilog you can set up two Seq servers and log to both of them:
.WriteTo.Seq("https://primary-seq")
.WriteTo.Seq("https://backup-seq")
In this case all of your log searching etc. would need to take place on the primary instance, as configuration data (permissions and so-on) wouldn't be replicated between them.
You might also consider using the bufferBaseFilename for one or both connections, which will buffer events locally to a file so that some server downtime is tolerated.
If your auditing requirements are transactional however (i.e. legal/compliance), you should probably still consider writing these inside regular transactions to your SQL database, if you have one.
