run_8fa5d4f29a090ef2

input

{
  "request": "Triage Jira ticket SREIN-1702: SEIO dashboards in Yardstick not loading",
  "references": [
    "https://mozilla-hub.atlassian.net/browse/SREIN-1702"
  ],
  "sourceContext": {
    "issue": "SREIN-1702"
  }
}

summary

SREIN-1702 reports that SEIO dashboards hosted in Yardstick are failing to load because Yardstick times out when fetching data from the reporter's InfluxDB data source. The reporter has an IP allowlist on their firewall for Yardstick's egress traffic; they added Yardstick's current external IP (34.160.71.72) but the timeout persists, suggesting either (a) Yardstick uses multiple/rotating egress IPs not fully covered by the allowlist, (b) the timeout has a different root cause unrelated to IP allowlisting (e.g. DNS, TLS, InfluxDB service health, or network path issues), or (c) additional firewall/network configuration (ports, protocols) is needed beyond just the IP. The ticket has no comments and is unassigned/in Backlog, so it needs owner assignment and technical diagnosis by someone with visibility into Yardstick's networking/egress configuration.

findings

• Ticket describes a data-source timeout: SEIO dashboards in Yardstick can't reach the reporter's InfluxDB instance.
• Reporter maintains an IP allowlist on their firewall for Yardstick egress traffic and updated it with what they believe is Yardstick's current external IP (34.160.71.72), but the issue persists.
• Reporter is explicitly asking whether there are other egress IPs (or IP ranges) for Yardstick that need to be allowlisted — this is an open question that needs an answer from someone owning Yardstick's infra/networking.
• Ticket has zero comments and sits in Backlog status, indicating no triage/ownership has occurred yet; no linked runbook or Confluence doc was provided/found for Yardstick egress IPs.
• If Yardstick runs on GCP (external IP format 34.160.71.72 looks like a GCP address, possibly a Cloud Run/Load Balancer/NAT IP), egress IPs may not be static per-instance and could rotate or use a range (e.g., Cloud NAT IP pool) rather than a single fixed IP, which would explain why allowlisting one IP didn't resolve the timeout.

proposed actions

Thanks for the report! To help diagnose this timeout, a few questions/next steps:

1. Egress IPs: Depending on how Yardstick is deployed (e.g., GCP Cloud Run/GKE behind Cloud NAT), its egress IP may not be a single static address — it could rotate within a NAT IP pool or use multiple addresses across regions/instances. Could you confirm which Yardstick component/service is fetching your InfluxDB data (grafana proxy, backend job, etc.), and check with the Yardstick platform/infra owners for the full list or CIDR range of egress IPs used by that service, rather than a single IP?
2. Beyond IP allowlisting, please double check: (a) the firewall rule allows the correct port/protocol for InfluxDB (e.g., 8086/HTTPS), (b) there's no TLS/cert issue, and (c) DNS resolution for your InfluxDB hostname is correct and stable from Yardstick's network.
3. Can you share the exact timeout error/message from the dashboard and roughly when it started (any recent change on your InfluxDB side, e.g., new firewall, IP change, or maintenance)?
4. Assigning to the Yardstick/SRE-Infra on-call or component owner to confirm current egress IP ranges/NAT config for Yardstick and to check platform-side logs for the failed connection attempts.

Moving this out of Backlog once we have an owner confirmed.

tool calls

[
  {
    "capability": "jira.issue.read",
    "args": {
      "key": "SREIN-1702"
    },
    "result": {
      "key": "SREIN-1702",
      "summary": "SEIO dashboards in Yardstick not loading",
      "status": "Backlog",
      "description_text": "Heya, I noticed that the SEIO dashboards aren\u2019t loading the other day. It looks like it\u2019s timing-out fetching the data source (our influxdb instance). I used to have a handful of IPs allowed but when I did a quick lookup for Yardstick the other day I saw that its current external IP is not in that list (34.160.71.72). I updated the list to include this new IP, but still no luck. Are there other potential egress IPs I should allow through the firewall for this? Thanks!",
      "comment_count": 0,
      "comments": []
    }
  }
]

log