> On Oct 17, 2018, at 10:26 AM, Bryan Call <bc...@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 <masa...@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 <shinr...@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 <bc...@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 <masa...@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
>>>>
>>>>
>>>>
>>>
>
