-
Notifications
You must be signed in to change notification settings - Fork 888
feat: show health check warnings #10620
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
Changes from all commits
6f4c14d
059e9fa
ee8bd1b
99893ff
5eba101
b0dace2
f97a359
7f82c1b
6fed35b
e9497ee
fa7224f
6495bb0
75f271e
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -31,6 +31,8 @@ type Report struct { | |
Time time.Time `json:"time"` | ||
// Healthy is true if the report returns no errors. | ||
Healthy bool `json:"healthy"` | ||
// Warning is true when Coder is operational but its performance might be impacted. | ||
Warning bool `json:"warning"` | ||
Comment on lines
32
to
+35
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. What if we get a report that has both There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. You're right, but I'm afraid that it will not be achievable without breaking API? I introduced the "warning" field to be perceived as "it is healthy, but...". To solve it properly, most likely we need to replace "Healthy" with enum, for instance: I'm happy to chat about this as it is the right moment. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The more I think about it, it could be useful to have both health and warn information, as they are not necessarily completely separate. For example, if you're using embedded database and access URL just points straight to the VM, and you get a failed healthcheck for database taking too long and warnings for access URL taking too long to respond, that can already give you an indication that perhaps the server is overloaded. Maybe we could add
at the top level, and any warnings from component reports get added in? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I agree with this concept if only we present these warnings on the "Health" page 👍 Otherwise, it is pointless. It also means that the Health page will become more informative than just Healthy/Unhealthy + JSON dump. |
||
// FailingSections is a list of sections that have failed their healthcheck. | ||
FailingSections []string `json:"failing_sections"` | ||
|
||
|
@@ -139,6 +141,9 @@ func Run(ctx context.Context, opts *ReportOptions) *Report { | |
if !report.DERP.Healthy { | ||
report.FailingSections = append(report.FailingSections, SectionDERP) | ||
} | ||
if report.DERP.Warning { | ||
report.Warning = true | ||
} | ||
if !report.AccessURL.Healthy { | ||
report.FailingSections = append(report.FailingSections, SectionAccessURL) | ||
} | ||
|
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
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.
This is the most important logical change. Using WebSockets won't be considered to be a failure anymore.