-
-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
feat: provide logger customization #410
Conversation
Let's discuss if it covers your issues. |
What about removing log from fetch at all? This will be more “browser” like. |
4 additional API endpoints) I’ll try to do my version of addressing same issues today. |
zx is suitable for crawling too, so fetch/http logging might be useful.
I can assemble them into
It's essential to bind log profile to async ctx: $.profile({logFormat: maskingLogger}, async() => {
await $.fetch('https://exampe.com', {authorization: ...})
// fetch https://exampe.com {"Authorization": "23e334ds******23"}
$`qctl login ${token}`
// $ qctl login fr324d324******09
})
$.profile({logIgnore: 'fetch'}, () => {
// push smth optinal that does not requre logging or even waiting
for(let url of urls) {
$.fetch(url, {data: ...})
}
}) |
True. I’m thinking about something like this:
|
+ zx logs are more of debug/tracing which usually goes to stderr (console.trace) |
Also echo can also be to stderr. WDYT? |
Let's make it configurable like in debug: log('cmd:input', ...)
log('cmd:output', ...)
$.logIgnore = ['cmd:*'] // to disable all
$.logIgnore = ['cmd:output'] // to disable stdout pushing External plugins may bring their own log events, so we need to apply filters to them too. |
This might be surprising a bit. UPD But if |
Lets not allow plugins to use zx logs. I’d like to keep logs of zx as internal as possible. |
Logger is essential.
Why log format is needed: we have a special magic process on our kuber pods that captures stdstreams and pushes their contents to elastic index. But it happens only for json strings with special fields, so we have to attach them somehow. |
Show your concept. I'll try to mimic. 0/1/2 level schema as you mentioned is fine, but it has some limitations. For large scripts level 1 may be not enough for debugging when option 0 produces too big output to recognize. Instead, I suggest introducing a composite dynamic scope prefix: |
Idea! We can use standard |
too many abstraction. Lets try to find simplest solution. Let’s reduce complexity. Can you expla little bit more your needs? |
Too many java devs around ))) I'm trying to attach meta to every log event to be able to: 1. process only necessary, 2. define event projection — format and channel How I'm going to use these powers — wrapping some code blocks with retries and raising log verbosity for the last attempt and every next matching bin. |
Maybe it's too much. Reverted. |
My biggest complaint was the nonstandard usage of stdout for diagnostic logging, rendering any shell script looking to provide an "output" problematic. Seeing that's finally being defaulted to stderr recently, great. Beyond that, the logging mechanism doesn't need to be this complex, a simple |
Thanks for the feedback. I've tried to combine both approaches:
|
0623812
to
17b9889
Compare
The v7 will introduce |
closes #376
closes #405
ignore
dep already comes withglobby
.Pros
cd/fetch/cmd,...
if (!verbose) return
at single placeCons
verbose
flagnot applied to spawned processes outputs, they just go as is to the root process stream