Support Migration Notice: To update migrated JIRA cases click here to open a new case use www.vmware.com/go/sr | vFabric Hyperic 5.7.0 is Now Available

Hyperic HQ

HQ does not unschedule metrics determined to be coming from the wrong agent

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Minor Minor
  • Resolution: Deferred
  • Affects Version/s: 4.2.0
  • Fix Version/s: None
  • Component/s: Core Monitoring
  • Case Links:
    none
  • Regression:
    No

Description

Recently a log line was added to detect metrics coming from the wrong agent:

2010-02-03 14:52:27,571 WARN [Thread-1724] [org.hyperic.hq.measurement.server.session.ReportProcessorEJBImpl@210] measurement (id=14813) was sent to the HQ server from agent (agentToken=1265054785885-5955226501439245874-8190015691460643997) but resource (id=11018) is not associated with that agent. Dropping measurement.

In the case where a network device is reconfigured to use a different agent, the metrics scheduled on the original agent are not unscheduled causing this message to fill in the logs.

Steps to reproduce:

Agent 1 - IP 10.0.0.1
Agent 2 - IP 10.0.0.2

In this example, agent 1 is monitoring a network device at 10.0.0.111. If the user navigates to that devices inventory page and changes the agent connection from 10.0.0.1:2144 to 10.0.0.2:2144 we correctly reschedule the metrics on the new agent, but the old agent at 10.0.0.1 continues to collect these measurements. This results in the logs filling with the error noted above.

Activity

Hide
Yoav Epelman added a comment -

Bulk change to new components

Show
Yoav Epelman added a comment - Bulk change to new components
Hide
Idan Hod added a comment -

As part of our continuous effort to improve product quality, The Hyperic product team has decided to implement a "zero bug policy" methodology.

Following this methodology, only defects that are planned to be handled in the near future will remain open. Any other defect will be deferred, with the option to be reevaluated if the need arises, or if changes to the Hyperic road-map make such defect a candidate for a fix.

We believe this new process will help create clarity and focus in the Hyperic road-map and ultimately benefit our customer base.

This bug has been deferred as part of the new policy.

We appreciate your cooperation and continues contribution to the improvement of Hyperic.

Show
Idan Hod added a comment - As part of our continuous effort to improve product quality, The Hyperic product team has decided to implement a "zero bug policy" methodology. Following this methodology, only defects that are planned to be handled in the near future will remain open. Any other defect will be deferred, with the option to be reevaluated if the need arises, or if changes to the Hyperic road-map make such defect a candidate for a fix. We believe this new process will help create clarity and focus in the Hyperic road-map and ultimately benefit our customer base. This bug has been deferred as part of the new policy. We appreciate your cooperation and continues contribution to the improvement of Hyperic.

People

Vote (1)
Watch (2)

Dates

  • Created:
    Updated:
    Resolved:
    Last comment:
    41 weeks, 3 days ago