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

Customizable logging for message parts? #1195

Closed
reidsunderland opened this issue Aug 28, 2024 · 5 comments
Closed

Customizable logging for message parts? #1195

reidsunderland opened this issue Aug 28, 2024 · 5 comments
Labels
enhancement New feature or request Sugar nice to have features... not super important. wishlist would be nice, not pressing for any particular client.

Comments

@reidsunderland
Copy link
Member

The current logging that shows accepted and posted messages comes from flowcb/log https://github.com/MetPX/sarracenia/blob/development/sarracenia/flowcb/log.py.

In some cases, it would be useful to show additional information like the sundew_extension, size, checksum, pubTime, but these aren't necessarily useful in all cases.

We have a logEvents option that makes it possible to fine tune which log messages show up. Maybe it's too much fine tuning, but we could add another option that that lets us define which part of the message we want to see in the log (add sundew_extension, etc. when useful).

We do have messageDebugDump, but it shows too much information for most cases, and the dictionary format is harder to read. I also just noticed that it's not documented in SR3 Options.

@reidsunderland reidsunderland added enhancement New feature or request wishlist would be nice, not pressing for any particular client. Sugar nice to have features... not super important. labels Aug 28, 2024
@petersilva
Copy link
Contributor

copying stuff over from #1156...
1 option is to change the default logging to include:

  • if present: sundew_extension
  • if present: first seven (based on git example) chars of identity value, like so "id: ab13f12"
  • if present: size (not humanized to avoid loss of precision.)

to ... post? or accept, or both? (the routines in sarracenia/flowcb/log are _messageAcceptStr and _messagePostStr

@petersilva
Copy link
Contributor

I don't know if the changes to default would be enough to obviate the need for programmable fields.

the best part is no part ... Elon Musk

@petersilva
Copy link
Contributor

so... looking at log.py, I see that _messagePostStr is not even called by default, it calls just messageIDStr which is literally just the URL... maybe we need an overarching logging verbosity setting? something like:


logVerbose 0    ... warnings errors...
logVerbose 1    ... info... with msgID str...
logVerbose 2    ... info ... with medium message info (selected fields.)
logVerbose 3    ... info ... with full message dumps.
logVerbose 4  ... debug... with msgIDstr...
logVerbose 5  .. debug... with medium message info
                   7  ... debug with full dumps.
logVerbose 8 ... turn on message protocol debugging... 


@petersilva
Copy link
Contributor

I thought this would be a five minute job... but the flow tests use the log outputs, so it's means modifying them all...

@petersilva
Copy link
Contributor

to avoid messing with the tests... just make sure the new fields are near the end.
sample post mod post log:

2024-08-28 13:00:40,127 [INFO] sarracenia.flowcb.log after_post posted to exchange: xflow_public topic: v03.post.20200105.WXO-DD.meteocode.atl.csv a file with baseUrl: h
ttp://localhost:8001/ relPath: 20200105/WXO-DD/meteocode/atl/csv/2020-01-05T03-00-01Z_FPHX14_r9zf_PA.csv size: 804 id: ruTzj2p

This is from static, so no sundew_extension present... but I really like the short id string.

petersilva added a commit that referenced this issue Sep 3, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request Sugar nice to have features... not super important. wishlist would be nice, not pressing for any particular client.
Projects
None yet
Development

No branches or pull requests

2 participants