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

tempo-query: add ReadinessProbe #1061

Merged
merged 1 commit into from
Oct 16, 2024
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
16 changes: 16 additions & 0 deletions .chloggen/tempo-query_ReadinessProbe.yaml
Original file line number Diff line number Diff line change
@@ -0,0 +1,16 @@
# One of 'breaking', 'deprecation', 'new_component', 'enhancement', 'bug_fix'
change_type: bug_fix

# The name of the component, or a single word describing the area of concern, (e.g. tempostack, tempomonolithic, github action)
component: tempostack

# A brief description of the change. Surround your text with quotes ("") if it needs to start with a backtick (`).
note: Use the ReadinessProbe to better indicate when tempo-query is ready to accept requests. Improving the startup reliability by avoiding lost data.

# One or more tracking issues related to the change
issues: [1058]

# (Optional) One or more lines of additional information to render under the primary note.
# These lines will be padded with 2 spaces and then inserted directly into the document.
# Use pipe (|) for multiline entries.
subtext: Without a readiness check in place, there is a risk that data will be lost when the queryfrontend pod is ready but the tempo query API is not yet available.
Copy link
Collaborator

Choose a reason for hiding this comment

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

how can be data lost in query frontend? It does not ingest any data? It's used only for querying.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

The queryfrontend with enabled jaeger contains 3 containers in its pod. tempo-query is part of it.

Copy link
Collaborator

Choose a reason for hiding this comment

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

I understand that, the point I am making is that the

data will be lost when the queryfrontend pod

implies to me that this fixes data ingestion, which is not the case

10 changes: 10 additions & 0 deletions internal/manifests/queryfrontend/query_frontend.go
Original file line number Diff line number Diff line change
Expand Up @@ -311,6 +311,16 @@ func deployment(params manifestutils.Params) (*appsv1.Deployment, error) {
},
Resources: tempoQueryResources(tempo),
SecurityContext: manifestutils.TempoContainerSecurityContext(),
ReadinessProbe: &corev1.Probe{
ProbeHandler: corev1.ProbeHandler{
GRPC: &corev1.GRPCAction{
Port: manifestutils.PortTempoGRPCQuery,
},
},
TimeoutSeconds: 1,
PeriodSeconds: 5,
FailureThreshold: 12,
},
}
jaegerQueryVolume := corev1.Volume{
Name: manifestutils.TmpStorageVolumeName + "-query",
Expand Down
10 changes: 10 additions & 0 deletions internal/manifests/queryfrontend/query_frontend_test.go
Original file line number Diff line number Diff line change
Expand Up @@ -289,6 +289,16 @@ func getExpectedDeployment(withJaeger bool) *v1.Deployment {
ReadOnly: true,
},
},
ReadinessProbe: &corev1.Probe{
ProbeHandler: corev1.ProbeHandler{
GRPC: &corev1.GRPCAction{
Port: manifestutils.PortTempoGRPCQuery,
},
},
TimeoutSeconds: 1,
PeriodSeconds: 5,
FailureThreshold: 12,
},
Resources: corev1.ResourceRequirements{
Limits: corev1.ResourceList{
corev1.ResourceCPU: *resource.NewMilliQuantity(45, resource.BinarySI),
Expand Down