Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

More visibility in Seq for events dropped at the client #127

Open
DanAvni opened this issue Dec 1, 2019 · 3 comments
Open

More visibility in Seq for events dropped at the client #127

DanAvni opened this issue Dec 1, 2019 · 3 comments

Comments

@DanAvni
Copy link

DanAvni commented Dec 1, 2019

after setting eventBodyLimitBytes to some value, if an event is dropped because it's size is too big please add an option to add an alternative fixed message to the log (e.g. "Event dropped because size is too big") so that the person reading Seq will at least know that there was something here and that he might find this info in the file logs I keep

@nblumhardt
Copy link
Member

Thank you for your suggestion, Dani.

One way this might be emulated, currently, is to enable SelfLog and re-emit an event through the Serilog pipeline if the text matches the one in:

https://github.com/serilog/serilog-sinks-seq/blob/dev/src/Serilog.Sinks.Seq/Sinks/Seq/SeqSink.cs#L187

Not an entirely elegant solution, but worth considering if this is important in your usage scenario.

@DanAvni
Copy link
Author

DanAvni commented Dec 2, 2019

Nick,
Few points:

  1. that would cause the long json event to be logged (as it is written in the line you mentioned)
  2. I have created in Seq many API keys for many services. Chances are that the user reading the logs using Seq will filter by specific properties added by each API key to distinguish the source of the message. That means they will not see the messages emitted from the self log and when reading the log will not know a line is missing.
  3. another thing that comes to mind is that the alternative event written to the logs should be customizable with a few properties (like original message timestamp, original message size). not sure about allowing access to other properties of the original message so a loop is not created if I reference the original message property that caused the whole thing to be too long

@KodrAus KodrAus changed the title Feature suggestion More visibility in Seq for events dropped at the client Jun 12, 2024
@nblumhardt
Copy link
Member

We've reviewed this again and think that something along these lines could address your requirements and not add too much more complexity in this sink:

serilog/serilog#1791 (comment)

The essential idea is that you'd register a handler for logging failures, the handler would have access to the "problem" events in their original form, and we'd try to make the result of the callback actionable. Will continue fleshing this out over there.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants