Discussion:
[PROPOSAL] HTTP Metrics Overhaul
Masaori Koshiba
2018-10-16 02:23:30 UTC
Permalink
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
Bryan Call
2018-10-16 17:44:48 UTC
Permalink
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
Post by Masaori Koshiba
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
Susan Hinrichs
2018-10-16 21:25:32 UTC
Permalink
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.
Post by Bryan Call
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
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
Masaori Koshiba
2018-10-17 12:08:39 UTC
Permalink
Post by Bryan Call
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
Post by Bryan Call
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.
Post by Bryan Call
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
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.
Post by Bryan Call
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
Post by Bryan Call
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
Bryan Call
2018-10-17 16:26:48 UTC
Permalink
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
Post by Bryan Call
Post by Bryan Call
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
Post by Bryan Call
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.
Post by Bryan Call
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
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.
Post by Bryan Call
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
Post by Bryan Call
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
Leif Hedstrom
2018-10-17 16:34:10 UTC
Permalink
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}).
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
Post by Bryan Call
Post by Bryan Call
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
Post by Bryan Call
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.
Post by Bryan Call
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
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.
Post by Bryan Call
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
Post by Bryan Call
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
Masakazu Kitajo
2018-10-18 00:59:03 UTC
Permalink
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
Post by Bryan Call
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}).
Post by Bryan Call
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
Post by Bryan Call
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.
Post by Bryan Call
-Bryan
Post by Bryan Call
Post by Bryan Call
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
Post by Bryan Call
Post by Bryan Call
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
Post by Bryan Call
Post by Bryan Call
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
Post by Bryan Call
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
Post by Bryan Call
Post by Bryan Call
Post by Bryan Call
in fact http/1.x specific.
Post by Bryan Call
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
Post by Bryan Call
Post by Bryan Call
Post by Bryan Call
Post by Bryan Call
tied to the scheme. I recommend breaking up TLS and non-TLS metric
and
Post by Bryan Call
Post by Bryan Call
Post by Bryan Call
Post by Bryan Call
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
Post by Bryan Call
Post by Bryan Call
Post by Bryan Call
Post by Bryan Call
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.
Post by Bryan Call
Post by Bryan Call
Post by Bryan Call
Post by Bryan Call
Also, I would be for modernizing the stats and configuration and
calling
Post by Bryan Call
Post by Bryan Call
Post by Bryan Call
Post by Bryan Call
everything tls instead of ssl.
-Bryan
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.
Post by Bryan Call
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
Post by Bryan Call
Post by Bryan Call
Post by Bryan Call
Post by Bryan Call
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
Loading...