Monitoring Portal servers

[Former Member]

Hi,

What I expect to do here is open a thread for discussion on how to pro actively monitor portal servers?

I have tried a lot getting materials to pro actively monitor portal servers but couldnt find much.

Generally we face a issue and fix it with certain amount of down time which in turn hits buisness hours. What can we do to best get rid of this. There has been many instances in which the error produced in traces and the actual error was unrelated.

After how many days should we restart a portal server so that we can take it to a weekend date which in turn does not hit buisness hours.

Any suggestions as to how we can monitor portal servers is appreciated.

Is it that we are going to have production portals running and keep our fingers crossed, pray that it does not come up with any issue. Weird isn't it.

Thanks & Regards,

Vijith

[Former Member]

Before we had our Java engines tuned correctly, we had many random and unrelated errors due to out of memory errors. This was narrowed down to garbage collections and the engines not being sized right.

Now that they are, we are running fine. Although upper management wants the portal restarted at 4:00AM every morning, I do not feel it is necessary.

Monitoring your java memory consumption will give you a clue to if it is memory problems or not.

[markus_doehr2]

Ok.. that can be an issue. Once configured, how do you check, that your portal is "running"? Does a started /irj application imply, that the portal is running

AND WORKING

? How to verify technically if e. g. ESS/MSS (for which I don´t have permissions) is working if I can´t/shouldn´t use the logfiles? How to do the same with the BI part? As posted above, do I have a problem with BI-Java or is this once again just a log entry where developers just threw everything to the error channel?

--

Markus

[markus_doehr2]

Real world example: We are trying to implement BI planning, I got a ticket from the guy testing that, that he just get´s an "empty iview". I checked the logs and I have

epjava:etladm 14% grep -i exception *.log | wc -l

3564

epjava:etladm 15% grep -i exception *.trc | wc -l

19519

So basically I have 23083 "issues" (or not) that can be a root cause for that empty iview.

One of those exception is

#1.5^H#0013210748BF006500000099000019A2000432DF49E9EB30#1181834506005#/Applications/BI#sap.com/irj#com.sap

.ip.bi.webapplications.runtime.jsp.portal.services.BIRuntimeService#stoetzelm#26435##epjava_ETL_4921350#st

oetzelm#b0b5dd701a8a11dc9f520013210748bf#SAPEngine_Application_Thread[impl:3]_55##0#0#Fatal#1#com.sap.ip.b

i.webapplications.runtime.jsp.portal.services.BIRuntimeService#Plain###Exception caught: com.sap.ip.bi.web

applications.runtime.controller.MessageException: Error while generating HTML

com.sap.ip.bi.webapplications.runtime.controller.MessageException: Error while generating HTML

at com.sap.ip.bi.webapplications.runtime.impl.Page.processRequest(Page.java:2572)

Since "bi" is in the name of the last call I assume that this has something to do with that.

There are many many many others with "bi" in the name and also without.

How to find out the root cause as a CUSTOMER? I´m really not disposed to create OSS calls for each of those exceptions

--

Markus