[ 
https://issues.apache.org/jira/browse/HBASE-5433?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Eric Huang updated HBASE-5433:
------------------------------

    Description: 
In a production environment, the visibility of successful REST request(s) are 
not getting exposed to metric system as we have only one metric (requests) 
today.
Proposing to add more metrics such as successful_get_count, failed_get_count, 
successful_put_count, failed_put_count

The current implementation increases the request count at the beginning of the 
method implementation and it is very hard to monitor requests (unless turn on 
debug, find the row_key and validate it in get/scan using hbase shell), it will 
be very useful to ops to keep an eye as requests from cross data-centers are 
trying to write data to one cluster using REST gateway through load balancer 
(and there is no visibility of which REST-server/RS failed to write data)

{code}
 Response update(final CellSetModel model, final boolean replace) {
    // for requests
    servlet.getMetrics().incrementRequests(1);
       ..  
       ..
      table.put(puts);
      table.flushCommits();
      ResponseBuilder response = Response.ok(); 
      // for successful_get_count
      servlet.getMetrics().incrementSuccessfulGetRequests(1);
      return response.build();
    } catch (IOException e) {
      // for failed_get_count
      servlet.getMetrics().incrementFailedGetRequests(1);
      throw new WebApplicationException(e,
                  Response.Status.SERVICE_UNAVAILABLE);
    } finally {
    }
  }
{code}

  was:
In a production environment, the visibility of successful REST request(s) are 
not getting exposed to metric system as we have only one metric (requests) 
today.
Proposing to add more metrics such as successful_get_count, failed_get_count, 
successful_put_count, failed_put_count

The current implementation increases the request count at the beginning of the 
method implementation and it is very hard to monitor requests (unless turn on 
debug, find the row_key and validate it in get/scan using hbase shell), it will 
be very useful to ops to keep an eye as requests from cross data-centers are 
trying to write data to one cluster using REST gateway through load balancer 
(and there is no visibility of which REST-server/RS failed to write data)

{code}
 Response update(final CellSetModel model, final boolean replace) {
    // for requests
    servlet.getMetrics().incrementRequests(1);
       ..  
       ..
      table.put(puts);
      table.flushCommits();
      ResponseBuilder response = Response.ok();
      // for successful_get_count
      servlet.getMetrics().incrementSuccessfulGetRequests(1);
      return response.build();
    } catch (IOException e) {
      // for failed_get_count
      servlet.getMetrics().incrementFailedGetRequests(1);
      throw new WebApplicationException(e,
                  Response.Status.SERVICE_UNAVAILABLE);
    } finally {
    }
  }
{code}

    
> [REST] Add metrics to keep track of success/failure count
> ---------------------------------------------------------
>
>                 Key: HBASE-5433
>                 URL: https://issues.apache.org/jira/browse/HBASE-5433
>             Project: HBase
>          Issue Type: Improvement
>          Components: metrics, REST
>    Affects Versions: 0.94.0
>            Reporter: Mubarak Seyed
>            Assignee: Mubarak Seyed
>              Labels: noob
>             Fix For: 0.94.0, 0.95.0
>
>         Attachments: HBASE-5433.trunk.v1.patch
>
>
> In a production environment, the visibility of successful REST request(s) are 
> not getting exposed to metric system as we have only one metric (requests) 
> today.
> Proposing to add more metrics such as successful_get_count, failed_get_count, 
> successful_put_count, failed_put_count
> The current implementation increases the request count at the beginning of 
> the method implementation and it is very hard to monitor requests (unless 
> turn on debug, find the row_key and validate it in get/scan using hbase 
> shell), it will be very useful to ops to keep an eye as requests from cross 
> data-centers are trying to write data to one cluster using REST gateway 
> through load balancer (and there is no visibility of which REST-server/RS 
> failed to write data)
> {code}
>  Response update(final CellSetModel model, final boolean replace) {
>     // for requests
>     servlet.getMetrics().incrementRequests(1);
>        ..  
>        ..
>       table.put(puts);
>       table.flushCommits();
>       ResponseBuilder response = Response.ok(); 
>       // for successful_get_count
>       servlet.getMetrics().incrementSuccessfulGetRequests(1);
>       return response.build();
>     } catch (IOException e) {
>       // for failed_get_count
>       servlet.getMetrics().incrementFailedGetRequests(1);
>       throw new WebApplicationException(e,
>                   Response.Status.SERVICE_UNAVAILABLE);
>     } finally {
>     }
>   }
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Reply via email to