RE: Unidata, Monitoring system parameters
At the risk of making announcements too soon, I'm working on a tool right now that will do this sort of monitoring for MV environments - in collaboration with or instead of products like DPMonitor. A VAR or IT staff can automatically monitor remote client systems for OS, DBMS, or Application issues, and get notifications when action is required. This allows support providers to be more pro-active, and adds new levels of service options for everyone. Another feature will allow system updates along the lines of Symantec LiveUpdate or RedHat Network Management, and other forms of remote maintenance to eliminate the need for people to manually update hundreds of systems. There's a LOT more being built into this but it's too early to go into detail at this time. E-mail inquiries are welcome, especially from people who feel the pain of supporting a large number of sites. Tony Nebula R&D [EMAIL PROTECTED] (Moderatoring presentations at Spectrum in Las Vegas - See you there!) >-Original Message- >From: [EMAIL PROTECTED] >[mailto:[EMAIL PROTECTED] On Behalf Of Scott Richardson >Sent: Friday, February 20, 2004 5:25 PM >To: [EMAIL PROTECTED] >Cc: Alan Billing >Subject: RE: Unidata, Monitoring system parameters > > >Date: Thu, 19 Feb 2004 18:50:24 +1100 >From: "Ken Wallis" <[EMAIL PROTECTED]> >Subject: RE: Unidata, Monitoring system parameters > >> James Hogan wrote: >>>> From time to time we have customers who break a Unidata >>> parameter and the >>> program they are running will crash with errors such as "No more >>> entries in MI table in 'LCT -n'". > >>[snip] > >>> I have had a look at the commands "sms", "gstt" and "lstt". >With some >>> clever scripting these could be used to take snap shots of the >>> system periodically >>> to check for an over step of the parameters. The script could >>> then warn the user if any parameter is over 80% utilised. > >:>I doubt it could warn them in time James. When programs go >wild and eat smm >>resources they tend to do it in a big hurry. > >>With decent tuning you should be able to find a reasonable compromise >>between making lots of memory available for big jobs without >lumbering >>little jobs with a huge footprint. Even on AIX now there are some >>extended shared memory facilities which allow you to have >more segments >>instead of just making them all huge! I can't remember the exact >>details but EXTSHM rings a bell. >> >>Cheers, >>Ken > >Hello James Hogan,of Sungard and Ken Wallis, > >I have been getting the U2 Users Daily Digest for a for weeks >now, after getting individual emails for the longest time. I >just caught this thread, and had to get in on this. > >What James Hogan wants to accomplish can be done. >There are products out there such as the DPMonitor that do >exactly that. > >There are several key factors though: >1) Situations like that require constant monitoring, and >mapping out of platform operational dynamics, and knowing the >behaviors that occur when things "start to go wrong". > >2) The Monitor needs to be external to the application server >being monitored. You need a real low overhaed process (Agent) >on the Application Server doing low level kernel calls, >consistently, over time, and establish what the operational >baseline characteristics of the application are in "normal" >mode. A real key is having that Agent talking to an >"Operations Console" Performance Explorer and Alert Center, >and having Probes, or Alarms set up, to notify Operations in >things get out of whack, and therefore allow corrective action >to take place before the application server or process gets >"hung". Imagine that - a proactive response as compared to a >reactive response. > >3) You can't run such standard system >commands/programs/utilities, especially ones on the >application server being monitored, as they consume >significant volumes of resources, and contribute to the >problem, if they ever report back to you, (such as Ken mentions). > >So, what do you do? Reinvent the wheel with some configuration >of scripts? > >The smart choice is to download and evaluate the DPMonitor >Performance Monitoring Solution. The licensed version will >monitor individual, user-selected processes, in addition to >the system wide parameters and metrics. You can set up Probes >to test and watch for certian conditions or thresholds to be >crossed, and then take pro-active, pre-programmed by the user >responses to those situations,
RE: Unidata, Monitoring system parameters
Date: Thu, 19 Feb 2004 18:50:24 +1100 From: "Ken Wallis" <[EMAIL PROTECTED]> Subject: RE: Unidata, Monitoring system parameters > James Hogan wrote: >>> From time to time we have customers who break a Unidata >> parameter and the >> program they are running will crash with errors such as "No >> more entries in >> MI table in 'LCT -n'". >[snip] >> I have had a look at the commands "sms", "gstt" and "lstt". >> With some clever >> scripting these could be used to take snap shots of the >> system periodically >> to check for an over step of the parameters. The script could >> then warn the user if any parameter is over 80% utilised. :>I doubt it could warn them in time James. When programs go wild and eat smm >resources they tend to do it in a big hurry. >With decent tuning you should be able to find a reasonable compromise >between making lots of memory available for big jobs without lumbering >little jobs with a huge footprint. Even on AIX now there are some extended >shared memory facilities which allow you to have more segments instead of >just making them all huge! I can't remember the exact details but EXTSHM >rings a bell. > >Cheers, >Ken Hello James Hogan,of Sungard and Ken Wallis, I have been getting the U2 Users Daily Digest for a for weeks now, after getting individual emails for the longest time. I just caught this thread, and had to get in on this. What James Hogan wants to accomplish can be done. There are products out there such as the DPMonitor that do exactly that. There are several key factors though: 1) Situations like that require constant monitoring, and mapping out of platform operational dynamics, and knowing the behaviors that occur when things "start to go wrong". 2) The Monitor needs to be external to the application server being monitored. You need a real low overhaed process (Agent) on the Application Server doing low level kernel calls, consistently, over time, and establish what the operational baseline characteristics of the application are in "normal" mode. A real key is having that Agent talking to an "Operations Console" Performance Explorer and Alert Center, and having Probes, or Alarms set up, to notify Operations in things get out of whack, and therefore allow corrective action to take place before the application server or process gets "hung". Imagine that - a proactive response as compared to a reactive response. 3) You can't run such standard system commands/programs/utilities, especially ones on the application server being monitored, as they consume significant volumes of resources, and contribute to the problem, if they ever report back to you, (such as Ken mentions). So, what do you do? Reinvent the wheel with some configuration of scripts? The smart choice is to download and evaluate the DPMonitor Performance Monitoring Solution. The licensed version will monitor individual, user-selected processes, in addition to the system wide parameters and metrics. You can set up Probes to test and watch for certian conditions or thresholds to be crossed, and then take pro-active, pre-programmed by the user responses to those situations, or simply generate an email, a page, or what have you. DPMonitor has Performance Agents for AIX, Solaris, and Windows. Even an Oracle Agent. U2 Products and applications can be monitored via individual per process monitoring. One Performance Explorer can display Agent data from all Agents, for centralized Enterprise, or ASP providers. Very easily installed and set up, and provides dynamic scaling, colorful, detail graphs of the health and resource level consumption of the application server platform, history of resource consumption, aggregation, and user-selectable timeframe periods for display. Dial right into problems situations quickly and easily and understand exactly what is going on, when it happens, and what ripple affects it causes in paltform operational dymanics. Real easy to solve the problems if you have a clear roadmap. DPMonitor provides that roadmap, at reasonable pricing. Check out the significantly updated www.deltek.us websoyte for product information and examples of how the DPMonitor could be easily & quickly setup to provide exactly the type of application server monitoring James at Sungard was asking about. Regards, Scott Richardson Senior Systems Engineer / Consultant Marlborough, MA 01752 Email: [EMAIL PROTECTED] Web: http://home.comcast.net/~CheetahFTL/CC eFax: 208-445-1259 -- u2-users mailing list [EMAIL PROTECTED] http://www.oliver.com/mailman/listinfo/u2-users
RE: Unidata, Monitoring system parameters
James Hogan wrote: >> From time to time we have customers who break a Unidata > parameter and the > program they are running will crash with errors such as "No > more entries in > MI table in 'LCT -n'". [snip] > I have had a look at the commands "sms", "gstt" and "lstt". > With some clever > scripting these could be used to take snap shots of the > system periodically > to check for an over step of the parameters. The script could > then warn the user if any parameter is over 80% utilised. I doubt it could warn them in time James. When programs go wild and eat smm resources they tend to do it in a big hurry. With decent tuning you should be able to find a reasonable compromise between making lots of memory available for big jobs without lumbering little jobs with a huge footprint. Even on AIX now there are some extended shared memory facilities which allow you to have more segments instead of just making them all huge! I can't remember the exact details but EXTSHM rings a bell. Cheers, Ken -- u2-users mailing list [EMAIL PROTECTED] http://www.oliver.com/mailman/listinfo/u2-users
