-
Notifications
You must be signed in to change notification settings - Fork 275
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
Reintroduce health liveliness check #1859
Conversation
This comment has been minimized.
This comment has been minimized.
let's think about how these gql queries get (or shouldn't get) reported to studio. |
(moved conversation from slack) I'm using OTel for traces and I'm seeing a million health check traces that distract from the useful ones. Any ideas on how to avoid that? Thanks for adding this back! |
...uter/src/configuration/snapshots/apollo_router__configuration__tests__schema_generation.snap
Outdated
Show resolved
Hide resolved
); | ||
.expect("query is always valid"); | ||
async move { | ||
let (parts, body) = run_graphql_request(service, health_check_request) |
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.
instead of calling run_graphql_request
and needing to deserialize json, maybe this could reproduce this part of the run_graphql_request
function?
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.
We're going with a static response for now
closes #1861
fixes #1852
Reintroduce health liveliness check (Issue #1861)
Depending on their environments and cloud settings, users may or may not be able to craft health probes that are able to make CSRF compatible GraphQL queries.
This is one of the reasons why we reintroduced a health check in the router.
The health liveness check endpoint is exposed on
127.0.0.1:8088/health
, and its listen address can be changed in the yaml configuration: