Seq Documentation and Support

Seq Documentation and Support

Welcome to the Seq documentation hub. You'll find comprehensive guides and documentation to help you start working with Seq as quickly as possible, as well as support if you get stuck. Let's jump right in!

Get Started    
Ask A Question



Ingestion fails with 403 Forbidden

I'm in the process of evaluating Seq using Kubernetes in Azure. My structured log messages are coming from an ASP.NET core application via Serilog. However log messages don't arrive at the Seq server, instead I receive the following error: `A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond` Testing same IP and port using Postman gives me a 403 response; "Forbidden" However the Seq UI, on port 80, is working fine. __What I've tried:__ I enabled Serilog.Debugging.SelfLog. It returns the error message mentioned above. I downloaded the full diagnostic report from the Seq diagnostics menu; no errors spotted. The Ingestion log says: `The ingestion API is configured and accepting requests` and the Server log says `"Seq listening on {ListenUris}","ListenUris":["http://localhost/","http://localhost:5341/"]` I inspected the Azure Network Security Group associated with the Kubernetes service. Port 5341 is accepting incoming requests. If I remove or change the port number then the response changes from 403 to 504 so I don't think this is an Azure network issue, since it seems like the request makes it to Seq's pod. Locally I've tested logging to Seq when running on both Docker (using sample commands provided on docker hub) and Kubernetes (using same deployment yaml as used in AKS) and both times Seq ingestion worked fine. I'm not sure what else to try at this stage. Any help in resolving the cause of my issue would be greatly appreciated. If you need a dump of the logs or deployment yaml please let me know. Thanks.

Posted by Kristian Eliasson about 14 hours ago


Considerations when using SEQ as AuditLog

We have been considering the Pros and Cons of using SEQ as the repository for our AuditLog. I have read a few questions in this forum (eg. [This] ( and [This]( ). However I still have a few questions: **What's the difference between WriteTo and AuditTo?** Assuming that the SEQ server and the connection to the SEQ server doesn't go down - I would guess that WriteTo still maintains the same sequence of events as AuditTo? Or that this problem could be solved using a timestamp generated in the client code? As far as I have understood this - just using WriteTo and not generating the 'auditing timestamp' - but relying on the SEQ server timestamp will actually be a problem for the sequence? **Is there a difference with exceptions, when using WriteTo and AuditTo?** In one of the previous post - answers you wrote: > AuditTo has the advantage of logging synchronously and propagating any exceptions, > but of course comes with a corresponding performance cost. You could use a second > server and WriteTo if guaranteed audit logging isn't a strict requirement. Could you try and explain this in a bit more detail? **Is performance good enough?** When sending both regular 'warnings and errors' to SEQ the number should be pretty low, but including an audit trail for each user severily increases the number of events sent to SEQ. Do you have a kind of 'formula' to use when trying to estimate disc usage and other HW specs? The reason I'm asking is that it could be a requirement to keep this kind of data between 1-5 years and I'm kind of worried that disc space especially could be an issue - because the auditlog cannot be deleted and it should also still be searchable. **Could you perhaps add a seperate documentation section about using SEQ as AuditLog?** SEQ has many advantages and I'm assuming that we are not the first ones considering to use SEQ as a audit log repo - it might be worth it to keep a seperate link on the documentation page about this. Just describing those 'special concerns' that needs to be thought about when using SEQ for this fairly important log.

Posted by Allan 19 days ago