trafficserver-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Malenfant <smalenf...@gmail.com>
Subject Re: Change in shn response (logging)
Date Tue, 16 Apr 2019 13:04:03 GMT
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 <jp557198@gmail.com> 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 <smalenfant@gmail.com>
> 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 <jp557198@gmail.com> 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 <solidwallofcode@oath.com>
>>> 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 <smalenfant@gmail.com>
>>> 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
>>>
>>

Mime
View raw message