<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 12pt;
font-family:Calibri
}
--></style></head>
<body class='hmmessage'><div dir='ltr'><div><br></div><div>> - Specific user oriented log messages (distinct from our normal operator logs)</div><div>> - Deprecation messages (if they are using old resource properties/template features)</div><div>> - Progress and resource state changes (an application doesn't want to poll an api for a state change)<br></div><div>> - Automated actions (autoscaling events, time based actions)</div><div>> - Potentially integrated server logs (from in guest agents)</div><br>is the idea that Heat would build events from the logs or would you want to send the log messages to another service to be process? so for example, Nova doesn't send all logs messages to the queue but they do send a set of messages relating to certain actions and errors that occur (beyond just CRUD events). as the use cases above seem to target specific actions/logs and not all logs, i would think the processing could be done on the initiators service end and not on the consumer end.<br><br>to give an example of what Ceilometer is capable of; Ceilometer currently takes JSON messages from the MQ from *most* services and from there we capture the entire raw notification and index on a select set of key-value pairs. i think it's entirely possible to take in non-json log messages and build an indexer around that if needed.<br><br><font style="" face="Calibri">cheers,<br><i>gord</i></font><br><br><br><div><hr id="stopSpelling">Date: Tue, 7 Apr 2015 12:55:37 +1000<br>From: asalkeld@mirantis.com<br>To: openstack-dev@lists.openstack.org<br>Subject: [openstack-dev] [all] how to send messages (and events) to our users<br><br><div dir="ltr">Hi all<div><br></div><div>For quite some time we (Heat team) have wanted to be able to send messages to our</div><div>users (by user I do not mean the Operator, but the User that is interacting with the client).</div><div><br></div><div><div>What do I mean by "user messages", and how do they differ from our current log messages</div><div>and notifications?</div></div><div>- Our current logs are for the operator and have information that the user should not have</div><div> (ip addresses, hostnames, configuration options, other tenant info etc..)</div><div>- Our notifications (that Ceilometer uses) *could* be used, but I am not sure if it quite fits. </div><div> (they seem a bit heavy weight for a log message and aimed at higher level events)</div><div><br></div><div>These messages could be (based on Heat's use case):</div><div><br></div><div>- Specific user oriented log messages (distinct from our normal operator logs)</div><div>- Deprecation messages (if they are using old resource properties/template features)</div><div>- Progress and resource state changes (an application doesn't want to poll an api for a state change)<br></div><div>- Automated actions (autoscaling events, time based actions)</div><div>- Potentially integrated server logs (from in guest agents)</div><div><br></div><div>I wanted to raise this to "[all]" as it would be great to have a general solution that </div><div>all projects can make use of.</div><div><br></div><div>What do we have now:<br></div><div>- The user can not get any kind of log message from services. The closest thing</div><div> ATM is the notifications in Ceilometer, but I have the feeling that these have a different aim.</div><div>- nova console log</div><div>- Heat has a DB "event" table for users (we have long wanted to get rid of this)</div><div><br></div><div>What do other clouds provide:</div><div>- <a href="https://devcenter.heroku.com/articles/logging" target="_blank">https://devcenter.heroku.com/articles/logging</a></div><div>- <a href="https://cloud.google.com/logging/docs/" target="_blank">https://cloud.google.com/logging/docs/</a></div><div>- <a href="https://aws.amazon.com/blogs/aws/cloudwatch-log-service/" target="_blank">https://aws.amazon.com/blogs/aws/cloudwatch-log-service/</a></div><div>- <a href="http://aws.amazon.com/cloudtrail/" target="_blank">http://aws.amazon.com/cloudtrail/</a></div><div>(other examples...)</div><div><br></div><div>What are some options we could investigate:</div><div>1. remote syslog</div><div> The user provides a rsyslog server IP/port and we send their messages to that.</div><div> [pros] simple, and the user could also send their server's log messages to the same</div><div> rsyslog - great visibility into what is going on.</div><div><br></div><div> There are great tools like loggly/logstash/papertrailapp that source logs from remote syslog</div><div> It leaves the user in control of what tools they get to use.</div><div><br></div><div> [cons] Would we become a spam agent (just sending traffic to an IP/Port) - I guess that's how remote syslog</div><div> works. I am not sure if this is an issue or not?</div><div><br></div><div> This might be a lesser solution for the use case of "an application doesn't want to poll an api for a state change"</div><div><br></div><div> I am not sure how we would integrate this with horizon.</div><div><br></div><div>2. Zaqar</div><div> We send the messages to a queue in Zaqar.</div><div> [pros] multi tenant OpenStack project for messaging!</div><div><br></div><div> [cons] I don't think Zaqar is installed in most installations (tho' please correct me here if this</div><div> is wrong). I know Mirantis does not currently support Zaqar, so that would be a problem for me.</div><div><br></div><div> There is not the level of external tooling like in option "1" (logstash and friends)</div><div><br></div><div>3. Other options:</div><div> Please chip in with suggestions/links!</div><div> <br></div><div><br></div><div><a href="https://blueprints.launchpad.net/heat/+spec/user-visible-logs" target="_blank">https://blueprints.launchpad.net/heat/+spec/user-visible-logs</a><br></div><div><br></div><div><br></div><div>Regards</div><div>Angus</div><div><br></div><div><br></div><div><br></div></div>
<br>__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</div> </div></body>
</html>