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
