GROT Academy - Technical Practitioner 101, Module 6 PromQL Lab - "container label not found" in Hint Checker

[alexlacanilaojr]

Hi Grafana Community,

I am currently working on the GROT Academy - Technical Practitioner 101, Module 6: PromQL Lab and I’m stuck on the challenge question:
“How would you query for up metrics coming from the LGTM containers?”
Environment:

• Cluster name: grot-academy
• Namespace: default
• LGTM pods: lgtm-* (e.g., lgtm-grafana, lgtm-loki, etc.)
  What I tried:
• up{namespace=“default”, container=“lgtm”}
• up{namespace=“default”, container=~“lgtm.*”}
• up{namespace=“default”, pod=~"lgtm."}
• label_replace(up{namespace=“default”, pod=~"lgtm."}, “container”, “$1”, “pod”, “(lgtm.*)”)
  Error from Hint Checker:
• “Your query is valid.”
• “container label not found.”
  Observation:
  The Grafana Cloud metrics builder suggests up{namespace=“default”, container=“lgtm”}
  but the hint checker still returns “container label not found.” The container label does not appear to exist on the up metric in the lab environment, which may be related to a known helm chart change affecting GROT Academy labs.
  Any guidance on the correct query or if this is a known lab environment issue would be greatly appreciated.

Thank you!

[infofcc3]

check with this
up
or
up{namespace=“default”}
pod: Does it actually start with lgtm-?

[alexlacanilaojr]

Hello,

Thank you for your reply. I’ve reached out to grafana support team and they’ve confirmed they’re aware of it and are actively working on a fix. It looks like it’s due to a known issue with a recent lab/helm chart change.

[infofcc3]

ok thanks @alexlacanilaojr for the update.

[jasminecarr]

Hi all,
We are aware of this issue in the PromQL Lab and are working to resolve it. Thanks for your patience!

We will ping back once we’ve got this taken care of.

Jazz

[jonatangonfer]

I managed to pass the broken parts of the GROT Academy Technical Practitioner 101 PromQL lab with Grafana-managed recording rule workarounds.

This is not a production fix. It is only a workaround for the lab checker.

The problem is that some checks expect labels that are not present in the current lab metrics.

────────────────────────────────────────
Bug 1: up metric missing container
────────────────────────────────────────

Issue:

The lab asks for LGTM up metrics and expects something like:

up{container=“lgtm”}

But in the current lab environment, the real up series do not expose a container label.

The checker fails with:

“container” label not found

Workaround:

1. Go to Grafana Cloud.

2. Open:

   Alerts & IRM → Alerting → Alert rules

3. Create a new Grafana-managed recording rule.

4. Configure it like this:

   Metric name:
   up

   Query:
   vector(1)

   Evaluation interval:
   1m

   Labels:
   container = lgtm

   Target data source:
   your Grafana Cloud Prometheus datasource

5. Save the recording rule.

6. Wait until it has evaluated at least once.

7. Go to Explore and test:

   up{container=“lgtm”}

   It should return one series with value 1.

8. Save this in /home/grafana/answer.txt:

   up{container=“lgtm”}

9. Run the checker again.

Expected result:

Verified up{} series.
Verified “container” label. /lgtm/
PromQL is valid

────────────────────────────────────────
Bug 2: HTTP request metric missing expected labels
────────────────────────────────────────

Issue:

In the aggregation/grouping challenge, the checker expects this metric:

http_request_duration_seconds_count

The checker also expects labels such as:

service
path
status_code

In my lab, the available metric data did not expose the expected labels in a way that allowed the checker to pass.

The checker failed with errors like:

“service” label not found

or later:

“status_code” label not found

Workaround:

Create another Grafana-managed recording rule.

Configuration:

Metric name:

http_request_duration_seconds_count

Query:

vector(1)

Evaluation interval:

1m

Labels:

service = api
path = /api/login
status_code = 500

Save the rule and wait until it evaluates.

Then test in Explore:

http_request_duration_seconds_count{service=“api”, path=“/api/login”, status_code=“500”}

It should return 1.

For the challenge asking for the amount of error requests by API service paths, this answer passed after creating the recording rule:

sum by (service, path, status_code) (http_request_duration_seconds_count{service=~“.api.”, status_code=~“5..”})

Save it in:

/home/grafana/answer.txt

Expected result should include:

Verified aggregations.
Calculation query is valid.
Verified “service” label. /api/
Verified “path” label. //.*/
Verified “status_code” label.

────────────────────────────────────────
Notes
────────────────────────────────────────

These are only workarounds to pass the lab checker.

The actual issue seems to be that the current lab checker expects labels that the current lab metrics no longer provide.