trafficserver-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Payne <jp557...@gmail.com>
Subject Re: Change in shn response (logging)
Date Tue, 16 Apr 2019 14:32:37 GMT
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 <smalenfant@gmail.com> 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 <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