trafficserver-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leif Hedstrom <zw...@apache.org>
Subject Re: [PROPOSAL] HTTP Metrics Overhaul
Date Wed, 17 Oct 2018 16:34:10 GMT


> On Oct 17, 2018, at 10:26 AM, Bryan Call <bcall@apache.org> wrote:
> 
> I didn’t think about ipv4 and ipv6.  If we want to break out all the stats so you can
figure out any combination we would need to have a stat hierarchy such as: proxy.transport.process.encryption.http_version.scheme
(e.g. proxy.process.{ipv4,ipv6}.{tls,non-tls}.{http1,http2}.{http,https}).
> 
> The current client connection stats would be:
> 
> proxy.process.ipv4.non-tls.http1.total_client_connections
> proxy.process.ipv6.non-tls.http1.total_client_connections
> proxy.process.ipv4.tls.http1.total_client_connections
> proxy.process.ipv6.tls.http1.total_client_connections
> proxy.process.ipv4.tls.http2.total_client_connections
> proxy.process.ipv6.tls.http2.total_client_connections


Yeh.

If we are going to make these changes (which I think we should), maybe we need to have a little
“working group” discussions, such that we get a new, consistent hierarchy here. Also don’t
forget that QUIC will have to get into the mix here, and long term, both H2 and QUIC on the
outbound connections.

I think (amc?) that mirroring the protocol stack hierarchy that we did for other APIs a while
back would work well on the metrics too? I think the above is inline with that as well?

Cheers,

— Leif

> 
> You can figure out any combination, such as all ipv4 requests that are encrypted.  However,
this might be too much for a normal user to understand.
> 
> -Bryan
> 
> 
> 
>> On Oct 17, 2018, at 5:08 AM, Masaori Koshiba <masaori@apache.org> wrote:
>> 
>>> The proxy.process.https stats (only 2 stats) should also be considered
>> when overhauling the stats.  They are really TLS or non-TLS stats and not
>> tied to the scheme. I recommend breaking up TLS and non-TLS metric and
>> calling them proxy.process.ssl. and proxy.process.non-ssl.
>> 
>> Good point. I didn't cover them.
>> 
>> Do you mean breaking every `proxy.process.{http,http1,http2}.*` metrics
>> into `proxy.process.ssl.{http,http1,http2}.*` and
>> `proxy.process.non-ssl.{http,http1}.*` ?
>> 
>> If we add `encryption`, why don't we add all transport protocols? I’d like
>> to avoid exposing underlying protocols on every metrics.
>> It looks like we're interested in underlying protocol stack on *some*
>> metrics but not on all. Also I'd like to minimize incompatible changes.
>> 
>> # As for `proxy.process.https.total_client_connections`
>> 
>> This is a counter for "HTTP/1.1 over TLS". We have similar metrics.
>> ```
>> proxy.process.http.total_client_connections
>> proxy.process.http.total_client_connections_ipv4
>> proxy.process.http.total_client_connections_ipv6
>> ```
>> 
>> All of them are HTTP/1.1 specific, so how about this changes?
>> 
>> ```
>> proxy.process.http1.total_client_connections
>> proxy.process.http1.total_client_connections.ipv4
>> proxy.process.http1.total_client_connections.ipv6
>> proxy.process.http1.total_client_connections.tls
>> ```
>> 
>> I agree it's bit weird, but if someone want to break them up more, he or
>> she can do that add the protocol stack at the last later.
>> 
>> ```
>> proxy.process.http1.total_client_connections.ipv4
>> proxy.process.http1.total_client_connections.ipv4_tls
>> proxy.process.http1.total_client_connections.ipv6
>> proxy.process.http1.total_client_connections.ipv6_tls
>> ```
>> 
>> # As for `proxy.process.https.incoming_requests`
>> 
>> This is a count for HTTP request over TLS (regardless HTTP version).
>> And non-encrypted version is `proxy.process.http.incoming_requests`
>> 
>> To follow above changes, I suggest
>> 
>> ```
>> proxy.process.http.incoming_requests
>> proxy.process.http.incoming_requests.tls
>> ```
>> 
>> Thanks,
>> Masaori
>> 
>> 2018年10月17日(水) 6:25 Susan Hinrichs <shinrich@oath.com.invalid>:
>> 
>>> I completely agree with the stats re-normalizing.  I've been messed up
>>> multiple times by assuming that a http metric covers both protocols but was
>>> in fact http/1.x specific.
>>> 
>>> On Tue, Oct 16, 2018 at 12:44 PM Bryan Call <bcall@apache.org> wrote:
>>> 
>>>> The proxy.process.https stats (only 2 stats) should also be considered
>>>> when overhauling the stats.  They are really TLS or non-TLS stats and not
>>>> tied to the scheme.  I recommend breaking up TLS and non-TLS metric and
>>>> calling them proxy.process.ssl. and proxy.process.non-ssl.
>>>> 
>>>> Another option to build a hierarchy of stats and have it be
>>>> proxy.process.encryption.http_version.scheme (e.g.
>>>> proxy.process.{ssl,non-ssl}.{http1,http2}.{http,https}). Where scheme I
>>>> don’t see being used very much or at all, so it would only be mainly
>>>> encryption and http_version.  For http2 encryption would always be ssl.
>>>> 
>>>> Also, I would be for modernizing the stats and configuration and calling
>>>> everything tls instead of ssl.
>>>> 
>>>> -Bryan
>>>> 
>>>> 
>>>> 
>>>> On Oct 15, 2018, at 7:23 PM, Masaori Koshiba <masaori@apache.org> wrote:
>>>> 
>>>> Hi all,
>>>> 
>>>> I’d like to propose some HTTP metrics changes. Because current HTTP
>>>> metrics doesn’t have consistent naming rules.
>>>> 
>>>> ----
>>>> 1. Define `proxy.process.http.*` is HTTP version general metrics.
>>>> 2. Introduce `proxy.process.http1.*` metrics for HTTP/1.1 specific
>>> metrics.
>>>> 3. Split general metric into version specific metrics if needed.
>>>> ----
>>>> 
>>>> More details are in
>>>> - https://github.com/apache/trafficserver/issues/4415
>>>> -
>>>> 
>>> https://docs.google.com/spreadsheets/d/1zux3OPiDNJlWALluhr8ciKypg_sYVxbG9fdmeuDD-Bo/edit?usp=sharing
>>>> 
>>>> My proposal has incompatible changes. And it requires some actions to
>>>> people who is tracking these metrics.
>>>> Please comment on the issue or this thread if you have any opinions.
>>>> 
>>>> My current target of these incompatible changes are next major release
>>>> (9.0.0).
>>>> 
>>>> Thanks,
>>>> Masaori
>>>> 
>>>> 
>>>> 
>>> 
> 


Mime
View raw message