[
https://issues.apache.org/jira/browse/KNOX-643?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15540380#comment-15540380
]
Larry McCay commented on KNOX-643:
----------------------------------
[~sumit.gupta] - this looks like a great set of goals.
I wonder whether an aggregate of metrics at the topology level is worth
pursuing.
I'd also be interested in specific usecases that these metrics could help
troubleshoot.
Maybe it would be worth writing up a KIP to describe the usecases and
implementation details.
I will have a look at the patch and API.
> Add the ability to gather and expose metrics in the gateway
> -----------------------------------------------------------
>
> Key: KNOX-643
> URL: https://issues.apache.org/jira/browse/KNOX-643
> Project: Apache Knox
> Issue Type: New Feature
> Components: Server
> Affects Versions: 0.8.0
> Reporter: Sumit Gupta
> Assignee: Sumit Gupta
> Fix For: Future
>
> Attachments: KNOX-643.patch
>
>
> The goal would be to capture various request/response metrics in the gateway
> and expose them via JMX and/or REST.
> Some of the requests on the dev mailing list are:
> - Capture TPS both at the service level as well as aggregate for the server
> instance.
> - Byte transfer counts per service and aggregate
> - Unsuccessful login
> - Successful login but overall return was HTTP 500 which indicates failure
> on the cluster side. An example would be users connecting to Knox with
> valid AD user/pass but which were not authorized in the cluster. This can
> happen when the cluster is in secure mode but a service like Centrify has
> not allowed the user into the cluster's zone.
> - Unsuccessful AD lookup by Knox - user doesn't exist.
> - Connection counts that used and didn't use an auth cookie and resulted in
> an AD lookup
> - Current open connections
> - Capability to reset the aggregate counters while Knox is running.
> - Ability to hook into Ambari's Metric collection framework.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
