Return-Path: X-Original-To: apmail-incubator-cloudstack-dev-archive@minotaur.apache.org Delivered-To: apmail-incubator-cloudstack-dev-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 04582DC37 for ; Mon, 11 Mar 2013 04:52:13 +0000 (UTC) Received: (qmail 12319 invoked by uid 500); 11 Mar 2013 04:52:12 -0000 Delivered-To: apmail-incubator-cloudstack-dev-archive@incubator.apache.org Received: (qmail 12173 invoked by uid 500); 11 Mar 2013 04:52:11 -0000 Mailing-List: contact cloudstack-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: cloudstack-dev@incubator.apache.org Delivered-To: mailing list cloudstack-dev@incubator.apache.org Received: (qmail 12148 invoked by uid 99); 11 Mar 2013 04:52:10 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 11 Mar 2013 04:52:10 +0000 X-ASF-Spam-Status: No, hits=-2.3 required=5.0 tests=RCVD_IN_DNSWL_MED,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of anshul.gangwar@citrix.com designates 203.166.19.134 as permitted sender) Received: from [203.166.19.134] (HELO SMTP.CITRIX.COM.AU) (203.166.19.134) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 11 Mar 2013 04:52:04 +0000 X-IronPort-AV: E=Sophos;i="4.84,819,1355097600"; d="scan'208";a="1362792" Received: from banpmailmx02.citrite.net ([10.103.128.74]) by SYDPIPO01.CITRIX.COM.AU with ESMTP/TLS/RC4-MD5; 11 Mar 2013 04:51:41 +0000 Received: from BANPMAILBOX01.citrite.net ([10.103.128.71]) by BANPMAILMX02.citrite.net ([10.103.128.74]) with mapi; Mon, 11 Mar 2013 10:21:39 +0530 From: Anshul Gangwar To: Alex Huang CC: "cloudstack-dev@incubator.apache.org" Date: Mon, 11 Mar 2013 10:21:38 +0530 Subject: Re: [DISCUSS] Syslog enhancements Thread-Topic: [DISCUSS] Syslog enhancements Thread-Index: Ac4eFB34lm2ryEwsQxqfQAni6aK+1w== Message-ID: <513D62DA.2070103@citrix.com> References: <6E004C34C1C59E45A35B4338808BC315013014D30E11@SJCPMAILBOX01.citrite.net> <35F04D4C394874409D9BE4BF45AC5EA9010B2854BA56@BANPMAILBOX01.citrite.net> <35237635-367F-4535-834D-E130E7DB6ACD@stratosec.co> <35F04D4C394874409D9BE4BF45AC5EA9010B2854C016@BANPMAILBOX01.citrite.net> <35F04D4C394874409D9BE4BF45AC5EA9010B2854C038@BANPMAILBOX01.citrite.net> <6E004C34C1C59E45A35B4338808BC315013014D3190E@SJCPMAILBOX01.citrite.net> <51382DAA.8030008@citrix.com> <51397DE3.70503@citrix.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130221 Thunderbird/17.0.3 acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Virus-Checked: Checked by ClamAV on apache.org Because of the class, from which I am getting alerts is present in=20 com.cloud.alert package. Thanks, Anshul On 08/03/13 18:19, Alex Huang wrote: > Why not org.apache.cloudstack.alert? It is an apache project. > > --Alex > >> -----Original Message----- >> From: Anshul Gangwar >> Sent: Thursday, March 7, 2013 9:58 PM >> To: Alex Huang >> Cc: cloudstack-dev@incubator.apache.org >> Subject: Re: [DISCUSS] Syslog enhancements >> >> Hi Alex, >> >> I will change it to package level then i.e. *com.cloud.alert *instead of >> *com.cloud.alert.AlertManagerImpl*. >> >> Thanks, >> Anshul >> On 08/03/13 06:24, Alex Huang wrote: >>> Anshul, >>> >>> Like the FS. The only thing I have is it's probably better to have us = actually >> change the log category to something like org.apache.cloudstack.alerts. = It >> takes a little code change but would make much more sense that >> AlertManagerImpl. >>> --Alex >>> >>>> -----Original Message----- >>>> From: Anshul Gangwar [mailto:anshul.gangwar@citrix.com] >>>> Sent: Wednesday, March 6, 2013 10:03 PM >>>> To: cloudstack-dev@incubator.apache.org >>>> Subject: Re: [DISCUSS] Syslog enhancements >>>> >>>> As per discussion I have created the FS for this feature at >>>> >> https://cwiki.apache.org/confluence/display/CLOUDSTACK/FS+for+Syslog+ >>>> E >>>> nhancements. >>>> This will use the log4j appender to send the syslog messages. >>>> >>>> Thanks, >>>> Anshul >>>> On 09/01/13 07:22, Hari Kannan wrote: >>>>> Hi, >>>>> >>>>> The core requirements I see are >>>>> >>>>> - Write to local - in syslog format >>>>> >>>>> - Send to remote sylog server >>>>> >>>>> - write the messages with appropriate Log level/priority in = syslog >>>> format >>>>> If log4j appender could do it, we certainly should consider/leverage >>>>> that - >>>> I'm not an expert on this, is this something that can be automated >>>> when we install CloudStack? >>>>> Hari >>>>> >>>>> -----Original Message----- >>>>> From: David Nalley [mailto:david@gnsa.us] >>>>> Sent: Tuesday, January 8, 2013 9:17 AM >>>>> To:cloudstack-dev@incubator.apache.org >>>>> Subject: Re: [DISCUSS] Syslog enhancements >>>>> >>>>> On Tue, Jan 8, 2013 at 12:12 PM, Ram Ganesh >>>> wrote: >>>>>>> -----Original Message----- >>>>>>> From: Alex Huang [mailto:Alex.Huang@citrix.com] >>>>>>> Sent: 08 January 2013 22:10 >>>>>>> To:cloudstack-dev@incubator.apache.org >>>>>>> Subject: RE: [DISCUSS] Syslog enhancements >>>>>>> >>>>>>> Ram and Hari, >>>>>>> >>>>>>> I continue to have trouble with this feature. What I'm used to >>>>>>> seeing in syslogs are not the things that are being described here. >>>>>>> They're usually some log level of an application. If there are >>>>>>> system events that are not logged to our own logs, why not log >>>>>>> them to our own logs and use the log4j syslogappender to filter >>>>>>> them and send them to syslog. Why write something else? >>>>>>> >>>>>>> Do you have any use cases where system events should not be >> logged >>>>>>> into CloudStack's logs? >>>>>> I do not think so. I think it is just the legacy code. We >>>>>> need to ensure that those events also get logged into the log files. >>>>>> Will take the log4j syslogappender path then >>>>>> >>>>>> Thanks, >>>>>> Ram >>>>>> >>>>> So does this obviate the need for the Syslog feature itself? Can we >>>>> just >>>> make this a docs bug to document how to configure log4j? >>>>> --David