You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@trafficserver.apache.org by Masaori Koshiba <ma...@apache.org> on 2018/10/16 02:23:30 UTC
[PROPOSAL] HTTP Metrics Overhaul
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
Re: [PROPOSAL] HTTP Metrics Overhaul
Posted by Masakazu Kitajo <ma...@apache.org>.
> 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.
Yah, and QUIC would have some versions (some features are already pushed
out from the first version). This brings up one more question; Should we
also think about TLS versions since all other protocol fields contain
versions?
Also, if we prefer small peaces, it may make more sense to split
"total_client_connections" into "{client, server}.{connections,
transactions}.{total, current}".
Masakazu
On Thu, Oct 18, 2018 at 1:34 AM Leif Hedstrom <zw...@apache.org> wrote:
>
>
> > 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 <ma...@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 <sh...@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 <ma...@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
> >>>>
> >>>>
> >>>>
> >>>
> >
>
>
Re: [PROPOSAL] HTTP Metrics Overhaul
Posted by Masakazu Kitajo <ma...@apache.org>.
> 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.
Yah, and QUIC would have some versions (some features are already pushed
out from the first version). This brings up one more question; Should we
also think about TLS versions since all other protocol fields contain
versions?
Also, if we prefer small peaces, it may make more sense to split
"total_client_connections" into "{client, server}.{connections,
transactions}.{total, current}".
Masakazu
On Thu, Oct 18, 2018 at 1:34 AM Leif Hedstrom <zw...@apache.org> wrote:
>
>
> > 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 <ma...@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 <sh...@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 <ma...@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
> >>>>
> >>>>
> >>>>
> >>>
> >
>
>
Re: [PROPOSAL] HTTP Metrics Overhaul
Posted by Leif Hedstrom <zw...@apache.org>.
> 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 <ma...@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 <sh...@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 <ma...@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
>>>>
>>>>
>>>>
>>>
>
Re: [PROPOSAL] HTTP Metrics Overhaul
Posted by Leif Hedstrom <zw...@apache.org>.
> 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 <ma...@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 <sh...@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 <ma...@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
>>>>
>>>>
>>>>
>>>
>
Re: [PROPOSAL] HTTP Metrics Overhaul
Posted by Bryan Call <bc...@apache.org>.
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 <ma...@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 <sh...@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 <ma...@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
>>>
>>>
>>>
>>
Re: [PROPOSAL] HTTP Metrics Overhaul
Posted by Bryan Call <bc...@apache.org>.
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 <ma...@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 <sh...@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 <ma...@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
>>>
>>>
>>>
>>
Re: [PROPOSAL] HTTP Metrics Overhaul
Posted by Masaori Koshiba <ma...@apache.org>.
> 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 <sh...@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 <ma...@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
> >
> >
> >
>
Re: [PROPOSAL] HTTP Metrics Overhaul
Posted by Masaori Koshiba <ma...@apache.org>.
> 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 <sh...@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 <ma...@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
> >
> >
> >
>
Re: [PROPOSAL] HTTP Metrics Overhaul
Posted by Susan Hinrichs <sh...@oath.com>.
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 <ma...@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
>
>
>
Re: [PROPOSAL] HTTP Metrics Overhaul
Posted by Susan Hinrichs <sh...@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 <ma...@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
>
>
>
Re: [PROPOSAL] HTTP Metrics Overhaul
Posted by Bryan Call <bc...@apache.org>.
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 <ma...@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://github.com/apache/trafficserver/issues/4415>
> - https://docs.google.com/spreadsheets/d/1zux3OPiDNJlWALluhr8ciKypg_sYVxbG9fdmeuDD-Bo/edit?usp=sharing <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
Re: [PROPOSAL] HTTP Metrics Overhaul
Posted by Bryan Call <bc...@apache.org>.
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 <ma...@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://github.com/apache/trafficserver/issues/4415>
> - https://docs.google.com/spreadsheets/d/1zux3OPiDNJlWALluhr8ciKypg_sYVxbG9fdmeuDD-Bo/edit?usp=sharing <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