Yesterday morning, 9/21, we had a visit from Uri Livnat, Ex Libris 'Infrastructure Director'. Uri is visiting several US Ex Libris customer sites this week to share information about Ex Libris' new Aleph 'Monitor' product, and to get feedback from current Ex Libris customers about additional system monitoring capabilities that customers would like to have added to Monitor.

Of course, PALNI Staff developed their own own home-grown system monitoring system to automatically monitor various system resources and processes, log information about system problems, and notify staff via email and pager about serious problems. Uri's visit gave staff a chance to compare our own home-grown system to Ex Libris' commercial product offering in this area.

Speaking for myself, I was reasonably impressed with Uri's demo of Monitor. Their system seems capable of monitoring most of the things in Aleph that we are currently monitoring, though it does not monitor non-Aleph things like computer room temperature, power outages, and network problems, nor does it currently monitor OPAC response times like our own system. However, for Aleph-specific issues, just about everything we currently monitor seems covered, plus a number of other system status indicators that we are not monitoring at present. As with our home-grown system, Monitor can email and/or page us of any problems, and can maintain a system status log.

Unlike our home-grown system, Monitor has an extensive web-based user interface (though it's limited to Internet Explorer at present), and it is written in Java to run under Apache Tomcat. Overall, the system appears to be very flexible about scheduling its monitoring activities, and in deciding how/when notifications should be sent out to support staff. We gave Uri a few suggestions for additional things we would like to see monitored, and also expressed our preference for a browser-independent version of the system.

Uri could not give us any pricing information, but said he would have our Ex Libris Sales Rep contact us on that. If the cost is reasonable, this could be a worthwhile purchase for PALNI. It has the potential to make it a good deal easier to monitor our Aleph servers for problems.

NOTE: Since Uri is Ex Libris' is responsible for Ex Libris technology infrastructure decisions, we decided to demonstrate our Aleph V. 17 performance issues, and get his advice. After seeing and discussing our problems, he told us that some other Aleph users (e.g., Harvard) have also reported similar problems following their upgrade to V. 17. In some of these cases, the performance issues have been related to changes in the way keyword sorting is handled under V. 17. However, after calling and discussing things with Ex Libris technical support staff in Israel, and running some tests on our system, Uri became convinced that our response time problems are more likely a Version 17 configuration or setup issue.

While he could not say for sure what was causing the problem, he acknowledged that our Aleph response time problem definitely needs to be solved, and promised to take back what he learned about the problem to the support staff at Ex Libris. For what it's worth, he also commented that he thinks our system may not have enough memory (we currently have 6 GBytes of RAM) to support our license limit of 300 OPAC users under version 17. However, since we rarely go over about 150 OPAC users right now, he does not really think this is the cause of our particular problems. In any case, our system configuration actually exceeds what Ex Libris recommended to us when we signed our contract. Moreover, we've moved MetaLib/SFX to a separate server, so that should actually free up resources for Aleph. If our system is under-configured, that was an Ex Libris responsibility.