I see your point Marcus.
I felt that accessing the database would be simpler but you are right that
everyone may not have access to it. Actually the CS logs do mention the host
names as well but in a different place and based on that you can match the id
to a name. For e.g. if you look for agent status logs that mentions both id and
name.
2013-07-29 10:09:47,124 DEBUG [c.c.h.Status] (AgentTaskPool-3:null)
Transition:[Resource state = Enabled, Agent event = Ping, Host id = 1, name =
xenserver-kd1]
2013-07-29 10:09:47,136 DEBUG [c.c.h.Status] (AgentTaskPool-3:null) Agent
status update: [id = 1; name = xenserver-kd1; old status = Up; event = Ping;
new status = Up; old update count = 78; new update count = 79]
2013-07-29 10:09:47,736 DEBUG [c.c.a.t.Request] (DirectAgent-24:null) Seq
1-1386348573: Sending { Cmd , MgmtId: 2546680725505, via: 1, Ver: v1, Flags:
100011,
[{"com.cloud.agent.api.StopCommand":{"isProxy":false,"executeInSequence":false,"vmName":"i-2-45-VM","wait":0}}]
}
2013-07-29 10:09:47,736 DEBUG [c.c.a.t.Request] (DirectAgent-24:null) Seq
1-1386348573: Executing: { Cmd , MgmtId: 2546680725505, via: 1, Ver: v1,
Flags: 100011,
[{"com.cloud.agent.api.StopCommand":{"isProxy":false,"executeInSequence":false,"vmName":"i-2-45-VM","wait":0}}]
}
The changes you have made would definitely improve the readability.
-Koushik
From: Marcus Sorensen [mailto:shadow...@gmail.com]
Sent: Thursday, August 01, 2013 7:26 PM
To: Koushik Das
Cc: cloudstack
Subject: Re: Review Request 13072: Print agent host name in logging of agent
commands
I agree, that would be useful.
The issue im resolving here is that 1) not everyone who has access to look at
the logs and troubleshoot also has access to (or knows the schema of) the
database. There might be an issue with a KVM host, but the admin will waste
time manually hunting down which host the command went to because he has no
idea what "via:1237" means and 2) even with db access, its a major pain to go
hunt down the unencrypted db password(because its a long string that's hard to
memorize), log into the database, run a query, just to know where to continue
your debugging.
A little background: Most of the people who surf these logs aren't devs. For us
they are usually devs, but not cloudstack devs. Maybe UI guys or some other
consumer. It has happened several times where someone comes into my office,
points out an agent command, and says "any idea where that went?". I pretty
much have the numbers memorized by now, depending on the zone, so I tell them
which agent the command went to. Then they ask me where I found that, and when
I explain that this little "via: 85" means to go log into the db and make an
SQL query for vm_instance 85, I almost always get some "gee that's useful, how
was I ever supposed to know that" response.
So I do agree that the correlations you mention would also be good, I disagree
with the idea that there is not much value in doing this.
On Aug 1, 2013 6:06 AM, "Koushik Das"
<koushik....@citrix.com<mailto:koushik....@citrix.com>> wrote:
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/13072/
The changes look fine but I don't see much value with this as the name can be
easily identified from the db. I feel the logs are used primarily for debugging
issues. And one key aspect that is missing currently is the correlation of
logs. Currently when a API call is made to MS, it traverses through various
layers in the MS and finally hitting the resource layer and then returns back
with response. Logs gets generated from each layer but it is not very intuitive
to relate them to API call. If there is a unique id (some kind of uuid) that
gets appended to the logs for a specific API call then correlation becomes very
easy.
I feel adding these kind of correlation would be much more useful.
- Koushik Das
On July 30th, 2013, 5:37 p.m. UTC, Marcus Sorensen wrote:
Review request for cloudstack.
By Marcus Sorensen.
Updated July 30, 2013, 5:37 p.m.
Bugs: CLOUDSTACK-3872
Repository: cloudstack-git
Description
Print agent name when logging Commands sent to VM hosts. See bug description.
I'm not super familiar with this code, so I'd like someone to look over it and
verify it's the right thing.
Testing
Tested on KVM zone, need help testing others.
Diffs
* core/src/com/cloud/agent/transport/Request.java (b0fa4cc)
* server/src/com/cloud/agent/manager/AgentManagerImpl.java (b157838)
View Diff<https://reviews.apache.org/r/13072/diff/>
