You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cloudstack.apache.org by Koushik Das <ko...@citrix.com> on 2013/08/01 14:06:55 UTC
Re: Review Request 13072: Print agent host name in logging of agent commands
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/13072/#review24435
-----------------------------------------------------------
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 30, 2013, 5:37 p.m., Marcus Sorensen wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/13072/
> -----------------------------------------------------------
>
> (Updated July 30, 2013, 5:37 p.m.)
>
>
> Review request for cloudstack.
>
>
> 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.
>
>
> Diffs
> -----
>
> core/src/com/cloud/agent/transport/Request.java b0fa4cc
> server/src/com/cloud/agent/manager/AgentManagerImpl.java b157838
>
> Diff: https://reviews.apache.org/r/13072/diff/
>
>
> Testing
> -------
>
> Tested on KVM zone, need help testing others.
>
>
> Thanks,
>
> Marcus Sorensen
>
>
Re: Review Request 13072: Print agent host name in logging of agent commands
Posted by Prasanna Santhanam <ts...@apache.org>.
> On Aug. 1, 2013, 12:06 p.m., Koushik Das wrote:
> > 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.
I disagree on this slightly. Snooping into the db for debugging should be gradually deprecated as a practice. Have you ever needed to look into the xen datastore for finding something? The point is admins map their hostnames to DNS addresses in datacenters and having via: 15 (representation of cloudstack) in the debug log is less intuitive compared to having command via kvm-host-0102. If I see command X failed on the kvm-host-0102 all I'll do as an admin of the cloud would be to inspect kvm-host-0102 over ssh. If you have 14 there I'll go to w3schools.com and start learning SQL :)
- Prasanna
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/13072/#review24435
-----------------------------------------------------------
On July 30, 2013, 5:37 p.m., Marcus Sorensen wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/13072/
> -----------------------------------------------------------
>
> (Updated July 30, 2013, 5:37 p.m.)
>
>
> Review request for cloudstack.
>
>
> 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.
>
>
> Diffs
> -----
>
> core/src/com/cloud/agent/transport/Request.java b0fa4cc
> server/src/com/cloud/agent/manager/AgentManagerImpl.java b157838
>
> Diff: https://reviews.apache.org/r/13072/diff/
>
>
> Testing
> -------
>
> Tested on KVM zone, need help testing others.
>
>
> Thanks,
>
> Marcus Sorensen
>
>
RE: Review Request 13072: Print agent host name in logging of agent
commands
Posted by Alex Huang <Al...@citrix.com>.
Yes. I like the idea but we should just load the hostname during the attache's creation rather than on every communication.
--Alex
> -----Original Message-----
> From: Chiradeep Vittal
> Sent: Thursday, August 1, 2013 11:20 PM
> To: dev@cloudstack.apache.org; Marcus Sorensen
> Cc: cloudstack; Alex Huang
> Subject: Re: Review Request 13072: Print agent host name in logging of agent
> commands
>
> This of course introduces an extra DB call during EVERY agent communication.
> If there was a cache, not a big deal, but as it so happens, there isn't one.
>
> On 8/1/13 10:10 PM, "Koushik Das" <ko...@citrix.com> wrote:
>
> >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,"executeInSequen
> ce
> >":f alse,"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,"executeInSequen
> ce
> >":f alse,"vmName":"i-2-45-VM","wait":0}}] }
> >
> >
> >The changes you have made would definitely improve the readability.
> >
> >-Koushik
> >
> >From: Marcus Sorensen [mailto:shadowsor@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"
> ><ko...@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/>
> >
> >
Re: Review Request 13072: Print agent host name in logging of agent commands
Posted by Marcus Sorensen <sh...@gmail.com>.
Yes, I thought of that, which is one of the reasons I asked for feedback.
I'm not quite sure how to do it the was Alex suggests, but I'll look into
it. I'm guessing some sort of id to hostname map that populates as attaches
are created.
On Aug 2, 2013 12:19 AM, "Chiradeep Vittal" <Ch...@citrix.com>
wrote:
> This of course introduces an extra DB call during EVERY agent
> communication.
> If there was a cache, not a big deal, but as it so happens, there isn't
> one.
>
> On 8/1/13 10:10 PM, "Koushik Das" <ko...@citrix.com> wrote:
>
> >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":f
> >alse,"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":f
> >alse,"vmName":"i-2-45-VM","wait":0}}] }
> >
> >
> >The changes you have made would definitely improve the readability.
> >
> >-Koushik
> >
> >From: Marcus Sorensen [mailto:shadowsor@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"
> ><ko...@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/>
> >
> >
>
>
Re: Review Request 13072: Print agent host name in logging of agent
commands
Posted by Chiradeep Vittal <Ch...@citrix.com>.
This of course introduces an extra DB call during EVERY agent
communication.
If there was a cache, not a big deal, but as it so happens, there isn't
one.
On 8/1/13 10:10 PM, "Koushik Das" <ko...@citrix.com> wrote:
>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":f
>alse,"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":f
>alse,"vmName":"i-2-45-VM","wait":0}}] }
>
>
>The changes you have made would definitely improve the readability.
>
>-Koushik
>
>From: Marcus Sorensen [mailto:shadowsor@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"
><ko...@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/>
>
>
RE: Review Request 13072: Print agent host name in logging of agent
commands
Posted by Koushik Das <ko...@citrix.com>.
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:shadowsor@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" <ko...@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/>
Re: Review Request 13072: Print agent host name in logging of agent commands
Posted by Marcus Sorensen <sh...@gmail.com>.
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" <ko...@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/>
>