Not DNS connections, but regular connections per downstream service. https://github.com/apache/trafficserver/pull/1609 The HostDB stat also can be dumped into JSON. It could be convenient if you would like to know the exact HostDB cache result for a specific service name.
Leif Hedstrom <zw...@apache.org> 于2019年6月6日周四 下午6:40写道： > > > > On Jun 6, 2019, at 18:57, zzz <z...@apache.org> wrote: > > > > We have been using those pages to monitor Hostdb and connection count > table > > in LI. We found it handy and useful. Not sure what’s the alternative way > to > > do similar things. > > Hmm, you mean dns connections ? Regular connection counts have metrics. > > As for HostDB, if there are metrics you need which are not available, you > ought to add those to the metrics list. > > I find it somewhat odd to use the HTML pages for metrics, so I’m curious > to hear more details on what metrics you actually need, and how we can get > this into the regular metrics instead. > > > > > > There will be no performance impact unless you issue a request. When you > > want to debug, the box is already in some bad state anyway. It’s > definitely > > not something you would request every seconds in prod though. > > Yes that’s not the reason to remove this. It’s a really ugly backdoor with > old code producing HTML. We have removed almost everything else from the > old web UI, this is the last remaining piece. > > — Leif > > > > We do have the special ACL to make it only serve from localhost. > > > >> On Thu, Jun 6, 2019 at 2:34 PM Leif Hedstrom <zw...@apache.org> wrote: > >> > >> Hi all, > >> > >> we have this feature where ATS can server some “static” pages for stats > >> and introspection. I’d like to propose that we remove this feature for > >> v9.0.0, opening up the door for better implementations via the > traffic_ctl > >> reworks. > >> > >> I understand that this would leave us without some of this feature for > the > >> short term. However, I think that’s ok for a number of reasons: > >> > >> 1. It’s mostly a debugging tool (IMO), turning it on in production is > >> risky at best. Several features (such as searching the cache), can kill > the > >> server performance. > >> > >> 2. There are some tools that can do some of what this does, e.g. the > >> traffic_cache_tool, and various metrics and logging, as well as > diagnostics. > >> > >> 3. It’s not particularly secure (there’s no ACLs, other than making > >> obscure URL names). And it’s not particularly easy to setup either :). > >> > >> > >> I’m ok not doing this if there’s at least someone who depends on and > need > >> this feature. I’d expect at a minimum it would still go away in ATS > v10.0.0. > >> > >> And discuss! > >> > >> — Leif > >> > >> > >> > >
