-
Notifications
You must be signed in to change notification settings - Fork 3.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
HBASE-25896 Implement a Region Visualization on Master WebUI #4178
Conversation
This PR is on top of #4177 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See comments/questions
Much of this change looks like boilerplate to wire up Gson to Jersey. It seems sane. I do not claim to understand the requirements there in detail.
hbase-http/src/main/java/org/apache/hadoop/hbase/http/gson/ByteArraySerializer.java
Outdated
Show resolved
Hide resolved
import org.apache.hbase.thirdparty.javax.ws.rs.ext.MessageBodyWriter; | ||
|
||
/** | ||
* Implements JSON serialization via {@link Gson} for JAX-RS. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just for my understanding, the ready alternative is JSON serialization via Jackson. (No claim that it is desirable or not.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, I suppose we still have Jackson around. I thought we were making an effort to purge it from our codebase, with Gson being the replacement target. I could be incorrect in that understanding! I am happy to use whichever is the community target. It is quite confusing to have multiple libraries on hand for marshaling JSON.
@@ -689,9 +691,16 @@ protected MasterRpcServices createRpcServices() throws IOException { | |||
@Override | |||
protected void configureInfoServer(InfoServer infoServer) { | |||
infoServer.addUnprivilegedServlet("master-status", "/master-status", MasterStatusServlet.class); | |||
infoServer.addUnprivilegedServlet("api_v1", "/api/v1/*", buildApiV1Servlet()); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is nice, something to build on
.register(GsonSerializationFeature.class) | ||
.register(new MasterFeature(master)) | ||
|
||
// devs: enable TRACING to see how jersey is dispatching to resources. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This could be lifted out to a note in the book.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't expect users to make use of Jersey tracing for this API as I don't expect users to consume this API directly. Hence keeping the information here in the code.
For clarity, this isn't OpenTelemetry tracing, this is tracing of the Jersey internals, how it receives and dispatches the request to an appropriate Resource
instance.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
fb8d724
to
63a849c
Compare
💔 -1 overall
This message was automatically generated. |
💔 -1 overall
This message was automatically generated. |
63a849c
to
91f8a2d
Compare
💔 -1 overall
This message was automatically generated. |
🎊 +1 overall
This message was automatically generated. |
💔 -1 overall
This message was automatically generated. |
This is a demonstration of visualization of regions on the cluster. The visualization is a stacked bar chart showing total storefile size per table per region server, with the x-axis being server names, the y-axis being storfile size, and the bars stacked per table. The visualization is generated entirely on the fly from within the browser, implemented using Vega Lite. So far, Vega appears to handle rendering this visualization for a cluster of over 700 region servers with approximately 300,000 regions. Per [0], include an update to the top-level LICENSE.txt. Also update LICENSE files in all binary distributions (i.e., jars), by way of LICENSE.vm. Vega uses a BSD 3-clause variant without advertising clause, and as such is a "Category A" license, per [1]. No changes are made to the NOTICE files, as per the existing example of bundling the minified JQuery, which is also a Category A license. [0]: https://infra.apache.org/licensing-howto.html [1]: https://www.apache.org/legal/resolved.html#category-a Signed-off-by: Andrew Purtell <apurtell@apache.org>
91f8a2d
to
4ea9449
Compare
Rebased and addressed checkstyle and whitespace issues. |
This is a demonstration of visualization of regions on the cluster. The visualization is a stacked
bar chart showing total storefile size per table per region server, with the x-axis being server
names, the y-axis being storfile size, and the bars stacked per table. The visualization is
generated entirely on the fly from within the browser, implemented using Vega Lite. So far, Vega
appears to handle rendering this visualization for a cluster of over 700 region servers with
approximately 300,000 regions.
Per 0, include an update to the top-level LICENSE.txt. Also update LICENSE files in all binary
distributions (i.e., jars), by way of LICENSE.vm. Vega uses a BSD 3-clause variant without
advertising clause, and as such is a "Category A" license, per 1.
No changes are made to the NOTICE files, as per the existing example of bundling the minified
JQuery, which is also a Category A license.