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
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
>>>
>>>
>>>
>>
