[jira] [Commented] (RANGER-4047) Ranger KMS health metrics
[
https://issues.apache.org/jira/browse/RANGER-4047?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17717240#comment-17717240
]
Dhaval Shah commented on RANGER-4047:
-
Push the change is apache master branch :
https://github.com/apache/ranger/commit/db97c44fa928a387e90dad48affd82b50bd53b5b
> Ranger KMS health metrics
> --
>
> Key: RANGER-4047
> URL: https://issues.apache.org/jira/browse/RANGER-4047
> Project: Ranger
> Issue Type: New Feature
> Components: kms
>Reporter: Vikas Kumar
>Assignee: Vikas Kumar
>Priority: Major
> Attachments: Apache KMS metrics.xlsx
>
>
> Ranger KMS should collect the important System as well as application level
> health metrics.
> System metrics: JVM/CPU/memory related metrics
> Application metrics: KMS API execution metrics. Like, number of time DECRYPT
> operation invoked and time taken to complete the request etc.
> There should also be API to consume these stats, preferably REST API. Any
> metric tools should be able to get these metrics through that REST API.
> This will help making KMS highly observable. Alerts system can be configured
> to consume, process and generate alerts.
> There could be many other use cases.
> *Approach:*
> The solution depends on "ranger-metrics" common module for both Json and
> Prometheus sink.
> Kms has added only KMS specific application metrics. Generally, one COUNT
> metric and corresponding elapsed time gauge metric for each REST end points.
> By default, metric collection is not thread-safe but the by adding following
> property in kms-site.xml it can be made thread-safe:
> Prop name: hadoop.kms.metric.collection.threadsafe=true. // possible values
> true/false
>
> ===Sample response to list down metrics collected
> curl -ivk -H "Content-Type: application/json" -H -X GET
> [http://localhost:9292/kms/metrics/json?user.name=vikas]
> sample response:
> {
> "KMS": {
> "GET_CURRENT_KEY_COUNT": 0,
> "DELETE_KEY_ELAPSED_TIME": 0,
> "EEK_DECRYPT_ELAPSED_TIME": 0,
> "GET_KEYS_METADATA_ELAPSED_TIME": 0,
> "EEK_GENERATE_ELAPSED_TIME": 0,
> "GET_CURRENT_KEY_ELAPSED_TIME": 0,
> "EEK_REENCRYPT_ELAPSED_TIME": 0,
> "KEY_CREATE_COUNT": 1,
> "UNAUTHORIZED_CALLS_COUNT": 0,
> "KEY_CREATE_ELAPSED_TIME": 81,
> "GET_KEY_VERSION_COUNT": 0,
> "ROLL_NEW_VERSION_ELAPSED_TIME": 0,
> "REENCRYPT_EEK_BATCH_COUNT": 0,
> "REENCRYPT_EEK_BATCH_ELAPSED_TIME": 0,
> "GET_KEYS_METADATA_COUNT": 0,
> "GET_KEY_VERSIONS_COUNT": 0,
> "GET_KEY_VERSIONS_ELAPSED_TIME": 0,
> "GET_KEYS_COUNT": 2,
> "EEK_GENERATE_COUNT": 0,
> "INVALIDATE_CACHE_COUNT": 0,
> "GET_METADATA_COUNT": 3,
> "REENCRYPT_EEK_BATCH_KEYS_COUNT": 0,
> "EEK_REENCRYPT_COUNT": 0,
> "UNAUTHENTICATED_CALLS_COUNT": 0,
> "GET_KEY_VERSION_ELAPSED_TIME": 0,
> "INVALIDATE_CACHE_ELAPSED_TIME": 0,
> "ROLL_NEW_VERSION_COUNT": 0,
> "EEK_DECRYPT_COUNT": 0,
> "GET_KEYS_METADATA_KEYNAMES_COUNT": 0,
> "DELETE_KEY_COUNT": 0,
> "GET_KEYS_ELAPSED_TIME": 72,
> "GET_METADATA_ELAPSED_TIME": 14,
> "TOTAL_CALL_COUNT": 7
> },
> "RangerJvm": {
> "GcTimeTotal": 339,
> "SystemLoadAvg": 1.47,
> "ThreadsBusy": 5,
> "GcCountTotal": 9,
> "MemoryMax": 1005584384,
> "MemoryCurrent": 221646760,
> "ThreadsWaiting": 20,
> "ProcessorsAvailable": 2,
> "GcTimeMax": 339,
> "ThreadsBlocked": 0,
> "ThreadsRemaining": 9
> }
> }
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (RANGER-4047) Ranger KMS health metrics
[
https://issues.apache.org/jira/browse/RANGER-4047?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17714629#comment-17714629
]
Bhavik Patel commented on RANGER-4047:
--
Yes, I also spent sometime on it and found the same.
> Ranger KMS health metrics
> --
>
> Key: RANGER-4047
> URL: https://issues.apache.org/jira/browse/RANGER-4047
> Project: Ranger
> Issue Type: New Feature
> Components: kms
>Reporter: Vikas Kumar
>Assignee: Vikas Kumar
>Priority: Major
> Attachments: Apache KMS metrics.xlsx
>
>
> Ranger KMS should collect the important System as well as application level
> health metrics.
> System metrics: JVM/CPU/memory related metrics
> Application metrics: KMS API execution metrics. Like, number of time DECRYPT
> operation invoked and time taken to complete the request etc.
> There should also be API to consume these stats, preferably REST API. Any
> metric tools should be able to get these metrics through that REST API.
> This will help making KMS highly observable. Alerts system can be configured
> to consume, process and generate alerts.
> There could be many other use cases.
> *Approach:*
> The solution depends on "ranger-metrics" common module for both Json and
> Prometheus sink.
> Kms has added only KMS specific application metrics. Generally, one COUNT
> metric and corresponding elapsed time gauge metric for each REST end points.
> By default, metric collection is not thread-safe but the by adding following
> property in kms-site.xml it can be made thread-safe:
> Prop name: hadoop.kms.metric.collection.threadsafe=true. // possible values
> true/false
>
> ===Sample response to list down metrics collected
> curl -ivk -H "Content-Type: application/json" -H -X GET
> [http://localhost:9292/kms/metrics/json?user.name=vikas]
> sample response:
> {
> "KMS": {
> "GET_CURRENT_KEY_COUNT": 0,
> "DELETE_KEY_ELAPSED_TIME": 0,
> "EEK_DECRYPT_ELAPSED_TIME": 0,
> "GET_KEYS_METADATA_ELAPSED_TIME": 0,
> "EEK_GENERATE_ELAPSED_TIME": 0,
> "GET_CURRENT_KEY_ELAPSED_TIME": 0,
> "EEK_REENCRYPT_ELAPSED_TIME": 0,
> "KEY_CREATE_COUNT": 1,
> "UNAUTHORIZED_CALLS_COUNT": 0,
> "KEY_CREATE_ELAPSED_TIME": 81,
> "GET_KEY_VERSION_COUNT": 0,
> "ROLL_NEW_VERSION_ELAPSED_TIME": 0,
> "REENCRYPT_EEK_BATCH_COUNT": 0,
> "REENCRYPT_EEK_BATCH_ELAPSED_TIME": 0,
> "GET_KEYS_METADATA_COUNT": 0,
> "GET_KEY_VERSIONS_COUNT": 0,
> "GET_KEY_VERSIONS_ELAPSED_TIME": 0,
> "GET_KEYS_COUNT": 2,
> "EEK_GENERATE_COUNT": 0,
> "INVALIDATE_CACHE_COUNT": 0,
> "GET_METADATA_COUNT": 3,
> "REENCRYPT_EEK_BATCH_KEYS_COUNT": 0,
> "EEK_REENCRYPT_COUNT": 0,
> "UNAUTHENTICATED_CALLS_COUNT": 0,
> "GET_KEY_VERSION_ELAPSED_TIME": 0,
> "INVALIDATE_CACHE_ELAPSED_TIME": 0,
> "ROLL_NEW_VERSION_COUNT": 0,
> "EEK_DECRYPT_COUNT": 0,
> "GET_KEYS_METADATA_KEYNAMES_COUNT": 0,
> "DELETE_KEY_COUNT": 0,
> "GET_KEYS_ELAPSED_TIME": 72,
> "GET_METADATA_ELAPSED_TIME": 14,
> "TOTAL_CALL_COUNT": 7
> },
> "RangerJvm": {
> "GcTimeTotal": 339,
> "SystemLoadAvg": 1.47,
> "ThreadsBusy": 5,
> "GcCountTotal": 9,
> "MemoryMax": 1005584384,
> "MemoryCurrent": 221646760,
> "ThreadsWaiting": 20,
> "ProcessorsAvailable": 2,
> "GcTimeMax": 339,
> "ThreadsBlocked": 0,
> "ThreadsRemaining": 9
> }
> }
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (RANGER-4047) Ranger KMS health metrics
[
https://issues.apache.org/jira/browse/RANGER-4047?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17714626#comment-17714626
]
Vikas Kumar commented on RANGER-4047:
-
[~bpatel] , I spent time on this. And if we implement that, it should not be
specific to KMS only, instead it should be part of "ranger-metrics" module so
that these Tomcat metrics can be made available for all Ranger components.
I have created one separate improvement Jira (RANGER-4196) that and will
work separately.
I hope it's okay for you.
> Ranger KMS health metrics
> --
>
> Key: RANGER-4047
> URL: https://issues.apache.org/jira/browse/RANGER-4047
> Project: Ranger
> Issue Type: New Feature
> Components: kms
>Reporter: Vikas Kumar
>Assignee: Vikas Kumar
>Priority: Major
> Attachments: Apache KMS metrics.xlsx
>
>
> Ranger KMS should collect the important System as well as application level
> health metrics.
> System metrics: JVM/CPU/memory related metrics
> Application metrics: KMS API execution metrics. Like, number of time DECRYPT
> operation invoked and time taken to complete the request etc.
> There should also be API to consume these stats, preferably REST API. Any
> metric tools should be able to get these metrics through that REST API.
> This will help making KMS highly observable. Alerts system can be configured
> to consume, process and generate alerts.
> There could be many other use cases.
> *Approach:*
> The solution depends on "ranger-metrics" common module for both Json and
> Prometheus sink.
> Kms has added only KMS specific application metrics. Generally, one COUNT
> metric and corresponding elapsed time gauge metric for each REST end points.
> By default, metric collection is not thread-safe but the by adding following
> property in kms-site.xml it can be made thread-safe:
> Prop name: hadoop.kms.metric.collection.threadsafe=true. // possible values
> true/false
>
> ===Sample response to list down metrics collected
> curl -ivk -H "Content-Type: application/json" -H -X GET
> [http://localhost:9292/kms/metrics/json?user.name=vikas]
> sample response:
> {
> "KMS": {
> "GET_CURRENT_KEY_COUNT": 0,
> "DELETE_KEY_ELAPSED_TIME": 0,
> "EEK_DECRYPT_ELAPSED_TIME": 0,
> "GET_KEYS_METADATA_ELAPSED_TIME": 0,
> "EEK_GENERATE_ELAPSED_TIME": 0,
> "GET_CURRENT_KEY_ELAPSED_TIME": 0,
> "EEK_REENCRYPT_ELAPSED_TIME": 0,
> "KEY_CREATE_COUNT": 1,
> "UNAUTHORIZED_CALLS_COUNT": 0,
> "KEY_CREATE_ELAPSED_TIME": 81,
> "GET_KEY_VERSION_COUNT": 0,
> "ROLL_NEW_VERSION_ELAPSED_TIME": 0,
> "REENCRYPT_EEK_BATCH_COUNT": 0,
> "REENCRYPT_EEK_BATCH_ELAPSED_TIME": 0,
> "GET_KEYS_METADATA_COUNT": 0,
> "GET_KEY_VERSIONS_COUNT": 0,
> "GET_KEY_VERSIONS_ELAPSED_TIME": 0,
> "GET_KEYS_COUNT": 2,
> "EEK_GENERATE_COUNT": 0,
> "INVALIDATE_CACHE_COUNT": 0,
> "GET_METADATA_COUNT": 3,
> "REENCRYPT_EEK_BATCH_KEYS_COUNT": 0,
> "EEK_REENCRYPT_COUNT": 0,
> "UNAUTHENTICATED_CALLS_COUNT": 0,
> "GET_KEY_VERSION_ELAPSED_TIME": 0,
> "INVALIDATE_CACHE_ELAPSED_TIME": 0,
> "ROLL_NEW_VERSION_COUNT": 0,
> "EEK_DECRYPT_COUNT": 0,
> "GET_KEYS_METADATA_KEYNAMES_COUNT": 0,
> "DELETE_KEY_COUNT": 0,
> "GET_KEYS_ELAPSED_TIME": 72,
> "GET_METADATA_ELAPSED_TIME": 14,
> "TOTAL_CALL_COUNT": 7
> },
> "RangerJvm": {
> "GcTimeTotal": 339,
> "SystemLoadAvg": 1.47,
> "ThreadsBusy": 5,
> "GcCountTotal": 9,
> "MemoryMax": 1005584384,
> "MemoryCurrent": 221646760,
> "ThreadsWaiting": 20,
> "ProcessorsAvailable": 2,
> "GcTimeMax": 339,
> "ThreadsBlocked": 0,
> "ThreadsRemaining": 9
> }
> }
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (RANGER-4047) Ranger KMS health metrics
[
https://issues.apache.org/jira/browse/RANGER-4047?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17713584#comment-17713584
]
Vikas Kumar commented on RANGER-4047:
-
Got your point, Let me explore this.
One approach could be to collect and publish the count of RUNNING container
threads, that should also serve the purpose. Because generally we keep number
of allowed http connection and count of container threads same.
Let me explore this, I will keep here posted on the progress.
> Ranger KMS health metrics
> --
>
> Key: RANGER-4047
> URL: https://issues.apache.org/jira/browse/RANGER-4047
> Project: Ranger
> Issue Type: New Feature
> Components: kms
>Reporter: Vikas Kumar
>Assignee: Vikas Kumar
>Priority: Major
> Attachments: Apache KMS metrics.xlsx
>
>
> Ranger KMS should collect the important System as well as application level
> health metrics.
> System metrics: JVM/CPU/memory related metrics
> Application metrics: KMS API execution metrics. Like, number of time DECRYPT
> operation invoked and time taken to complete the request etc.
> There should also be API to consume these stats, preferably REST API. Any
> metric tools should be able to get these metrics through that REST API.
> This will help making KMS highly observable. Alerts system can be configured
> to consume, process and generate alerts.
> There could be many other use cases.
> *Approach:*
> The solution depends on "ranger-metrics" common module for both Json and
> Prometheus sink.
> Kms has added only KMS specific application metrics. Generally, one COUNT
> metric and corresponding elapsed time gauge metric for each REST end points.
> By default, metric collection is not thread-safe but the by adding following
> property in kms-site.xml it can be made thread-safe:
> Prop name: hadoop.kms.metric.collection.threadsafe=true. // possible values
> true/false
>
> ===Sample response to list down metrics collected
> curl -ivk -H "Content-Type: application/json" -H -X GET
> [http://localhost:9292/kms/metrics/json?user.name=vikas]
> sample response:
> {
> "KMS": {
> "GET_CURRENT_KEY_COUNT": 0,
> "DELETE_KEY_ELAPSED_TIME": 0,
> "EEK_DECRYPT_ELAPSED_TIME": 0,
> "GET_KEYS_METADATA_ELAPSED_TIME": 0,
> "EEK_GENERATE_ELAPSED_TIME": 0,
> "GET_CURRENT_KEY_ELAPSED_TIME": 0,
> "EEK_REENCRYPT_ELAPSED_TIME": 0,
> "KEY_CREATE_COUNT": 1,
> "UNAUTHORIZED_CALLS_COUNT": 0,
> "KEY_CREATE_ELAPSED_TIME": 81,
> "GET_KEY_VERSION_COUNT": 0,
> "ROLL_NEW_VERSION_ELAPSED_TIME": 0,
> "REENCRYPT_EEK_BATCH_COUNT": 0,
> "REENCRYPT_EEK_BATCH_ELAPSED_TIME": 0,
> "GET_KEYS_METADATA_COUNT": 0,
> "GET_KEY_VERSIONS_COUNT": 0,
> "GET_KEY_VERSIONS_ELAPSED_TIME": 0,
> "GET_KEYS_COUNT": 2,
> "EEK_GENERATE_COUNT": 0,
> "INVALIDATE_CACHE_COUNT": 0,
> "GET_METADATA_COUNT": 3,
> "REENCRYPT_EEK_BATCH_KEYS_COUNT": 0,
> "EEK_REENCRYPT_COUNT": 0,
> "UNAUTHENTICATED_CALLS_COUNT": 0,
> "GET_KEY_VERSION_ELAPSED_TIME": 0,
> "INVALIDATE_CACHE_ELAPSED_TIME": 0,
> "ROLL_NEW_VERSION_COUNT": 0,
> "EEK_DECRYPT_COUNT": 0,
> "GET_KEYS_METADATA_KEYNAMES_COUNT": 0,
> "DELETE_KEY_COUNT": 0,
> "GET_KEYS_ELAPSED_TIME": 72,
> "GET_METADATA_ELAPSED_TIME": 14,
> "TOTAL_CALL_COUNT": 7
> },
> "RangerJvm": {
> "GcTimeTotal": 339,
> "SystemLoadAvg": 1.47,
> "ThreadsBusy": 5,
> "GcCountTotal": 9,
> "MemoryMax": 1005584384,
> "MemoryCurrent": 221646760,
> "ThreadsWaiting": 20,
> "ProcessorsAvailable": 2,
> "GcTimeMax": 339,
> "ThreadsBlocked": 0,
> "ThreadsRemaining": 9
> }
> }
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (RANGER-4047) Ranger KMS health metrics
[
https://issues.apache.org/jira/browse/RANGER-4047?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17713034#comment-17713034
]
Bhavik Patel commented on RANGER-4047:
--
Number of HttpConnection is governed by Http Server's (Tomcat container)
configuration like for Tomcat following is the parameter:
{*}maxConnections{*}: The maximum number of connections that the server will
accept and process at any given time.
===> Right, so there is any way to get the total number of open connections?
Use case:
As we are observing connection timeout warning in many jobs
so to debug that we are checking how many calls are made to KMS and to find
that we using the access logs but we want to make sure http open connections
and access logs count must be the same.
> Ranger KMS health metrics
> --
>
> Key: RANGER-4047
> URL: https://issues.apache.org/jira/browse/RANGER-4047
> Project: Ranger
> Issue Type: New Feature
> Components: kms
>Reporter: Vikas Kumar
>Assignee: Vikas Kumar
>Priority: Major
> Attachments: Apache KMS metrics.xlsx
>
>
> Ranger KMS should collect the important System as well as application level
> health metrics.
> System metrics: JVM/CPU/memory related metrics
> Application metrics: KMS API execution metrics. Like, number of time DECRYPT
> operation invoked and time taken to complete the request etc.
> There should also be API to consume these stats, preferably REST API. Any
> metric tools should be able to get these metrics through that REST API.
> This will help making KMS highly observable. Alerts system can be configured
> to consume, process and generate alerts.
> There could be many other use cases.
> *Approach:*
> The solution depends on "ranger-metrics" common module for both Json and
> Prometheus sink.
> Kms has added only KMS specific application metrics. Generally, one COUNT
> metric and corresponding elapsed time gauge metric for each REST end points.
> By default, metric collection is not thread-safe but the by adding following
> property in kms-site.xml it can be made thread-safe:
> Prop name: hadoop.kms.metric.collection.threadsafe=true. // possible values
> true/false
>
> ===Sample response to list down metrics collected
> curl -ivk -H "Content-Type: application/json" -H -X GET
> [http://localhost:9292/kms/metrics/json?user.name=vikas]
> sample response:
> {
> "KMS": {
> "GET_CURRENT_KEY_COUNT": 0,
> "DELETE_KEY_ELAPSED_TIME": 0,
> "EEK_DECRYPT_ELAPSED_TIME": 0,
> "GET_KEYS_METADATA_ELAPSED_TIME": 0,
> "EEK_GENERATE_ELAPSED_TIME": 0,
> "GET_CURRENT_KEY_ELAPSED_TIME": 0,
> "EEK_REENCRYPT_ELAPSED_TIME": 0,
> "KEY_CREATE_COUNT": 1,
> "UNAUTHORIZED_CALLS_COUNT": 0,
> "KEY_CREATE_ELAPSED_TIME": 81,
> "GET_KEY_VERSION_COUNT": 0,
> "ROLL_NEW_VERSION_ELAPSED_TIME": 0,
> "REENCRYPT_EEK_BATCH_COUNT": 0,
> "REENCRYPT_EEK_BATCH_ELAPSED_TIME": 0,
> "GET_KEYS_METADATA_COUNT": 0,
> "GET_KEY_VERSIONS_COUNT": 0,
> "GET_KEY_VERSIONS_ELAPSED_TIME": 0,
> "GET_KEYS_COUNT": 2,
> "EEK_GENERATE_COUNT": 0,
> "INVALIDATE_CACHE_COUNT": 0,
> "GET_METADATA_COUNT": 3,
> "REENCRYPT_EEK_BATCH_KEYS_COUNT": 0,
> "EEK_REENCRYPT_COUNT": 0,
> "UNAUTHENTICATED_CALLS_COUNT": 0,
> "GET_KEY_VERSION_ELAPSED_TIME": 0,
> "INVALIDATE_CACHE_ELAPSED_TIME": 0,
> "ROLL_NEW_VERSION_COUNT": 0,
> "EEK_DECRYPT_COUNT": 0,
> "GET_KEYS_METADATA_KEYNAMES_COUNT": 0,
> "DELETE_KEY_COUNT": 0,
> "GET_KEYS_ELAPSED_TIME": 72,
> "GET_METADATA_ELAPSED_TIME": 14,
> "TOTAL_CALL_COUNT": 7
> },
> "RangerJvm": {
> "GcTimeTotal": 339,
> "SystemLoadAvg": 1.47,
> "ThreadsBusy": 5,
> "GcCountTotal": 9,
> "MemoryMax": 1005584384,
> "MemoryCurrent": 221646760,
> "ThreadsWaiting": 20,
> "ProcessorsAvailable": 2,
> "GcTimeMax": 339,
> "ThreadsBlocked": 0,
> "ThreadsRemaining": 9
> }
> }
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (RANGER-4047) Ranger KMS health metrics
[
https://issues.apache.org/jira/browse/RANGER-4047?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17713003#comment-17713003
]
Vikas Kumar commented on RANGER-4047:
-
I have tried to consolidate all collected metrics with endpoints and
description in following spreadsheet.
[^Apache KMS metrics.xlsx]
> Ranger KMS health metrics
> --
>
> Key: RANGER-4047
> URL: https://issues.apache.org/jira/browse/RANGER-4047
> Project: Ranger
> Issue Type: New Feature
> Components: kms
>Reporter: Vikas Kumar
>Assignee: Vikas Kumar
>Priority: Major
> Attachments: Apache KMS metrics.xlsx,
> image-2023-04-17-15-24-54-207.png
>
>
> Ranger KMS should collect the important System as well as application level
> health metrics.
> System metrics: JVM/CPU/memory related metrics
> Application metrics: KMS API execution metrics. Like, number of time DECRYPT
> operation invoked and time taken to complete the request etc.
> There should also be API to consume these stats, preferably REST API. Any
> metric tools should be able to get these metrics through that REST API.
> This will help making KMS highly observable. Alerts system can be configured
> to consume, process and generate alerts.
> There could be many other use cases.
> *Approach:*
> The solution depends on "ranger-metrics" common module for both Json and
> Prometheus sink.
> Kms has added only KMS specific application metrics. Generally, one COUNT
> metric and corresponding elapsed time gauge metric for each REST end points.
> By default, metric collection is not thread-safe but the by adding following
> property in kms-site.xml it can be made thread-safe:
> Prop name: hadoop.kms.metric.collection.threadsafe=true. // possible values
> true/false
>
> ===Sample response to list down metrics collected
> curl -ivk -H "Content-Type: application/json" -H -X GET
> [http://localhost:9292/kms/metrics/json?user.name=vikas]
> sample response:
> {
> "KMS": {
> "GET_CURRENT_KEY_COUNT": 0,
> "DELETE_KEY_ELAPSED_TIME": 0,
> "EEK_DECRYPT_ELAPSED_TIME": 0,
> "GET_KEYS_METADATA_ELAPSED_TIME": 0,
> "EEK_GENERATE_ELAPSED_TIME": 0,
> "GET_CURRENT_KEY_ELAPSED_TIME": 0,
> "EEK_REENCRYPT_ELAPSED_TIME": 0,
> "KEY_CREATE_COUNT": 1,
> "UNAUTHORIZED_CALLS_COUNT": 0,
> "KEY_CREATE_ELAPSED_TIME": 81,
> "GET_KEY_VERSION_COUNT": 0,
> "ROLL_NEW_VERSION_ELAPSED_TIME": 0,
> "REENCRYPT_EEK_BATCH_COUNT": 0,
> "REENCRYPT_EEK_BATCH_ELAPSED_TIME": 0,
> "GET_KEYS_METADATA_COUNT": 0,
> "GET_KEY_VERSIONS_COUNT": 0,
> "GET_KEY_VERSIONS_ELAPSED_TIME": 0,
> "GET_KEYS_COUNT": 2,
> "EEK_GENERATE_COUNT": 0,
> "INVALIDATE_CACHE_COUNT": 0,
> "GET_METADATA_COUNT": 3,
> "REENCRYPT_EEK_BATCH_KEYS_COUNT": 0,
> "EEK_REENCRYPT_COUNT": 0,
> "UNAUTHENTICATED_CALLS_COUNT": 0,
> "GET_KEY_VERSION_ELAPSED_TIME": 0,
> "INVALIDATE_CACHE_ELAPSED_TIME": 0,
> "ROLL_NEW_VERSION_COUNT": 0,
> "EEK_DECRYPT_COUNT": 0,
> "GET_KEYS_METADATA_KEYNAMES_COUNT": 0,
> "DELETE_KEY_COUNT": 0,
> "GET_KEYS_ELAPSED_TIME": 72,
> "GET_METADATA_ELAPSED_TIME": 14,
> "TOTAL_CALL_COUNT": 7
> },
> "RangerJvm": {
> "GcTimeTotal": 339,
> "SystemLoadAvg": 1.47,
> "ThreadsBusy": 5,
> "GcCountTotal": 9,
> "MemoryMax": 1005584384,
> "MemoryCurrent": 221646760,
> "ThreadsWaiting": 20,
> "ProcessorsAvailable": 2,
> "GcTimeMax": 339,
> "ThreadsBlocked": 0,
> "ThreadsRemaining": 9
> }
> }
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (RANGER-4047) Ranger KMS health metrics
[
https://issues.apache.org/jira/browse/RANGER-4047?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17713001#comment-17713001
]
Vikas Kumar commented on RANGER-4047:
-
[~bpatel] , it's partially correct.
Actually it counts the total number of KMS API calls. It doesn't consider
*"/kms/api/status" api* as we know it gets invoked very frequently to know the
whether kms process is UP or not.
It will give you the count of all calls to KMS except *"/kms/api/status".* This
counter has been added in KMSAuthenticationFilter.
Number of HttpConnection is governed by Http Server's (Tomcat container)
configuration like for Tomcat following is the parameter:
{*}maxConnections{*}: The maximum number of connections that the server will
accept and process at any given time.
So this counter is not monitoring the number of open http connections, instead
it is counting the number of times KMS API has been invoked.
If you have any specific input/idea, please suggest in detail. I would give it
a try to include them as well.
> Ranger KMS health metrics
> --
>
> Key: RANGER-4047
> URL: https://issues.apache.org/jira/browse/RANGER-4047
> Project: Ranger
> Issue Type: New Feature
> Components: kms
>Reporter: Vikas Kumar
>Assignee: Vikas Kumar
>Priority: Major
> Attachments: image-2023-04-17-15-24-54-207.png
>
>
> Ranger KMS should collect the important System as well as application level
> health metrics.
> System metrics: JVM/CPU/memory related metrics
> Application metrics: KMS API execution metrics. Like, number of time DECRYPT
> operation invoked and time taken to complete the request etc.
> There should also be API to consume these stats, preferably REST API. Any
> metric tools should be able to get these metrics through that REST API.
> This will help making KMS highly observable. Alerts system can be configured
> to consume, process and generate alerts.
> There could be many other use cases.
> *Approach:*
> The solution depends on "ranger-metrics" common module for both Json and
> Prometheus sink.
> Kms has added only KMS specific application metrics. Generally, one COUNT
> metric and corresponding elapsed time gauge metric for each REST end points.
> By default, metric collection is not thread-safe but the by adding following
> property in kms-site.xml it can be made thread-safe:
> Prop name: hadoop.kms.metric.collection.threadsafe=true. // possible values
> true/false
>
> ===Sample response to list down metrics collected
> curl -ivk -H "Content-Type: application/json" -H -X GET
> [http://localhost:9292/kms/metrics/json?user.name=vikas]
> sample response:
> {
> "KMS": {
> "GET_CURRENT_KEY_COUNT": 0,
> "DELETE_KEY_ELAPSED_TIME": 0,
> "EEK_DECRYPT_ELAPSED_TIME": 0,
> "GET_KEYS_METADATA_ELAPSED_TIME": 0,
> "EEK_GENERATE_ELAPSED_TIME": 0,
> "GET_CURRENT_KEY_ELAPSED_TIME": 0,
> "EEK_REENCRYPT_ELAPSED_TIME": 0,
> "KEY_CREATE_COUNT": 1,
> "UNAUTHORIZED_CALLS_COUNT": 0,
> "KEY_CREATE_ELAPSED_TIME": 81,
> "GET_KEY_VERSION_COUNT": 0,
> "ROLL_NEW_VERSION_ELAPSED_TIME": 0,
> "REENCRYPT_EEK_BATCH_COUNT": 0,
> "REENCRYPT_EEK_BATCH_ELAPSED_TIME": 0,
> "GET_KEYS_METADATA_COUNT": 0,
> "GET_KEY_VERSIONS_COUNT": 0,
> "GET_KEY_VERSIONS_ELAPSED_TIME": 0,
> "GET_KEYS_COUNT": 2,
> "EEK_GENERATE_COUNT": 0,
> "INVALIDATE_CACHE_COUNT": 0,
> "GET_METADATA_COUNT": 3,
> "REENCRYPT_EEK_BATCH_KEYS_COUNT": 0,
> "EEK_REENCRYPT_COUNT": 0,
> "UNAUTHENTICATED_CALLS_COUNT": 0,
> "GET_KEY_VERSION_ELAPSED_TIME": 0,
> "INVALIDATE_CACHE_ELAPSED_TIME": 0,
> "ROLL_NEW_VERSION_COUNT": 0,
> "EEK_DECRYPT_COUNT": 0,
> "GET_KEYS_METADATA_KEYNAMES_COUNT": 0,
> "DELETE_KEY_COUNT": 0,
> "GET_KEYS_ELAPSED_TIME": 72,
> "GET_METADATA_ELAPSED_TIME": 14,
> "TOTAL_CALL_COUNT": 7
> },
> "RangerJvm": {
> "GcTimeTotal": 339,
> "SystemLoadAvg": 1.47,
> "ThreadsBusy": 5,
> "GcCountTotal": 9,
> "MemoryMax": 1005584384,
> "MemoryCurrent": 221646760,
> "ThreadsWaiting": 20,
> "ProcessorsAvailable": 2,
> "GcTimeMax": 339,
> "ThreadsBlocked": 0,
> "ThreadsRemaining": 9
> }
> }
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (RANGER-4047) Ranger KMS health metrics
[
https://issues.apache.org/jira/browse/RANGER-4047?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17712895#comment-17712895
]
Bhavik Patel commented on RANGER-4047:
--
This *"TOTAL_CALL_COUNT": 7* attribute ** count the total http connection made
by client, right?
If yes then it's better along with total param if we count http connections per
user.
> Ranger KMS health metrics
> --
>
> Key: RANGER-4047
> URL: https://issues.apache.org/jira/browse/RANGER-4047
> Project: Ranger
> Issue Type: New Feature
> Components: kms
>Reporter: Vikas Kumar
>Assignee: Vikas Kumar
>Priority: Major
>
> Ranger KMS should collect the important System as well as application level
> health metrics.
> System metrics: JVM/CPU/memory related metrics
> Application metrics: KMS API execution metrics. Like, number of time DECRYPT
> operation invoked and time taken to complete the request etc.
> There should also be API to consume these stats, preferably REST API. Any
> metric tools should be able to get these metrics through that REST API.
> This will help making KMS highly observable. Alerts system can be configured
> to consume, process and generate alerts.
> There could be many other use cases.
> *Approach:*
> The solution depends on "ranger-metrics" common module for both Json and
> Prometheus sink.
> Kms has added only KMS specific application metrics. Generally, one COUNT
> metric and corresponding elapsed time gauge metric for each REST end points.
> By default, metric collection is not thread-safe but the by adding following
> property in kms-site.xml it can be made thread-safe:
> Prop name: hadoop.kms.metric.collection.threadsafe=true. // possible values
> true/false
>
> ===Sample response to list down metrics collected
> curl -ivk -H "Content-Type: application/json" -H -X GET
> [http://localhost:9292/kms/metrics/json?user.name=vikas]
> sample response:
> {
> "KMS": {
> "GET_CURRENT_KEY_COUNT": 0,
> "DELETE_KEY_ELAPSED_TIME": 0,
> "EEK_DECRYPT_ELAPSED_TIME": 0,
> "GET_KEYS_METADATA_ELAPSED_TIME": 0,
> "EEK_GENERATE_ELAPSED_TIME": 0,
> "GET_CURRENT_KEY_ELAPSED_TIME": 0,
> "EEK_REENCRYPT_ELAPSED_TIME": 0,
> "KEY_CREATE_COUNT": 1,
> "UNAUTHORIZED_CALLS_COUNT": 0,
> "KEY_CREATE_ELAPSED_TIME": 81,
> "GET_KEY_VERSION_COUNT": 0,
> "ROLL_NEW_VERSION_ELAPSED_TIME": 0,
> "REENCRYPT_EEK_BATCH_COUNT": 0,
> "REENCRYPT_EEK_BATCH_ELAPSED_TIME": 0,
> "GET_KEYS_METADATA_COUNT": 0,
> "GET_KEY_VERSIONS_COUNT": 0,
> "GET_KEY_VERSIONS_ELAPSED_TIME": 0,
> "GET_KEYS_COUNT": 2,
> "EEK_GENERATE_COUNT": 0,
> "INVALIDATE_CACHE_COUNT": 0,
> "GET_METADATA_COUNT": 3,
> "REENCRYPT_EEK_BATCH_KEYS_COUNT": 0,
> "EEK_REENCRYPT_COUNT": 0,
> "UNAUTHENTICATED_CALLS_COUNT": 0,
> "GET_KEY_VERSION_ELAPSED_TIME": 0,
> "INVALIDATE_CACHE_ELAPSED_TIME": 0,
> "ROLL_NEW_VERSION_COUNT": 0,
> "EEK_DECRYPT_COUNT": 0,
> "GET_KEYS_METADATA_KEYNAMES_COUNT": 0,
> "DELETE_KEY_COUNT": 0,
> "GET_KEYS_ELAPSED_TIME": 72,
> "GET_METADATA_ELAPSED_TIME": 14,
> "TOTAL_CALL_COUNT": 7
> },
> "RangerJvm": {
> "GcTimeTotal": 339,
> "SystemLoadAvg": 1.47,
> "ThreadsBusy": 5,
> "GcCountTotal": 9,
> "MemoryMax": 1005584384,
> "MemoryCurrent": 221646760,
> "ThreadsWaiting": 20,
> "ProcessorsAvailable": 2,
> "GcTimeMax": 339,
> "ThreadsBlocked": 0,
> "ThreadsRemaining": 9
> }
> }
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (RANGER-4047) Ranger KMS health metrics
[
https://issues.apache.org/jira/browse/RANGER-4047?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17712465#comment-17712465
]
Vikas Kumar commented on RANGER-4047:
-
Updated the patch. Requesting reviewers to please review and add your feedbacks.
> Ranger KMS health metrics
> --
>
> Key: RANGER-4047
> URL: https://issues.apache.org/jira/browse/RANGER-4047
> Project: Ranger
> Issue Type: New Feature
> Components: kms
>Reporter: Vikas Kumar
>Assignee: Vikas Kumar
>Priority: Major
>
> Ranger KMS should collect the important System as well as application level
> health metrics.
> System metrics: JVM/CPU/memory related metrics
> Application metrics: KMS API execution metrics. Like, number of time DECRYPT
> operation invoked and time taken to complete the request etc.
> There should also be API to consume these stats, preferably REST API. Any
> metric tools should be able to get these metrics through that REST API.
> This will help making KMS highly observable. Alerts system can be configured
> to consume, process and generate alerts.
> There could be many other use cases.
> *Approach:*
> The solution depends on "ranger-metrics" common module for both Json and
> Prometheus sink.
> Kms has added only KMS specific application metrics. Generally, one COUNT
> metric and corresponding elapsed time gauge metric for each REST end points.
> By default, metric collection is not thread-safe but the by adding following
> property in kms-site.xml it can be made thread-safe:
> Prop name: hadoop.kms.metric.collection.threadsafe=true. // possible values
> true/false
>
> ===Sample response to list down metrics collected
> curl -ivk -H "Content-Type: application/json" -H -X GET
> [http://localhost:9292/kms/metrics/json?user.name=vikas]
> sample response:
> {
> "KMS": {
> "GET_CURRENT_KEY_COUNT": 0,
> "DELETE_KEY_ELAPSED_TIME": 0,
> "EEK_DECRYPT_ELAPSED_TIME": 0,
> "GET_KEYS_METADATA_ELAPSED_TIME": 0,
> "EEK_GENERATE_ELAPSED_TIME": 0,
> "GET_CURRENT_KEY_ELAPSED_TIME": 0,
> "EEK_REENCRYPT_ELAPSED_TIME": 0,
> "KEY_CREATE_COUNT": 1,
> "UNAUTHORIZED_CALLS_COUNT": 0,
> "KEY_CREATE_ELAPSED_TIME": 81,
> "GET_KEY_VERSION_COUNT": 0,
> "ROLL_NEW_VERSION_ELAPSED_TIME": 0,
> "REENCRYPT_EEK_BATCH_COUNT": 0,
> "REENCRYPT_EEK_BATCH_ELAPSED_TIME": 0,
> "GET_KEYS_METADATA_COUNT": 0,
> "GET_KEY_VERSIONS_COUNT": 0,
> "GET_KEY_VERSIONS_ELAPSED_TIME": 0,
> "GET_KEYS_COUNT": 2,
> "EEK_GENERATE_COUNT": 0,
> "INVALIDATE_CACHE_COUNT": 0,
> "GET_METADATA_COUNT": 3,
> "REENCRYPT_EEK_BATCH_KEYS_COUNT": 0,
> "EEK_REENCRYPT_COUNT": 0,
> "UNAUTHENTICATED_CALLS_COUNT": 0,
> "GET_KEY_VERSION_ELAPSED_TIME": 0,
> "INVALIDATE_CACHE_ELAPSED_TIME": 0,
> "ROLL_NEW_VERSION_COUNT": 0,
> "EEK_DECRYPT_COUNT": 0,
> "GET_KEYS_METADATA_KEYNAMES_COUNT": 0,
> "DELETE_KEY_COUNT": 0,
> "GET_KEYS_ELAPSED_TIME": 72,
> "GET_METADATA_ELAPSED_TIME": 14,
> "TOTAL_CALL_COUNT": 7
> },
> "RangerJvm": {
> "GcTimeTotal": 339,
> "SystemLoadAvg": 1.47,
> "ThreadsBusy": 5,
> "GcCountTotal": 9,
> "MemoryMax": 1005584384,
> "MemoryCurrent": 221646760,
> "ThreadsWaiting": 20,
> "ProcessorsAvailable": 2,
> "GcTimeMax": 339,
> "ThreadsBlocked": 0,
> "ThreadsRemaining": 9
> }
> }
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (RANGER-4047) Ranger KMS health metrics
[ https://issues.apache.org/jira/browse/RANGER-4047?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17712381#comment-17712381 ] Vikas Kumar commented on RANGER-4047: - Added review request: [https://reviews.apache.org/r/74396/] > Ranger KMS health metrics > -- > > Key: RANGER-4047 > URL: https://issues.apache.org/jira/browse/RANGER-4047 > Project: Ranger > Issue Type: New Feature > Components: kms >Reporter: Vikas Kumar >Assignee: Vikas Kumar >Priority: Major > > Ranger KMS should collect the important System as well as application level > health metrics. > System metrics: JVM/CPU/memory related metrics > Application metrics: KMS API execution metrics. Like, number of time DECRYPT > operation invoked and time taken to complete the request etc. > There should also be API to consume these stats, preferably REST API. Any > metric tools should be able to get these metrics through that REST API. > This will help making KMS highly observable. Alerts system can be configured > to consume, process and generate alerts. > There could be many other use cases. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (RANGER-4047) Ranger KMS health metrics
[ https://issues.apache.org/jira/browse/RANGER-4047?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17710973#comment-17710973 ] Vikas Kumar commented on RANGER-4047: - [~bpatel] , I am aware of Kishore's "ranger-metric" module changes. KMS health metric code will depend on this common module. I am already working on this. > Ranger KMS health metrics > -- > > Key: RANGER-4047 > URL: https://issues.apache.org/jira/browse/RANGER-4047 > Project: Ranger > Issue Type: New Feature > Components: kms >Reporter: Vikas Kumar >Assignee: Vikas Kumar >Priority: Major > > Ranger KMS should collect the important System as well as application level > health metrics. > System metrics: JVM/CPU/memory related metrics > Application metrics: KMS API execution metrics. Like, number of time DECRYPT > operation invoked and time taken to complete the request etc. > There should also be API to consume these stats, preferably REST API. Any > metric tools should be able to get these metrics through that REST API. > This will help making KMS highly observable. Alerts system can be configured > to consume, process and generate alerts. > There could be many other use cases. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (RANGER-4047) Ranger KMS health metrics
[ https://issues.apache.org/jira/browse/RANGER-4047?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17710930#comment-17710930 ] Bhavik Patel commented on RANGER-4047: -- [~vikkumar] check the jira: https://issues.apache.org/jira/browse/RANGER-4152 to use common module. > Ranger KMS health metrics > -- > > Key: RANGER-4047 > URL: https://issues.apache.org/jira/browse/RANGER-4047 > Project: Ranger > Issue Type: New Feature > Components: kms >Reporter: Vikas Kumar >Assignee: Vikas Kumar >Priority: Major > > Ranger KMS should collect the important System as well as application level > health metrics. > System metrics: JVM/CPU/memory related metrics > Application metrics: KMS API execution metrics. Like, number of time DECRYPT > operation invoked and time taken to complete the request etc. > There should also be API to consume these stats, preferably REST API. Any > metric tools should be able to get these metrics through that REST API. > This will help making KMS highly observable. Alerts system can be configured > to consume, process and generate alerts. > There could be many other use cases. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (RANGER-4047) Ranger KMS health metrics
[ https://issues.apache.org/jira/browse/RANGER-4047?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17705939#comment-17705939 ] Bhavik Patel commented on RANGER-4047: -- [~vikkumar] are you working on this? > Ranger KMS health metrics > -- > > Key: RANGER-4047 > URL: https://issues.apache.org/jira/browse/RANGER-4047 > Project: Ranger > Issue Type: New Feature > Components: kms >Reporter: Vikas Kumar >Assignee: Vikas Kumar >Priority: Major > > Ranger KMS should collect the important System as well as application level > health metrics. > System metrics: JVM/CPU/memory related metrics > Application metrics: KMS API execution metrics. Like, number of time DECRYPT > operation invoked and time taken to complete the request etc. > There should also be API to consume these stats, preferably REST API. Any > metric tools should be able to get these metrics through that REST API. > This will help making KMS highly observable. Alerts system can be configured > to consume, process and generate alerts. > There could be many other use cases. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (RANGER-4047) Ranger KMS health metrics
[ https://issues.apache.org/jira/browse/RANGER-4047?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17680100#comment-17680100 ] Bhavik Patel commented on RANGER-4047: -- This will feature will surly help a lot. Thanks [~vikkumar]. > Ranger KMS health metrics > -- > > Key: RANGER-4047 > URL: https://issues.apache.org/jira/browse/RANGER-4047 > Project: Ranger > Issue Type: New Feature > Components: kms >Reporter: Vikas Kumar >Assignee: Vikas Kumar >Priority: Major > > Ranger KMS should collect the important System as well as application level > health metrics. > System metrics: JVM/CPU/memory related metrics > Application metrics: KMS API execution metrics. Like, number of time DECRYPT > operation invoked and time taken to complete the request etc. > There should also be API to consume these stats, preferably REST API. Any > metric tools should be able to get these metrics through that REST API. > This will help making KMS highly observable. Alerts system can be configured > to consume, process and generate alerts. > There could be many other use cases. -- This message was sent by Atlassian Jira (v8.20.10#820010)
