xds: error descriptions #8554
xds: error descriptions #8554
Conversation
YifeiZhuang
commented
Sep 23, 2021
•
YifeiZhuang
commented
- audited existing error messages in xds name resolver, xds lbs, xdsServerWrapper and made changes to add more error description verbosely. However, we should discuss how much error details of internal processing logics we should expose to messages visible to customers, e.g.
- what is the immediately/root cause of the error: what components, what config is missing, what is invalid, what is expected, or unknown errors?
- hint what is the possible action to fix the error?
- added more debug logs in xds server
There was a problem hiding this comment.
This seems about the right level of verbosity. We want to give the essential context without drowning the user in data. Generally, we should say what is broken and not try to assume how it became broken. That also means generally not suggesting how to fix the error (but there are sometimes special cases to that).
On server-side we'll need to use more logs than status codes, since we shouldn't be sharing too much information with the client.
| @@ -281,6 +281,9 @@ public void userEventTriggered(ChannelHandlerContext ctx, Object evt) throws Exc | |||
| SslContextProviderSupplier sslContextProviderSupplier = InternalProtocolNegotiationEvent | |||
| .getAttributes(pne).get(ATTR_SERVER_SSL_CONTEXT_PROVIDER_SUPPLIER); | |||
| if (sslContextProviderSupplier == null) { | |||
| logger.log(Level.INFO, "No sslContextProviderSupplier found in filterChainMatch " | |||
There was a problem hiding this comment.
This may be normal. INFO is logged by default, and we don't want to log by default when nothing is wrong. Use FINE level?
Ugh. Looks like the "Using fallback" log also needs fixing.
There was a problem hiding this comment.
And when fallback exists I think it will be nice to have a single message that includes "no ... found and using fallback for ...".
Also do we need to print out variable names like sslContextProviderSupplier or can we just say no filter-matched for connection ..."?
There was a problem hiding this comment.
It's not an error, so no log. Everything is working as expected. We also have to be careful on server-side not to log too frequently; if every connection fails the same way it can produce a lot of logs very quickly.
The sslContextProviderSupplier is used by the xds creds themselves when the control plane has security configured. But the fallback credentials don't use such a supplier and may not even be using TLS. Language tweak following grpc#8554.
The sslContextProviderSupplier is used by the xds creds themselves when the control plane has security configured. But the fallback credentials don't use such a supplier and may not even be using TLS. Language tweak following #8554.
