Closed breunigs closed 2 years ago
Hi @breunigs,
I've opened #269 to resolve this issue. It should be out later today. If this issue persists, can you open a ticket with support@instana.com
directly? When I've seen this issue come up for other customers, its generally related to something at the agent deployment layer.
Thanks, Hunter
Problem Description
This stack trace:
Tracing unsurprisingly doesn't work when this occurs, since this is not a scenario for which
try_forever_with_backoff
retries.Looking at the agent, it has an error for the pod in question, but also unrelated errors that make the agent itself look quite unhealthy:
10.142.10.146
is the IP of the Kubernetes pod where the initial stack trace is from.The setup for that app is PhusionPassenger on nginx with smart forking, no Instana AutoTrace™, but this manual integration:
INSTANA_AGENT_HOST
gets set through k8s downward API.Other pods with the same setup work fine, only the ones going to the misbehaving agent were experiencing the issue.
I would expect that the sensor retries indefinitely, even if the agent sends garbage. Killing the instana-agent pod made me unable to reproduce the issue so far, but the Ruby app pod would stay broken of course.
Minimal, Complete, Verifiable, Example
Your terms of conditions disallow me from reverse engineering the Instana Host Agent, so I can't provide one. Unfortunately debug logging was not enabled for the ruby-sensor at the time, so I can't tell you what value was set in
discovery
:My best guess is that it was an integer or some such:
Gemfile.lock
Ruby Version