This repository has been archived by the owner on Oct 4, 2019. It is now read-only.
cmd/geth: implement interval-based status logging #324
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
may be worth thinking about more flexible and beautiful ways to display information... 'monitor', 'attach', etc, along with termui, graphs... output can be 'machiney'-- line-by-line, or human-y -- pictures of buffalo and whatnot.
solution: use a go func connected to the node's Ethereum to grab and calculate relevant logs rel ethereumproject#127 rel ethereumproject#318 --- TODO: fix or remove: - downloading-from peers, eg 'this var/x/x peers' - shows mode 'FullSync' before downloader initializes, even if it will be 'FastSync'
solution: comment code and include small explanation
solution: remove exploratory code that is not useless
solution: move to Warn from Error
solution: update it and simplify
solution: - remove dead code, old notes - remove units from --log-pace= argument, just use seconds as value (simpler is better) - if mining, show STATUS MINE with minerthreads and hashrate (TODO: more?) - gofmt Rel ethereumproject#127, ethereumproject#318
solution: improve legibility
solution: relegate to debug
solution: share chan in main between shutdown and closing status log goroutine
solution: implement and glog SetAlsoToStdErr exported function and use in case of --log-dir
results in missing any logs after shutdown processes in FS logs solution: defer log Flush after shutdown services also decrease flushInterval from 30 -> 5 seconds (rate at which log buffer is written to FS)
solution: rename flag and flagvar and status log function also adds logstatus flag to correct category for usage output
solution: refactor to use '--log-status='sync=60'' syntax, which can eventually support other features besides 'sync', eg. mine, net, disk
…to cmd.go solution: cut and paste and update imports
whilei
changed the title
solution: error if neither fastblock nor fullblock match desired head number fixes ethereumproject#325
solution: don't share os-interrupt channel as a global. Notify library documentation clearly says Notify events can be called multiple times and notification will be copied, so there's no harm in listening for the same event on mutliple channels. This pattern avoids a global and encourages per-feature handling of shutdown scenarios.
…g-pace' wording solution: fix
This was referenced Jul 31, 2017
3 tasks
splix
approved these changes
Aug 16, 2017
Closed
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Rel #127, #318
Currently looks like this:
So far, I've made the optional interval-based logging use
Error(level=1) tier of logging priority, which enables a user-specified graduated combination of event-based and interval-based logging (since Error is "highest" priority tier), eg.TODO:
--log-pacename? Alternative ideas might be--log-status,--vstatus, ...--log-status--log-status="sync=60,disk=120,net=30,mine=10", where current PR deals only withsync=<interval>functionality, but in the future we might want interval-based status logs for additional information, like disk I/O rates, network latency, and mining progress. This proposed flag argument syntax echoes existing--vmodule="eth=2,core*=5", but uses integer values for interval rates instead of verbosity levels--log-status="sync=60", with extensibility then for comma-separated input<feature>=<interval>, eg.--log-status="sync=60,mine=15,net=120"