Azure / azure-sdk-for-java

This repository is for active development of the Azure SDK for Java. For consumers of the SDK we recommend visiting our public developer docs at https://docs.microsoft.com/java/azure/ or our versioned developer docs at https://azure.github.io/azure-sdk-for-java.
MIT License
2.26k stars 1.94k forks source link

[FEATURE REQ] Blob Storage Metrics #17339

Closed dloplopez closed 4 months ago

dloplopez commented 3 years ago

Is your feature request related to a problem? Please describe. We need to access the metrics of all requests made against Blob Storage for upload, download, and delete files in a Blob. Without getting these metrics from the Azure Metrics API Rest.

Describe the solution you'd like All the requests should have a way to access the metrics like request state, response time, etc…

Describe alternatives you've considered ...

Additional context ...

Information Checklist Kindly make sure that you have added all the following information above and checkoff the required fields otherwise we will treat the issuer as an incomplete report

rickle-msft commented 3 years ago

@dloplopez Thank you for opening this issue. Can you please clarify a bit more? If you turn on metrics, you should be able to access that information by reading the $logs container that is created in your storage account. Is this what you are looking for? Or are you asking that metrics information be included in something like a header on the response of each request?

dloplopez commented 3 years ago

Thanks @rickle-msft for your prompt answer. We need some metrics on the application side for monitoring purposes. For example, we'll need to know how much time is take to upload each file or error responses from the Azure API. Ideally, these metrics would be available via JMX so we can easily use them in our monitoring system.

rickle-msft commented 3 years ago

@dloplopez We don't have anything that supports JMK, but this might be close to what you're looking for: https://docs.microsoft.com/en-us/azure/storage/common/storage-analytics?toc=/azure/storage/blobs/toc.json

antonmry commented 3 years ago

I was taking a look to storage-analytics but it seems in the Azure side. We would like to have metrics in the client side, I mean exposed in the application using the SDK to upload files which it's running on-prem and using an on-prem monitoring system.

We can create these metrics (upload times, errors, etc) ourselves as application metrics but it would be handy if it's provided by the SDK directly with JMX and/or as Java API (similar to the Kafka producer and other popular libraries http://kafka.apache.org/22/javadoc/org/apache/kafka/clients/producer/KafkaProducer.html#metrics-- )

rickle-msft commented 3 years ago

I see. Thank you for the extra details. This seems like a larger ask, so we'll likely have to take some time to discuss if it is a feature we will add and plan for it.

@alzimmermsft FYI

rickle-msft commented 3 years ago

One of the libraries we use internally has this option to enable metrics. It mentions that it will light up if there is an instrumentation facade on the classpath. I don't know much about JMX or that ecosystem. Does the instrumentation facade mention in that javadoc sound like it would apply to those tools?

antonmry commented 3 years ago

Yes, I think that's a way to implement it. Reactor uses Micrometer which it's like sl4j but for metrics, IMHO it's a good option for the Azure SDK but I don't know how complex would be to generate some metrics (for example, how long a request to the Azure API takes) using Reactor

rickle-msft commented 3 years ago

@antonmry Thank you for that information. It helps us move this conversation forward. We're still discussing internally.

davidmestr commented 1 year ago

Hi! Some new about this?

github-actions[bot] commented 4 months ago

Hi @dloplopez, we deeply appreciate your input into this project. Regrettably, this issue has remained inactive for over 2 years, leading us to the decision to close it. We've implemented this policy to maintain the relevance of our issue queue and facilitate easier navigation for new contributors. If you still believe this topic requires attention, please feel free to create a new issue, referencing this one. Thank you for your understanding and ongoing support.