[tempo-distributed] drop jaeger-ui related ports and config completely #3963
Conversation
…o-query only if enabled Currently the service monitor is added regardless of whether the old jaeger mode is enabled or not. Similar to the ports on the deployment and service, we only include the servicemonitor if `queryFrontend.query.enabled=true`. Additionally, the selector of the service monitor does not work anyway, because the service that includes the old ports has a different `app.kubernetes.io/component` label than the one created from the servicemonitor template Signed-off-by: Alexander Bartolomey <github@alexanderbartolomey.de>
1. remove servicemonitor. tempo-query is now only a gRPC proxy for jaeger. There's not metrics, and no UI anymore 2. remove jaeger metrics and ui ports from service. They plainly dont exist anymore. the ports are also not what the server expects, there's a single server running on default 7777 3. use correct config file for tempo-query, the executable loads the wrong config file Signed-off-by: Alexander Bartolomey <github@alexanderbartolomey.de>
The port was still pointing to a jaeger-related HTTP port, this is gone since grafana/tempo#3840 so don't use it anymore HTTP ingress is no longer for connecting to jaeger UI, but can instead be used for e.g. grafana data sources access via ingress Signed-off-by: Alexander Bartolomey <github@alexanderbartolomey.de>
zoomoid
requested review from
a team,
BitProcessor,
QuentinBisson,
Sheikh-Abubaker,
faustodavid and
swartz-k
as code owners
zoomoid
changed the title
Signed-off-by: Alexander Bartolomey <github@alexanderbartolomey.de>
| @@ -1,4 +1,4 @@ | |||
| {{- if and .Values.queryFrontend.query.enabled .Values.queryFrontend.ingress.enabled -}} | |||
| {{- if .Values.queryFrontend.ingress.enabled -}} | |||
There was a problem hiding this comment.
Is there any reason to change this?
There was a problem hiding this comment.
the tempo-query service evolved to be gRPC-only, and I see very little use in having an HTTP ingress for a gRPC service the way it currently is set up.
However, similar to the remark below, I might be work considering if the ingress needs to be kept in its entirety, I think the original idea went along the same lines of setting the queryFrontend.service.port to the HTTP metrics port, because that was the last remaining (somewhat sensible) HTTP endpoint to use for this entire service.
The extra predicate in the conditional can of course remain, but since the ingress is fully customizable with respect to host, path and so forth, technically you don't have to use it for the tempo-query service alone and could also use it to expose the 3200 metrics endpoint of query-frontend (whatever might be the reason to do this).
Also, if the ingress used to just be for tempo-query, why not put its configuration in the values under queryFrontend.query?
charts/tempo-distributed/values.yaml
Outdated
| service: | ||
| # -- Port of the query-frontend service | ||
| port: 16686 | ||
| port: 3200 |
There was a problem hiding this comment.
Should it not be 7777?
There was a problem hiding this comment.
If it should, can you use this value in the templates instead to avoid magic numbers?
There was a problem hiding this comment.
okay, so getting back to this, the service.port properties are nested under queryFrontend, which has the static 3200 port for (i guess) just metrics via HTTP. The property's description also refers to query-frontend, not tempo-query, so this whole field seems a bit misplaced. I don't know if it's actually needed for something, but if it should just rectify the broken old port to the new (gRPC) port of tempo-query, we can set it to 7777 in the values and use that value in the template, sure.
However I think the confusion I had here is really indicative of drift of the upstream tempo-query service and the helm chart's use of it.
For now, I'll set this to 7777 and carry that to the service template.
Signed-off-by: Alexander Bartolomey <github@alexanderbartolomey.de>
2 participants
This no longer works, grafana/tempo#3840 removed jaeger from tempo-query, changing with it the port that the server running in the container listens to:
7777of tempo-query. Note that the container port isn't configurable right now. If you opt to setADDRESSviaqueryFrontend.query.extraEnvsto something different, you cannot access the server anymore from outside the pod.queryFrontendIngress. This no longer works for accessing Jaeger UI. Instead, you can repurpose the ingress, e.g. for configuring Grafana data sourcestempo-querydoesn't export any metrics, there's nothing to scrape there, so this can be dropped completely in favour of the already existing service monitor for query-frontend's HTTP portmost of these changes probably also need to be reflected in the non-distributed charts as well, but I'm awaiting feedback here first.