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 Sat, 20 Apr 2019 22:55:05 GMT
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 <jp557198@gmail.com> 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 <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