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