MySQL Bugs: #41249: lua memory usage graph stops populating after agent re-install

Bug #41249	lua memory usage graph stops populating after agent re-install
Submitted:	5 Dec 2008 5:42	Modified:	21 Jul 2009 15:17
Reporter:	Gary Whizin	Email Updates:
Status:	Closed	Impact on me:	None
Category:	MySQL Enterprise Monitor: Server	Severity:	S3 (Non-critical)
Version:	2.0.0.7105	OS:	Any
Assigned to:	Darren Oldag	CPU Architecture:	Any

Description:
Data in the new agent resource usage graphs (CPU, RAM) stops after you do a full install of a new agent monitoring the same DB. This is a very common operation as users/testers try agent after agent (for example, while helping us track down agent RAM or CPU problems). 

It's very helpful to see usage history across agent versions and, in fact, you see  that for all graphs except the new resource metric ones.

Workaround: probably works OK if you run the upgrade installer (or it would probably also work to plug in the old agent UUID if you do a full install).

How to repeat:
1. install an agent
2. load the lua memory graph (or the new bundle that includes the new agent resource usage graphs)
3. wait for the graph populate (so far so good)
4. stop the agent
5. use full installer & start new agent version (replaces prior one). Note: new UUID for agent, same UUID for DB

The new agent graphs (CPU, memory) don't populate

Diego Medina writes: 
This bug is still present on 2.1 and as I test only fresh installs of the agent, to compare how they work over time, I cannot use the upgrade installer.
Please look into this bug.

Darren Oldag writes: 
This is a bigger systemic problem to changing 'related' objects around a MySQL server.

rule and graph data collections are bound to their instance variables at server discovery or rule schedule time.  currently, this binding is never again looked at after a server exists.  for rules, you could unschedule/reschedule the rules for a brute force solution.  or, delete the MySQL server from the dashboard and let it rediscover.  but those options suck.

so, itis not just graphs, and not just agents.  if the operating system 'host' changes for a given mysqld (which is uniquely identified by his uuid), then we will lose os::host binding and graphs will be wrong and rules will be wrong.  so our plan for keeping a mysqld identity tied to the mysql... is broken.

this can be fixed by adding some rebind logic when the transport (agent) and/or host changes on a given mysqld server.  what will happen though is... you will only see graph data for the NEW objects from the time the NEW object is reported.  we do not combine 'old' agent/os data with the 'new' agent/os data since they are distinctly separate objects.

Keith Russell writes: 
Patch applied in versions => 2.1.0.1074.

Diego Medina writes: 
Verified fixed on 2.1.0.1074

Notes: Your old graph information will not be shown any more, you will only see graph data from the time you install your new agent.

An entry was added to the 2.1.0 changelog:

Data in the agent resource usage graphs (CPU, RAM) stopped after a full install of a new agent monitoring the same database was carried out. Usage history was available across agent versions for all graphs except the agent resource usage graphs.