[Opensim-dev] service monitoring for opensim

[Brianna]

I use an unrefined method, besides users yelling at me.

With the existing [ llHTTPRequest(url ,[HTTP_METHOD,"GET"],""); ] I can push 
a lot of info up to my stable PHP world on the server with no sim loading.
Of course once there I can use MySql, send email, honk horns or write flat 
files to my hearts content, That keeps the talented dev team on more 
important issues.
I also use the same technique for a visitor log from prim collision, again 
avoiding scripting scanners.


----- Original Message ----- 
From: "Paul Fishwick" <fishwick at cise.ufl.edu>
To: <opensim-dev at lists.berlios.de>
Sent: Thursday, December 18, 2008 5:22 AM
Subject: Re: [Opensim-dev] service monitoring for opensim


> This sounds good - btw, is this instrumented now?  Where are the php or
> html files for simstatus, get_grid_info, etc?  As a suggestion, the
> monitoring
> might use a GUI control or does it already?
> -p
>
> Sean Dague wrote:
>> I've been poking around recently on ways to do service monitoring of
>> OpenSim via reasonably stately requests.  The idea here is to make some
>> standard recipes for how one could use things like nagios, or other
>> standard management frameworks to keep track of opensim, and let you
>> know when things have gone wrong.
>>
>> For monitoring the simulator there is currently:
>>
>> http://server:port/simstatus/
>>
>> Which returns "OK" or doesn't.  It's not a very robust check, but it's
>> workable enough. :)  It at least tells you if the sim is deadlocked or 
>> not.
>>
>> On the grid services side I was looking for lowload function calls,
>> preferably REST, that can be used to the same avail.
>>
>> For the grid server:
>>
>> http://host:gridport/sims/UUID-of-known-sim
>>
>> works pretty well.  It's a single db lookup, and returns a small amount
>> of data.
>>
>> For the user server:
>>
>> http://host:userport/get_grid_info
>>
>> fits the bill.
>>
>> For the asset server:
>>
>> http://host:assetport/assets/ec4b9f0b-d008-45c6-96a4-01dd947ac621
>>
>> works well.  For those wondering, that's returning the texture on the
>> moon, which is a hard coded uuid in the client, so something every grid
>> should have.
>>
>> Inventory and Messaging servers aren't quite as simple, as there isn't a
>> quick and easy REST call on either.  While it would be possible to
>> create a faked xml-rpc set of requests, I'm hoping to avoid that if
>> possible.
>>
>> Question:
>>
>> What do people think of adding some easy REST interfaces to the
>> Messaging and Inventory services that are like the /simstatus/ call?
>> Are there other alternatives we should be using here?  Does anyone else
>> have other thoughts on sane ways to service monitor these environments?
>>
>> -Sean
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> Opensim-dev mailing list
>> Opensim-dev at lists.berlios.de
>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>>
>
>
> -- 
> Paul Fishwick, PhD
> Professor and Director, Digital Arts and Sciences Programs
> University of Florida
> Computer & Information Science and Eng. Dept.
> Bldg. CSE, Room 301
> P.O. Box 116120
> Gainesville, FL 32611
> Email: fishwick at cise.ufl.edu
> Phone: (352) 392-1414
> Fax: (352) 392-1220
> Web: http://www.cise.ufl.edu/~fishwick
>
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev