<html><head><style type="text/css"><!-- DIV {margin:0px;} --></style></head><body><div style="font-family:arial,helvetica,sans-serif;font-size:12pt"><div>I would certainly vote to return some running statistics from our servers, especially the region server.<br><br>Returning some of the things we display on the console now is a good start. Beyond that, we could consider items which help in understanding some of the differences we see in our testing. Perhaps number of scripts, prims & textures loaded. A count of errors or exceptions could help us. Things like that.<br><br>Charles<br></div><div style="font-family: arial,helvetica,sans-serif; font-size: 12pt;"><br><div style="font-family: arial,helvetica,sans-serif; font-size: 13px;"><font size="2" face="Tahoma"><hr size="1"><b><span style="font-weight: bold;">From:</span></b> Sean Dague <sdague@gmail.com><br><b><span style="font-weight: bold;">To:</span></b>
opensim-dev@lists.berlios.de<br><b><span style="font-weight: bold;">Sent:</span></b> Wednesday, December 17, 2008 6:34:15 PM<br><b><span style="font-weight: bold;">Subject:</span></b> [Opensim-dev] service monitoring for opensim<br></font><br>
I've been poking around recently on ways to do service monitoring of<br>OpenSim via reasonably stately requests. The idea here is to make some<br>standard recipes for how one could use things like nagios, or other<br>standard management frameworks to keep track of opensim, and let you<br>know when things have gone wrong.<br><br>For monitoring the simulator there is currently:<br><br><a href="http://server:port/simstatus/" target="_blank">http://server:port/simstatus/</a><br><br>Which returns "OK" or doesn't. It's not a very robust check, but it's<br>workable enough. :) It at least tells you if the sim is deadlocked or not.<br><br>On the grid services side I was looking for lowload function calls,<br>preferably REST, that can be used to the same avail.<br><br>For the grid server:<br><br><a href="http://host:gridport/sims/UUID-of-known-sim" target="_blank">http://host:gridport/sims/UUID-of-known-sim</a><br><br>works pretty well.
It's a single db lookup, and returns a small amount<br>of data.<br><br>For the user server:<br><br><a href="http://host:userport/get_grid_info" target="_blank">http://host:userport/get_grid_info</a><br><br>fits the bill.<br><br>For the asset server:<br><br><a href="http://host:assetport/assets/ec4b9f0b-d008-45c6-96a4-01dd947ac621" target="_blank">http://host:assetport/assets/ec4b9f0b-d008-45c6-96a4-01dd947ac621</a><br><br>works well. For those wondering, that's returning the texture on the<br>moon, which is a hard coded uuid in the client, so something every grid<br>should have.<br><br>Inventory and Messaging servers aren't quite as simple, as there isn't a<br>quick and easy REST call on either. While it would be possible to<br>create a faked xml-rpc set of requests, I'm hoping to avoid that if<br>possible.<br><br>Question:<br><br>What do people think of adding some easy REST interfaces to the<br>Messaging and Inventory services that are
like the /simstatus/ call?<br>Are there other alternatives we should be using here? Does anyone else<br>have other thoughts on sane ways to service monitor these environments?<br><br> -Sean<br><br>-- <br>Sean Dague / Neas Bade<br><a ymailto="mailto:sdague@gmail.com" href="mailto:sdague@gmail.com">sdague@gmail.com</a><br><a href="http://dague.net" target="_blank">http://dague.net</a><br><br><br></div></div></div></body></html>