Does BOXI 3.1 (windows) have any type of built-in functionality that would alert me (via email, call/beeping etc.) when a BO Server or Service goes down OR if a server & service does not come up after a certain period of time?
As an example, if my Web Intelligence Job Server suddenly goes into a stopped status (but is being restarted), I want to be notified immediately of that that server has gone into a stopped and/or disabled status (ie. notify me with the āTypeā of Server/service, and the name of that server/service).
Iāve looked, and I havenāt found anything in XI that can/will do this. I find it hard to believe that BO has not included this functionality within theyāre product (but then Iāve seen BO skip other normal/typical needed functionalitys too, so maybe they skipped this one as well).
We had the same challenge. So I found some windows batch files that check the status of a service. I coded those batch files into a set of scripts that run each hour and check the status of all services and if a service is down, it will send an e-mail notification as well as try and restart the service. You can download the scripts and instructions from this BOBās Downloads post:
Yeah, youāre right. Iāve been playing with XI 3.1, but havenāt gone production with it yet. I looked at the services list and behold they are not running the individual components as services. Has anyone had a problem with report or job servers just up and quitting?
Hi, we are in production and have been seeing servers stalled in a status of āstoppingā It looks to be fixed in fixpack 1.5 (tested it on dev ok, hope to install on prod thias week).
There is a thread on this on the forum somewhere already
So I take it, no one (yet) has heard and/or found a way to dynamically monitor & alert when any BO 3.1 Servers (and/or āvirtualā Services) go down??
If anyone hears of anything, please let BOB (and hopefully myself) know asap!!!
What we have followed at our XI 3.0 installation is this:
a) Create a set of WebI reports that run against individual source systems. We have 10 different sources and thus 10 individual WebI Reports.
b) The reports are scheduled to run every 3 minutes (you can increase or decrease this). Report is scheduled to be outputted as Webi report on server and instance limit is set to 5.
c) Inside Scheduling a Notification is added when the job FAILS to run. A set of Admins are sent a note via email that the particular report did not run.
We have gone with 10 reports as we connect to different sources. If 1 of them is unavialble the error report tells us before an end user runs into any issue.
The report check essentially checks for Webi Report server (the processing tier), and Webi JOb server (for Scheduling). Ours is a heavy Webi environment and hence we went by this approach. If you use Crystal or DeskI more you should follow the same procedure but build the reports in DeskI.
Thats not a bad idea. However, I see one flaw in that strategy. If the Webi Job Server goes down, then none of your report(s) will run at all, there-by you will never get an email telling you that the Webi Job Server is down (because all the Webi reports need that particular server to be up in order to run).
Anyone have any ideaās of how to test & alert if/when a Webi, deski, or Crystal Job Server goes down?
Thanks for the good idea though, its a start down the right road at leastā¦
We faced the issue with the Webi Processing Servers as the load increased on the system. Firstly we went from one to two, then finally to four of these to better handle the load.
However, even with four of these servers running they would sometimes not re-start properly when they go through their periodic re-cycle. This is just annoying because one day you find you are running on 3 not 4, a couple of days later you could be running with just 2 etc. until you hit problems from the users. As there is no easy way to alert for this you donāt really see the issue until it is too late.
So, our pre-emptive action is to kill all Webi-processing servers once a day and then they re-start automatically. We seem to last 24 hours without hitting the automatic re-start limit so this works well for us even though it is not pretty.
Weāre still on XIr2, and we had problems with services going down unexpectedly during the night, resulting on a mass of reporting failures in the morning.
We wrote a few batch scripts, and also used the examples taken from a link on this thread; but it wasnāt always satisfactory.
As a consequence we had to resort to 3rd party software such as MOM (Message orientated Middleware), and Microsoft Message Queuing, in Particular.
Fiddly to setup but does a great job alerting individuals (either by email or sms) of when a service or server goes belly up
Fair point that. To avoid such scenario we have another job that spits an indicator file on a Network drive. A batch job on the drive looks for that indicator file every xx minutes and if it does not find the file it automatically sends a note to the responsible people.
However we have never had to use this alternative. The Webi report alert does it for us every time simply because at our installation the biggest show stopper has been Webi Report server that goes down (mostly for Memory full error), Job server has really never given us any error. Your installation of course could be different.
It might be just me, but I have found the Business Objects services are very stable. We have been on XI for almost 4 years and the Business Objects services have never gone down by themselves.
The only service that has gone down many times was the CMS. But the problem was on the database side. Therefore, we have developed some scripts to monitor the database availability instead.
BO_TN, if your webi server goes down very often because of memory problem, you might want to consider scaling out.
The problem, for us, was the sheer hardware resources(or lack thereof) we had at our disposal. We had 1.5 CPU and 4 GB RAM total to run on a 32 bit machine for an Enterprise wise installation of XI 3.1. The number of users was about 400 and concurrent users were about 50. The limitation of hardware did hamper us a lot. It also benefitted us in extracting the maximum bang for the buck and coming up with solutions as suggested above.
50 concurrent users is really not much. But of course it depends on how much data are they pulling across.
I am a firm believer of āyou get exactly what you are paying forā. If your users demand high performance, they have to flip the bills. You cannot expect a Corvette performance if you are only paying a Corolla price.
(BOB member since 2006-10-03)
(BOB member since 2006-12-18)
(BOB member since 2007-01-18)
(BOB member since 2002-06-18)