services/horizon: Add more verbose logging for horizon start up #4161
Conversation
erika-sdf
changed the title
| @@ -509,6 +509,8 @@ func NewAppFromFlags(config *Config, flags support.ConfigOptions) (*App, error) | |||
| if config.Ingest && !config.EnableCaptiveCoreIngestion && config.StellarCoreDatabaseURL == "" { | |||
| return nil, fmt.Errorf("flag --%s cannot be empty", StellarCoreDBURLFlagName) | |||
| } | |||
|
|
|||
| log.Infof("Initializing horizon...") | |||
There was a problem hiding this comment.
does this output print on console, wasn't sure on significance of using this or stdLog, the desired outcome is to be on console correct, assume they both output there, was just asking for my own edification on logging preferences.
There was a problem hiding this comment.
Both log and stdLog calls print to console. The code that runs prior to the logger initialization uses the stdLog calls. I think @jacekn 's feature request was specifically about seeing failures prior to the initialization, so the stdLog statements provide some context on what's happening.
| @@ -18,6 +18,7 @@ import ( | |||
| ) | |||
|
|
|||
| func mustNewDBSession(subservice db.Subservice, databaseURL string, maxIdle, maxOpen int, registry *prometheus.Registry) db.SessionInterface { | |||
| log.Infof("Establishing database session at %s for %v", databaseURL, subservice) | |||
There was a problem hiding this comment.
Sorry for a late review. I was OOO. Not sure if we should print databaseURL as it contains a sensitive info (password).
PR Checklist
PR Structure
otherwise).
services/friendbot, orallordocif the changes are broad or impact manypackages.
Thoroughness
.mdfiles, etc... affected by this change). Take a look in the
docsfolder for a given service,like this one.
Release planning
needed with deprecations, added features, breaking changes, and DB schema changes.
semver, or if it's mainly a patch change. The PR is targeted at the next
release branch if it's not a patch change.
What
Add more verbose logging to horizon start up. Include lines that signal db migration and captive core set up, which should be logged to stdout since it happens before logging is set up.
Why
It would make debugging easier.
Known limitations