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

exp/ingest/ledgerbackend: Stream stellar-core logs to file #2673

Conversation

bartekn
Copy link
Contributor

@bartekn bartekn commented Jun 5, 2020

PR Checklist

PR Structure

  • This PR has reasonably narrow scope (if not, break it down into smaller PRs).
  • This PR avoids mixing refactoring changes with feature changes (split into two PRs
    otherwise).
  • This PR's title starts with name of package that is most changed in the PR, ex.
    services/friendbot, or all or doc if the changes are broad or impact many
    packages.

Thoroughness

  • This PR adds tests for the most critical parts of the new functionality or fixes.
  • I've updated any docs (developer docs, .md
    files, etc... affected by this change). Take a look in the docs folder for a given service,
    like this one.

Release planning

  • I've updated the relevant CHANGELOG (here for Horizon) if
    needed with deprecations, added features, breaking changes, and DB schema changes.
  • I've decided if this PR requires a new major/minor version according to
    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

Stream stellar-core logs to file.

Why

Currently we stream logs to stdout what can be hard to read when also Horizon logs are streamed.

@bartekn bartekn requested a review from a team June 5, 2020 13:36
@cla-bot cla-bot bot added the cla: yes label Jun 5, 2020
Copy link
Contributor

@abuiles abuiles left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@bartekn 👍 -- shall we create an issue to make this configurable?

@bartekn
Copy link
Contributor Author

bartekn commented Jun 5, 2020

shall we create an issue to make this configurable?

Do you mean if logs should be streamed to a file? I'm not sure. We create a file in a tempdir that gets removed when ledger backend is closed so it shouldn't be an issue.

@abuiles
Copy link
Contributor

abuiles commented Jun 5, 2020

Do you mean if logs should be streamed to a file? I'm not sure. We create a file in a tempdir that gets removed when ledger backend is closed so it shouldn't be an issue.
👍

}()
return w
func (r *stellarCoreRunner) getLogLineWriter() (io.Writer, error) {
f, err := os.OpenFile(r.getLogFilePath(), os.O_APPEND|os.O_CREATE|os.O_WRONLY, 0644)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Having real time logs of core interleaved with the horizon logs can be valuable to reason about what's happening, I wouldn't totally remove the option of printing the logs instead of using a file.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In fact, wouldn't it be simpler to simply print the Core logs (with the same format as the Horizon ones) but control their verbosity (including not printing any logs at all)?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Using a temporary file which gets removed makes debugging cumbersome:
0. You need to make sure the file isn't removed (e.g. if horizon crashes or if the container terminates they will be gone).

  1. You need to fish for the file
  2. You need to reason about the timestamps of the file with respect to the timestamp in the horizon logs

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In fact, wouldn't it be simpler to simply print the Core logs (with the same format as the Horizon ones) but control their verbosity (including not printing any logs at all)?

I think it makes sense. My only worry is that the log format may change in the future breaking the parsing code but I think we should be able to catch it quickly. I'll update the PR.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We could add a test for it, so that we catch it when it happens. Right?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes but this requires integration tests (you actually need to run stellar-core to catch this) and we don't have them yet.

@bartekn bartekn changed the base branch from captive-core to captive-core-online June 17, 2020 10:29
@bartekn
Copy link
Contributor Author

bartekn commented Jun 18, 2020

I think you could use the same writer for both (assuming stellar core writes line by line, which it should).

On top of that, the line writer goroutines should be stopped on Close() (it didn't matter for debugging, when it was commented out, but now they will cause a memory leak).

Originally posted by @2opremio in #2694

@bartekn bartekn force-pushed the captive-core-stream-logs-to-file branch from 644e175 to e5e10f8 Compare June 29, 2020 15:08
@bartekn bartekn closed this Jul 15, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants