Yes, that works only if you are doing standard remapping. If you use parent.config in forward proxy mode, it doesn't work.
I believe the change made might have broken logging for forward proxy. On Tue, Apr 16, 2019 at 10:32 AM Jeremy Payne <[email protected]> wrote: > hmm.. just tested again, whenever ATS(7.1.4/5) polls an upstream > server(parent or origin), i see an IP in the 'nhi' field. > for a cache hit, results in a '-' entry. > > jeremy > > On Tue, Apr 16, 2019 at 8:04 AM Steve Malenfant <[email protected]> > wrote: > > > > I tried the change a few things here although can't get to same values > as before. > > > > I had to change from the following: > > shn=%<shh> pqsn=%<pqsn> pqsi=%<pqsi> > > > > To (as suggested): > > shn=%<{Host}cqh> pqsn=%<shn> pqsi=%<nhi> > > > > nhi doesn't return anything, shn returns an IP. > > > > Parent.config on our "edge" caches looks like: > > dest_domain=<domain> parent="10.10.10.1:80|0.999; 10.10.10.2 > :80|0.999;68.1.14.152:80|0.999;" secondary_parent=" 10.10.11.1 > :80|0.999; 10.10.10.2:80|0.999;" round_robin=consistent_hash > go_direct=false qstring=ignore > > > > This change definitively removed/changed the pqsn/pqsi/shn logic that > was there before when parent.config is in use. > > > > Steve > > > > > > On Tue, Apr 16, 2019 at 8:44 AM Jeremy Payne <[email protected]> wrote: > >> > >> 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 >
