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
Logging in Watchbot4 #205
Logging in Watchbot4 #205
Conversation
* adds logging of watcher-level errors, worker receives, and completion status * prefixed logs from child processes
Move binary-split from dev to dependency
* change scale-down MetricIntervalLowerBound to MetricIntervalUpperBound
lib/logger.js
Outdated
@@ -31,11 +31,11 @@ class Logger { | |||
} | |||
|
|||
workerFailure(results) { | |||
this.log(`[failure] ${JSON.stringify(results)}`); | |||
this.log(`[worker] [failure] ${JSON.stringify(results)}`); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These logs are not coming from the internals of the worker, but are instead coming from the watchbot listen
process. Should this be prefixed with [watchbot]
instead?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see workerFailure
is called from
Line 51 in 7c5b226
this.logger.workerFailure(results); |
do you also suggest changing the method names as
watchbotFailure()
?
Other than this I think it is necessary to prefix [worker]
here
Lines 19 to 20 in 7c5b226
child.stdout.pipe(logger.stream()); | |
child.stderr.pipe(logger.stream()); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right, it's necessary to prefix [worker]
on those streamed logs since they are actually coming from the worker child process, while the message with the results JSON is coming from the code inside of watchbot. I think the function should still be called workerFailure
, but since this log is taking place inside of the watchbot code and not inside of the code defined by the user in the subprocess, the log should be prefixed with [watchbot]
.
* Add alarms and alarm docs * Add failedPlacementAlarmPeriods * Add CloudWatch Alarms snapshots * Update template jest snapshots * Add CloudWatch Alarms snapshots * Add failedworker and failedworkerplacement metric * Typo r/LogGroup/Logs * Change metric name * Metric Filter of worker errors to "[failure]" * Have current published version instead of undefined * Jake's Review * uh update-jest * Update alarms.md
572eb90
to
b48ba7e
Compare
* Add alarms and alarm docs * Add failedPlacementAlarmPeriods * Add CloudWatch Alarms snapshots * Update template jest snapshots * Add CloudWatch Alarms snapshots * Add failedworker and failedworkerplacement metric * Typo r/LogGroup/Logs * Change metric name * Metric Filter of worker errors to "[failure]" * Have current published version instead of undefined * Jake's Review * uh update-jest * Update alarms.md
8ce7c9f
to
566c4e8
Compare
427a8ca
to
1c1b28d
Compare
* Add travis user * Ensure this fails * Add validation for notificationEmail or notificationTopic
…queue threshold, info to doc (#211) * Closes #208, #207, #206, #182, #149, #72, #15 (cherry picked from commit 8de328df79ccf52b8d612c625891555808c2fa0e) * Add minSize as option * update jest tests * Change MinSize to 0 * update jest * identation and minSize to 0 * Add deadletterThreshold info in Worker-retry-cycle
3a196da
to
1892852
Compare
Seems like this PR needs to be rebased on master. @tapasweni-pathak let us know when you're ready for this to get a final review! |
@jakepruitt The Travis is failing, can you run in your local and suggest what is missing in the tests? Plus I don't think I would be rebasing this one, I would just create a new one. |
Hmmm @tapasweni-pathak I was able to fix the test locally, but it looks like I can't replicate the |
@jakepruitt I added an empty commit for |
@tapasweni-pathak yeah, the EPIPE was passing for me locally. Could you set this up on a new branch/rebased branch and see if the error persists? I think we should address it in a fresh environment that we know is up to date with master, since it's tough to know the state of the files in this branch. |
@jakepruitt yeah error persists, I already created a separate PR #225 before checking again if the tests worked locally for you. Tests didn't work locally or on Travis for me. |
Could we close this PR to avoid confusion with #225? |
Closing in favor of #225 |
Closes #204.
cc @mapbox/platform-engine-room.