-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/51562/#review147467
-----------------------------------------------------------




ambari-metrics/ambari-metrics-host-monitoring/src/main/python/core/host_info.py 
(line 260)
<https://reviews.apache.org/r/51562/#comment214649>

    This will break a long running process, this should log as error but not 
result in a pkill.



ambari-metrics/ambari-metrics-host-monitoring/src/main/python/core/host_info.py 
(line 262)
<https://reviews.apache.org/r/51562/#comment214650>

    How about inversion of control here? Store allowed values as a dict and 
check against it? If not in allowed values then check pattern and either add to 
allowed or not.



ambari-server/src/main/resources/common-services/AMBARI_METRICS/0.1.0/configuration/ams-env.xml
 (line 84)
<https://reviews.apache.org/r/51562/#comment214651>

    Sink interval should also be in ams-env instead of ams-site.


- Sid Wagle


On Aug. 31, 2016, 6:49 p.m., Aravindan Vijayan wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/51562/
> -----------------------------------------------------------
> 
> (Updated Aug. 31, 2016, 6:49 p.m.)
> 
> 
> Review request for Ambari, Dmytro Sen, Sumit Mohanty, and Sid Wagle.
> 
> 
> Bugs: AMBARI-18289
>     https://issues.apache.org/jira/browse/AMBARI-18289
> 
> 
> Repository: ambari
> 
> 
> Description
> -------
> 
> PROBLEM
> Negative values are being reported for IOPS in the "system servers" dashboard
> 
> BUG
> This was a dockerized environment. Negative rate values were seen because 
> read/write counters were dropping below the previous values at random times. 
> On further investigation, it revealed that this was due to the docker volume 
> groups present on the host. It is expected of docker containers to add/remove 
> the volume groups during the lifecyle of a container. So, when a volume group 
> goes away, the read/write counters do not contribute to the total counter 
> values, thus making the value go below the last seen value.
> 
> FIX
> Have a provision to discard such "special" disk partitions through a skip 
> pattern. If skipped, they will not contribute to the global counter metric. 
> Individual disk counter metrics can be used to get disk specific counter 
> values.
> 
> 
> Diffs
> -----
> 
>   ambari-metrics/ambari-metrics-host-monitoring/conf/unix/metric_monitor.ini 
> 3e5d861 
>   
> ambari-metrics/ambari-metrics-host-monitoring/src/main/python/core/config_reader.py
>  02f0ce3 
>   
> ambari-metrics/ambari-metrics-host-monitoring/src/main/python/core/host_info.py
>  845b270 
>   
> ambari-server/src/main/resources/common-services/AMBARI_METRICS/0.1.0/configuration/ams-env.xml
>  4135d32 
>   
> ambari-server/src/main/resources/common-services/AMBARI_METRICS/0.1.0/package/scripts/params.py
>  2503c43 
>   
> ambari-server/src/main/resources/common-services/AMBARI_METRICS/0.1.0/package/templates/metric_monitor.ini.j2
>  383a0de 
> 
> Diff: https://reviews.apache.org/r/51562/diff/
> 
> 
> Testing
> -------
> 
> Manually tested.
> 
> 
> Thanks,
> 
> Aravindan Vijayan
> 
>

Reply via email to