Doesnt answer your question as to why the change and documentation discrepancy. But in testing I noticed nhi is now the field to use to log the upstream ip
On Tue, Apr 16, 2019, 7:29 AM Steve Malenfant <[email protected]> wrote: > 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 >> >
