You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@ambari.apache.org by "Robert Nettleton (JIRA)" <ji...@apache.org> on 2017/02/24 22:41:44 UTC
[jira] [Updated] (AMBARI-20190) LogSearch Integration logs repeated
WARN message that should be at DEBUG level
[ https://issues.apache.org/jira/browse/AMBARI-20190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Robert Nettleton updated AMBARI-20190:
--------------------------------------
Description:
When the LogSearch Integration layer in Ambari cannot obtain the logsearch logging metadata for a given HostComponent, it logs the following message to ambari-server.log:
{code}Error occurred while making request to LogSearch service, unable to populate logging properties on this resource{code}
The problem is that this message is logged too many times at the WARN level, without providing much useful information. In the case of a larger cluster, this message may be logged thousands of times in the ambari-server.log, and was caused by the fact that SmartSense IDs do not exist for LogSearch, since they haven't been added to the separate SmartSense stack definition.
This issue should be fixed with the following two minor changes:
1. This message should be logged at the DEBUG level, since it is generally only useful when a particular component's log messages cannot be found.
2. This message should be modified to include the Host and Component associated with the LogSearch error, to assist in debugging if this situation occurs.
was:
When the LogSearch Integration layer in Ambari cannot obtain the logsearch IDs for a given HostComponent, it logs the following message to ambari-server.log:
{code}Error occurred while making request to LogSearch service, unable to populate logging properties on this resource{code}
The problem is that this message is logged too many times at the WARN level, without providing much useful information. In the case of a larger cluster, this message may be logged thousands of times in the ambari-server.log, and was caused by the fact that SmartSense IDs do not exist for LogSearch, since they haven't been added to the separate SmartSense stack definition.
This issue should be fixed with the following two minor changes:
1. This message should be logged at the DEBUG level, since it is generally only useful when a particular component's log messages cannot be found.
2. This message should be modified to include the Host and Component associated with the LogSearch error, to assist in debugging if this situation occurs.
> LogSearch Integration logs repeated WARN message that should be at DEBUG level
> ------------------------------------------------------------------------------
>
> Key: AMBARI-20190
> URL: https://issues.apache.org/jira/browse/AMBARI-20190
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
> Affects Versions: 2.5.0
> Reporter: Robert Nettleton
> Assignee: Robert Nettleton
> Priority: Critical
> Fix For: 2.5.0
>
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> When the LogSearch Integration layer in Ambari cannot obtain the logsearch logging metadata for a given HostComponent, it logs the following message to ambari-server.log:
> {code}Error occurred while making request to LogSearch service, unable to populate logging properties on this resource{code}
> The problem is that this message is logged too many times at the WARN level, without providing much useful information. In the case of a larger cluster, this message may be logged thousands of times in the ambari-server.log, and was caused by the fact that SmartSense IDs do not exist for LogSearch, since they haven't been added to the separate SmartSense stack definition.
> This issue should be fixed with the following two minor changes:
> 1. This message should be logged at the DEBUG level, since it is generally only useful when a particular component's log messages cannot be found.
> 2. This message should be modified to include the Host and Component associated with the LogSearch error, to assist in debugging if this situation occurs.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)