We pushed some 7.1.x in our production environment. Looks like we need to revert that change for our deployment. The documentation doesn't match the behavior anymore and seems like I can't get the origin server without the port. This does impact our anomaly detection and event alarming that we have in place.
I really would like to know the reasoning behind this. Looks like the PR was done based on the fact that psqn was empty but user was not using parent.config. This is good information for troubleshooting. Our CDN hierarchy includes edge caches connected to Mid Caches via forward proxies (We also have Multi-Site Origin configured via proxying as well). shn was "origin hostname", pqsn was "proxy hostname", pqsi was "proxy resolved IP". Steve On Wed, Feb 6, 2019 at 11:43 AM Jeremy Payne <[email protected]> wrote: > re: ATS 7.1.x > > Somewhat related.. I notice that upon polling an upstream server, pqsi > does not log the upstream IP. > pqsn DOES log the upstream FQDN. > If I replace pqsi with 'nhi' then I am able to log upstream IP again. > > > > On Mon, Jan 14, 2019 at 1:51 PM Alan Carroll <[email protected]> > wrote: > > > > One of the issues with this is what exactly was the difference between > `pqsn` and `shn`? Did they different when using parent.config? > > > > On Fri, Jan 11, 2019 at 11:54 AM Steve Malenfant <[email protected]> > wrote: > >> > >> Was doing some testing this morning and noticed that I couldn't find my > traffic by the origin server hostname anymore using our logging system. > While discussing with a few folks, looks like the "shn" field isn't > reporting the origin server hostname under certain circumstances, for > example when used with parent.config. > >> > >> shn now reports the IP address or hostname used in the parent.config, > which is what we used pqsn/pqsi field before. > >> > >> In the pull request https://github.com/apache/trafficserver/pull/3860, > there is a workaround using the client/server host header that can be used. > That header contains also a port. > >> > >> I know we applied the logic of pqsn to shn, but pqsn had a different > meaning than origin server hostname. > >> > >> pqsnThe proxy request server name; the name of the server that > fulfilled the request. > >> > >> The PR says that the psqn logic was proper, although I don't think it > was the case for the definition of shn. > >> > >> shnThe hostname of the origin server. > >> > >> Few things could happen. > >> - Revert back the change > >> - Adjust my logging system (and everybody else maybe) > >> > >> Any explanation that the 5.x/6.x behavior was causing? > >> > >> Thanks, > >> > >> Steve > > > > > > > > -- > > Beware the fisherman who's casting out his line in to a dried up > riverbed. > > Oh don't try to tell him 'cause he won't believe. Throw some bread to > the ducks instead. > > It's easier that way. - Genesis : Duke : VI 25-28 >
