Installation Guide |
GEM Documentation Navigation Page. Documentation is also available at The GEM Home Page. Documentation and Code are both Copyright © 1995-2006 by Sql Technologies. All Rights are Reserved.
The following guide describes how to install GEM.
If you are planning to using GEM, please contact Sql Technologies by email. We are interested in making your GEM Installation a success, and will provide installation support. We are aiming for full customer satisfaction and will work with you to make this product a success.
GEM manages your systems from central monitoring systems. A windows systems is used to manage your windows databases. A unix/linux server is used for your unix servers. If you have both (a "Hybrid Environment") windows and unix based databases, you will need 2 monitoring systems.
These systems run a lot of perl batch jobs. It is recommended that you use dedicated systems for your production GEM monitoring servers. For your initial trial setup, use a development system. On windows monitoring systems, we suggest you have access to a windows login OTHER than the login you normally use for login. On windows, scheduled GEM batch jobs might result in the pop up of dos cmd boxes (which is annoying). Scheduling the jobs using a 'batch' windows account prevents this.
You will need appropriate SQL Server and/or Sybase/Oracle client software to be installed on your monitoring servers.
Identify the directory you are going to install GEM into. This is only tricky if you have a Hybrid Environment, in which case your admins need to create a samba share such that a single directory appear in both unix/linux and windows. When GEM is installed on a samba share, the same code works unchanged to monitor both your Unix and Windows environments seamlessly.
Each monitoring station requires perl to be installed at version 5.8.1 or later. This can be verified by running the command perl -v (prints the version number).
On windows, we recommend the latest Activestate Perl from http://www.activestate.com. Use the default installation options.
On UNIX, binary releases can be downloaded from http://www.cpan.org. You can have your unix admins install/provide perl for you or can install your own version of perl in your own home directory. The second approach has the advantage that you have control, and will not need permission of the unix administrators to add/update modules.
Verify availability of the perl DBI module and associated DBD perl modules. DBI and DBD::ODBC are required on windows servers. DBI and Native DBD Drivers (DBD::Sybase, DBD::Oracle) are required for the perl on your unix monitoring servers.
On Windows, install these modules via : [StartKey] -> [Run] and then type ppm install DBI
If your company has a firewall/proxy set up such that the ppm commands fail we suggest:
Bring up a browser and go to http://ppm.activestate.com/PPMPackages/zips/ - select your version and go to the Windows subdirectoy and download the latest zip file. The file will contain 3 files when extracted - a .ppd file, a readme, and a .tar.gz file. To install this ActiveState PPM package, run the following command in the current directory:
ppm install DBD-ODBC.ppd
You should download both the DBD::ODBC and DBI libraries. The latest versions (as of October 2007 are 1.13 and 1.58 respectively.
On Unix, the DBI and DBD::Sybase modules must be installed by hand. You may also wish to install DBD::Oracle, although oracle support is currently limited with full support scheduled for 3Q08. Module installation on unix may require administrator help (the make install step requires write access to the perl library directories which are write protected unless you are using a local version of perl.
While GEM does not "technically" require running scripts on an web server, several of the interfaces were designed primarly for web access. To run these scripts, you must create a 'script enabled' directory on your web server. GEM provides perl scripts which, when deployed to this directory will provide web based features. The primary interfaces provided at this time are a monitoring and reporting tool for your database servers. You should secure this web directory as you see fit for information of that type.
GEM requires a small monitoring database. Place this database on Sybase if you have a Hybrid or Unix Only environment and on either Sybase or Microsoft SQL Server in windows only environments. This database will store enterprise monitoring information and must be accessible from all your monitoring servers. If you have Unix Systems yet wish (for some reason) to use a SQL Server as your repository, you can install FreeTds and the unix verison of DBD::ODBC.
use master
If you are trialing GEM, we recommend installing on 4-6 database servers on 4-6 separate sytems and that the trial be either 'all unix' or 'all windows' databases. You will require the following rights on these database servers:
You need windows administrator access your windows database servers
Ensure that all the database servers identified in the last step have span>ODBC entries (Windows Monitoring Box), and have appropriate Sybase interfaces file (and Oracle tnsnames.ora) entries. The configuration process (configure.pl) will automatically discover your servers based on these values.
All UNIX systems involved with GEM must be accessible from the unix monitoring system by ssh/scp (preferred method), rsh/rcp, or standard ftp. The account you will be using to schedule the batch jobs and to run gem must be able to get into these systems without passwords (except in the case of ftp where a password is ok).
monitor ebarlow: ssh sybase@sybprod
Database administrators can be, and should be, a cautious lot. We obviously roll out a tool like GEM to a single test box and install the client on our personal workstation. Lowest risk configuration and all that. An installation like that totally and completely buys you nothing. GEM will be of no value. That is totally and completely the wrong way to roll out GEM.
The correct way to roll out GEM is to implement it on between 4 and 6 test and dev servers at once using a 'server' class box as a monitoring station (it does NOT need to be a dedicated box but it runs a bunch of perl scripts). Obviously dont trial GEM on anything production (that includes your workstation). Your Trial needs this many systems to let you to see how the GEM software works. Plus, GEM is a LOT of effort to implement, so you might as well get some use out of your GEM trial.
Finally, ensure that you have defined ALL items on the GEM pre-install check list. For example, GEM loses half its value in a unix environment if you dont have 'no password' access via either ssh or rsh connectivity to your unix systems. Simarly, "ADMINSITRATOR GROUP" rights are required for direct access to your Windows servers log files. You need these. Additionally, it is highly strongly very suggested that you have a web server with a script capable directory into which you can place our cgi perl interface. While we do have a TK version of the interface, the web interface is the one you should use.
Presuming you have a reasonable network configuration, GEM has a pretty low footprint on everything but the monitoring host system. Network impact is mostly semi hourly fetches of your database error logs. GEM does install our system stored procedures on all your database servers. They are a nice package and you will like them. On the monitoring system, GEM runs a bunch of perl batch jobs - and frequently multiple jobs will run at the same time. We recommend multi processor systems as your monitoring systems, but most 2-4 year old server class systems will be fine (find some depricated system). Linux is a good choice for a monitoring system to monitor unix database.
As far as your database servers go, GEM has the experience to be a good citizen. GEM is designed by active dbas, not a lab by developers. Your developers and users should have not have any noticable degredation in performance as a result of GEM.
A good solid burn in environment for GEM should have between 4 and 6 database servers and 4 to 6 different host systems (of course nothing production should be touched). It would be slightly simpler to implement the trial if running all windows or all unix databases.
You should now download and extract the GEM software from http://www.edbarlow.com/download.pl.
You will need a passcode to download the software which can be recieved by mail from SQL Technolgies.
Extract into the directory identified in the pre-install checklist. You should need to install into only one location regardless of whether you have a hybrid or non-hybrid environment.
The GEM download file is a standard compressed tar file and can be extracted with winzip (windows), gnu tar (
Many of the GEM tools use perl/Tk for a user interface. On windows this works without support, but on unix this requires some type of X terminal manager (like exceed). On UNIX, you must set the environment variable DISPLAY correctly.
EXPORT DISPLAY=your_ip_address:0.0.
Unix users will also require an X terminal manager installed on their workstation. Your infrastructure support can help you install this if you are not allready set up.
perl troubleshoot.pl
Use the program troubleshoot.pl in the root of the installation tree to test for the presence of necessary perl libraries. troubleshoot.pl is the GEM installation trouble shooting program and it can be run to diagnose any GEM issues - a successful run indicates that your configuration is stable.
See the section on configure.pl for details on what this program does.
configure.pl is the GEM configuration utility.
This utility will build the configuration files (stored in the conf subdirectory) and runs
some basic setup tasks for GEM. The GEM Configuration Tool is quite intelligent, and will
survey your systems to give you a good baseline that should require minimal tuning to work
within your environment.
Some of the things configure.pl does include:
One primary output of configure.pl is the configuration files stored in the conf directory. These files can be hand edited once GEM is set up.
Changing the hashbangs (the first line of the file on unix is known as a hashbang and defines the command line
interpreter to use), removing Control-M (dos newline) characters from the files, and modifying library paths.
configure.pl also creates the GEM Batch Jobs. On a win32 monitoring station, GEM can
schedule these jobs. On a unix environment, we create a crontab.txt file they can be schedule via cron.
The initial database installation is done via configure.pl
This program also will generate an initial version of the GEM console and prepopulate
the alarm system with alerts and reports relevant to your environment.
perl configure.pl
If you wish to see diagnostic messages, you may run
perl configure.pl --DEBUG
A log file of the run will be placed in the logs subdirectory.
FOLLOW THE FOLLOWING STEP BY STEP INSTRUCTIONS TO COMPLETE YOUR INSTALLATION
PURPOSE: License Details and Acceptance
This tab gives licensing options for GEM. Select "I AGREE WITH THE LICENSE" to continue after you have read all the information provided when you click on the various buttons on this page.
The GEM Help button will help guide you through your install.
All GEM code is copyright (c) 1995-2007 by SQL Technologies=head1 The Register Tab
PURPOSE: Basic configuration setup plus register your product.
[This tab is trivial if you have an All Windows or All Unix environment.]
PURPOSE: Ensure Mail Connectivity
This tab is only required on Windows servers. For these servers, you need to provide your SMTP mail server name. If "Test Mail Install" should send a test message to your GEM Administrator Mail Address (entered earlier).
PURPOSE: Register your Databases & Systems with GEM
PURPOSE: Identify Database Home Directories & Important FIles
This tab contains rows for each UNIX/Linux system, listing survey results (collected earlier) in blue and configuration directives in black. If survey results look incorrect, correct the configuration directives (with the add/delete buttons) and rerun the surveys.
When completed, you consider clicking "SAVE CONFIGURATION CHANGES"=head1 The Connect Tab
PURPOSE: Test connectivity and survey your systems.
When you create your servers, it will also create two backup plans for you: one that has the same name as the server and the other which has _WEEKEND appended to the server name. Data on your plans is stored in the configure.cfg file and is hand editable. Please see documentation on the GEM Maintenance And Backup System.
PURPOSE: Define Console Special Behaviors
You may copy the files via unix copies (ssh, rsh, ftp - select the Copy using FTP button) or to a local directory (like //NEWSERVER/c$/web/gem). Some users may want to do thsi copy for security reasons - to allow non administrators to use the GEM console. This keeps those same users away from the GEM directory tree which stores other highly sensitive data.
PURPOSE: Set Up Alarms & Monitoring Systems
Now would be a good time to Save Configuration Changes!
Click the "Install Software" button to run the numbered steps listed below that button.
PURPOSE: Define Scheduling and Actually Schedule Batch Jobs
crontab -e
<vi window pops up>
:r crontab.txt
Once you are done with your GEM installation, there are a variety of post-installation tasks . This checklist is designed to help you with these tasks.
There are outstanding issues with chmod() and dos newline removal that impact Hybrid environments. Specifically, you must run configure.pl on unix AFTER you run configure.pl on windows. This is because there is no way to get windows to use just a standard newline instead of CR/newline (so all files will have a ^M in them if you run on windows last).
You should also run the Batch File creation on UNIX last. If you ran your Win32 install after your Unix install, go to your unix server and run
The password files are located in conf/*_password.dat and are hand editable.
If you add new databases or systems, recreate & reschedule your Batch Scripts. Most scripts work against all servers in the configuration files, but some scripts work on a specific database (specifically the ones with the Database name in the file name).
One of the most horrific tasks of the windows DBA is disk space cleanup. Something is *always* running out of space... GEM automates this task for you.
The file conf/Win32_Cleanup.dat contains a list of disk space Cleanup instructions for the windows cleanup batch job. It is suggested that you customize this file to include your tran/archive log directories, your application log directories, and any other directories that fill up on your systems. A best practice is to add rows to this file over time, every time the windows disk space monitor spots a directory that is filling up. The lines in this file conform to the arguments of ADMIN_SCRIPTS/bin/purge_old_files.pl, and include --hours and --days to identify the keep times, --dir to identify the directory to purge, and either --compress=
The Unix_Cleanup.dat file will control unix file/directory cleanups. It is similar to the Windows cleanup file but for the addition of the --hostname argument.
Port Monitoring is a quick availability test - and a good way to find out if a database or system is down. The file conf/port_monitor.dat contains a list of Hosts and Ports to Monitor.
This file is autogenerated by configure.pl but will probably require hand editing.
Simple format:
The File conf/Replication.dat is used by the Sybase replication server monitoring scripts and will need to be popluated with your Rep Servers and Routes.
There are two programs that check replication. The batch SybRepServerChecker will check all your rep servers to be sure that no routes are suspended, that disk space is reasonable, and that there are no other serious errors. There are also three batches, SybRepMonAgent, SybRepMonCheck, and SybRepMonReport that compute latencies of your replication, and will warn you when replication falls behind. These three batch programs call SybRepMonitor.pl. This program takes an argument --ACTION.
To initialize this system, you need to set up your configuration file and then run myperl SybRepMonitor.pl --ACTION=INSTALL
After the system is INSTALLED, the above mentioned batches will perform your monitoring automatically. Below is the syntax for SybRepMonitor.pl:
You may not wish all your alarms to work at the same thresholds - preferring to set some thresholds individually. Generally speaking, this is most needed when some resourse is nearing "full" and generating alarms, but you can not fix the problem immediately - intending to fix the problem later. The conf/threshold_overrides.dat file allows you that control.
Another separately installed GEM component is the Sybase threshold manager. This program (ADMIN_SCRIPTS/bin/threshold_manager.pl) installs customized sp_thresholdaction procedures into your databases and allows you to find peak usage (most important for log file sizes). This proactive utility will hopefully prevent you from running out of log space - because you will have been warned in advance in such a way that you can expand capacity before there is a production alert.
The sp_thresholdaction procedures we install are simple reporting versions that insert peak usage data into a small table in sybsystemprocs. You can run a report showing peak usage of data and log segments in your databases which is the Threshold Report you can view in the console.
This procedure needs to be installed manually by running
ADMIN_SCRIPTS/bin/threshold_manager.pl --ACTION=INSTALL
after you have registered your servers. One warning. If you increase the *size* of any of your databases, you will need to rerun the above installation command. Sybase thresholds are based on free pages and the percentages are therefore set when you run the installation. So, if you double the size of a database, your 60% threshold will be firing at 30% and recording it as 60% full! Just reinstall and you will be ok!.
Other commands of interest:
ADMIN_SCRIPTS/bin/threshold_manager.pl --ACTION=CHECK
ADMIN_SCRIPTS/bin/threshold_manager.pl --ACTION=REPORT
This feature only works with Sybase
This information is stored in conf/pc_service.dat and can be created from configure.pl using "Snapshot Win32 Services" on the Post install tasklist. The file can also be created by the unscheduled batch file PcServiceCheckerInit.ksh.
You will probably need to hand edit this file - the snapshot is at a point in time and some services may get turned off or just dont stay up. After you have created this file, simply remove lines which get flagged by the monitors yet are not important.
The alarms tab will populate the directory cgi-bin with runnable web scripts. The button to actually distribute those scripts to your web server is currently unimplemented. You will need to copy the scripts by hand.
This is made easier by the fact that the scripts have been modified to run in your environments, but it is possible that the scripts do not execute.
It is beyond the scope of this document to discuss web server setup. All the directory requires is script access.
The top of these scripts should look like:
The paths, company name, sybase directories, and perl version have all been customized. Make sure they all look ok.
Test this script through your web browser.
perl monitor.pl
Two modules are currently shipped with GEM - an event viewer and a monitor. Both are located in the root directory. To run, use
perl ADMIN_SCRIPTS/bin/fix_db.pl -Ax
This is a cute little database configuration checker. You might as well run it. It shows dboptions you might wish to correct and identifies common configuration problems. To correct these problems remove the -x (noexec) option.
You can add customized reports to the console easily using conf/console.dat. These reports can be pretty much any command or sql statement. Check out the file for the syntax.
It is recommended that you create object level backups of your server DDL once per week. GEM provides the excellent script dbschema.pl (written by Michael Peppler and David Owen) in the ADMIN_SCRIPTS/bin directory to facilitate this process. Because this script is written in SybPerl (not DBI::Sybase), we do not provide an integrated approach to creating these audits. I recommend you back up your ddl once per week on your production servers.
You can set up conf/dns.dat and then do dns monitoring with
0,20,40 * * * * /usr/bin/nice /usr/local/bin/perl-5.8.1 /apps/sybmon/dev/ADMIN_SCRIPTS/monitoring/dnsmonitor.pl --OUTFILE=/apps/sybmon/dev/data/html_output/dnsmonitor.pl.txt
The gem configuration utility will schedule your jobs on win32 monitoring stations.
At 2 points in configure.pl, you can create a unix crontab file. This file is named crontab.txt and is placed in the GEM root directory. You should schedule this file using yoru crontab on unix. To do this run
You should also place a .forward file in your home directory to redirect mails to your account.
Put the output of any of your routine scripts into data/html_output or data/cronlogs to have the reports show in the GEM console. This is a convenient spot to redirect output in any case. The filename itself is used to generate the console report.
Schedule additional alarming reports. These need to be set up in the cgi-bin mimi.pl reports screen before they can be run. But you can snapshot anything you can see on those screens and mail the results as appropriate
I sync logins between my replicated servers with
I monitor cisco logs with
I monitor centrally collected (via syslogsd) unix logs with
GEM is an administrative tool, designed for system administrators. As such, the conf directory contains all your passwords. You need to protect this data via operating system permissions.
We strongly recommend that all other directories in the tree, with the exception of the data/CONSOLE_REPORTS tree, be also made secure. Technically, you can allow read/execute access to these files, but it would be easier to only allow owner/group access - much of the data contained may be sensitive.
GEM is designed for simple upgrades. The steps are as follows
No configuration files are shipped with the installation so there should be no problems. All configuration files are shipped with a .sample extension.
On your windows monitoring server, you may not be able to extract the code because the task scheduler is running a batch job that calls one of the perl scripts. Windows will not let you overwrite a program that is running. This does not happen under Unix. You can either go into the task scheduler, stop all running jobs before rerunning the extract, or kill the jobs and then stop the task scheduler process. I normally just stop the jobs, but sometimes (because end task does not work cleanly) i am forced to stop the scheduler process for the duration of the extract.
After you download, your GEM scripts will have *OUR* hashbangs, library paths, and sybase environment. This is probably not what you want.
Run
The alarm database reinstall will save table data, drop all tables, reinstall tables, and finally copy back data. If there is a problem, it will leave a tables with the extension _BAK containing the original data. So, under the hood, the upgrade process for the table Event is "select into Event_BAK from Event", "drop table Event", "create table Event", "insert Event select * from Event_BAK", and finally "drop table Event_BAK". Upgrades can not start if any tables with the extension _BAK exists - you must remove them before the upgrade.
If there is a problem, you can probably just drop the BAK table - but it would be better to recover by following a process akin to "truncate table Event", "insert Event select * from Event_BAK", "Drop table Event" (you have to do these by hand). Got it? Any questions on a failed install please contact SQL Technologies tech support.
The final install step redoes your hashbangs, perl library paths, and removes all control M's from the code line. A log of the upgrade is saved in the logs directory.
ONCE YOU HAVE SUCCESSFULLY RUN upgrade.pl YOU ARE DONE
INSTALLATION GUIDE
Pre-install check list
and
[StartKey] -> [Run] and then type ppm install DBD::ODem/em.
go
create database gemalarms on data_device_6=200
go
use master
go
sp_dboption gemalarms,"select",true
go
sp_dboption gemalarms,"trunc",true
go
use gemalarms
go
checkpoint
go
sp_addlogin "gemalarms","gemalarms","gemalarms"
go
sp_adduser gemalarms
go
You will require sa_role access for all your Sybase database servers
You will require "no-password" access via ssh or rsh for your unix systems
You will require sybase unix account access for your Sybase database servers.
Last login: Wed Apr 2 11:37:29 2008 from monitor
$
Suggestions on your first implementation
Download & initial setup
tar xvzf gem.tgz), or with gzip -d gem.tgz; tar xvf gem.tar. If you install GEM into a subdirectory, do not use a directory that includes space characters (ie. Program Files). White space in the directory name is not a tested option.
configure.pl
GEM Configuration Tool
Important notes
How to run configure.pl
The welcome tab
The paths tab
The servers tab
The files tab
The backups tab
The console tab
The alarms tab
The install software tab
The post install tasks tab
The scheduler tab
export EDITOR=vi
Be sure that the account you schedule this on has a .forward file so any errors will not be routed!
A .forward file is a file in your HOME directory that contains mail addresses.
POST INSTALLATION STEPS
Other things to do
CLEAN UP UNIX SCRIPTS DIRECTORY
perl upgrade.pl to fix these issues. Modify your Password Files
sybase_passwords.dat
oracle_password.dat
pc_password.dat
unix_passwords.dat
sqlsvr_password.dat
All configuration files are self documented. An archive of your old configuration files is kept in conf/saved_filesWindows Directory Cleaner
# FILENAME: Win32_Cleanup.dat
#
# USED BY: Batch job Win32FileCleanup
#
# SYNOPSIS: Directives for cleaning up win32 drives. This file is
# identical to Unix_Cleanup.dat but for the --compress (Win32 only)
# argument which is missing and the required --host argument (Unix Only).
#
#
# FORMAT : HOSTNAME drive drive drive.
#
# DETAILS : The arguments are the arguments to purge_old_win32_files.pl
#
# --host=<host>
# --hours=<hours>
# --days=<days>
# --dir=<dir>
# [--del] - do you wish to delete the file?
# [--done] - only work on files with .done extension
#
# EXAMPLE FORMATS:
#
# Delete 14+ day old files on host h1
# --days=14 --dir=//adsrv012/c$/oracle/admin/SCPROD/udump --del
#
# Delete files with .done extension older than 2 days old
# Note: this will delete .done.gz files and .done files
# --days=2 --dir=//SRVR001/d$/logshipbuffer --del --done
#
#######################################################################
#
# START RECOMMENDED PURGES
# --days=7 --dir=C:/gem/data/logs -del
# --days=7 --dir=C:/gem/data/batchjob_errors -del
# --days=7 --dir=C:/gem/data/GEM_BATCHJOB_LOGS -del
# --days=7 --dir=C:/gem/data/CONSOLE_REPORTS -del
# --days=7 --dir=C:/gem/data/cronlogs -del
# --days=7 --dir=C:/gem/data/errors -del
# --days=7 --dir=C:/gem/data/backup_reports -del
# --days=7 --dir=C:/gem/data/html_output -del
# --days=30 --dir=C:/gem/data/BACKUP_LOGS\*\sessionlog -del
# --days=30 --dir=C:/gem/data/BACKUP_LOGS\*\errors -del
# END RECOMMENDED PURGES
Unix Directory Cleaner
port_monitor.dat
# hostname PORT SERVER DESCRIPTION
SRVR001 1433 SRVR001 Microsoft SQL Server
SRVR007 1433 SRVR007 Microsoft SQL Server
brokersql 1433 BROKERSQL Microsoft SQL Server
mail1 25 Sendmail on mail1
Sybase Replication Monitoring
# FILENAME: replication.dat
#
# SYNOPSIS: Lists your sybase replication server information
#
# FORMAT:
#
# REPSERVER $NAME $LOGIN $PASSWORD $THRESHOLD_MB
# REPROUTE $SOURCE_SVR $SOURCE_DB $DEST_SVR $DEST_DB $REPSERVER
#
# EXAMPLES (350MB Thresholds):
#
# REPSERVER REP1DR_RS sa <pass> 350
# REPSERVER REP2_RS sa <pass> 350
# REPSERVER REP1_RS sa <pass> 350
#
# REPROUTE SYB1 my_db SYB2 my_db REP2_RS
# REPROUTE SYB1 my_db SYB1DR my_db REP2_RS
#
# ONCE YOU SET THIS FILE UP - PLEASE RUN
# ADMIN_SCRIPTS/monitoring/SybRepMonitor.pl --ACTION=INSTALL
# MONITORING IS HANDLED AUTOMATICALLY BY THE GEM BATCH SybRepMonAgent
##############################
Usage: SybRepMonitor.pl --ACTION=INSTALL|UNINSTALL|MONITOR|REPORT|CHECK
[--SERVER=xxx] [--DEBUG] [--OUTFILE=file]
if --ACTION=INSTALL will install
--REBUILD redoes table creates
if --ACTION=CHECK will check latency vs --ALARM_MINS
- mail to --ALARM_MAILTO as needed
if --ACTION=REPORT will create a report
- will print data for --REPORT_HOURS hours
- will only show rows > --REPORT_THRESH seconds
- will aggregate based on --BUCKETSIZE
- will print HTML output if --HTML is passed
if --ACTION=MONITOR will insert rows into all source databases
- will insert --ITERATIONS rows
- sleeps --FREQUENCY secs between each insert
Adjust Alarming Thresholds
# FILENAME: threshold_overrides.dat
#
# SYNOPSIS: Monitoring Thresholds
#
# DETAILS : This file permits you to turn off alarms and to control their
# severity. This is a Comma Separated File
#
# SAMPLE FORMAT:
# <system> <monitor_program> <level> <threshold> <optional subsystem>
#
# monitor_program=UnixDiskspace|PcDiskspace|SybSpaceMonitor
# |SpaceMonitorSqlsvr|ThresholdManager
# level=CRITICAL|ERROR|WARNING
#
# remember to reset higher priority thresholds so there is no overlap - ie if you
# set ERROR to 98%, then you should set critical to something larger (say 99%).
# The programs may act wierd if the CRITICAL threshold was less than the ERROR threshold.
#
# By default - SybSpaceMonitor & SpaceMonitorSqlsvr will use 90/92/95% as
# their default thresholds
#
# Replication thresholds are in minutes. For replication, you can put a
# blank target name in if you want but not a blank source name
#
# EXAMPLES
# eg. directfeed,UnixDiskspace,WARNING,80,Disk: /var
# eg. direct1,UnixDiskspace,WARNING,80,Disk: /var
# eg. direct2 ,UnixDiskspace,WARNING,80,Disk: /var
#
# eg. SYBSVR1,SybSpaceMonitor,WARNING,80,db1
# eg. SYB1,SybSpaceMonitor,ERROR,95
# eg. SYB1,SybSpaceMonitor,ERROR,95,clientdb
#
# eg. ADSRV057,PcDiskspace,ERROR,98,d$
# eg. ADSRV057,PcDiskspace,CRITICAL,99,d$
#
# eg. SERVERNM,ThresholdManager,CRITICAL,99,logsegment|default
#
# EXAMPLE REPLICATION STUFF
# eg. SOURCESVR,SybRepMonCheck,CRITICAL,30,TARGETNM
# eg. SOURCESVR,SybRepMonCheck,ERROR,15,TARGETNM
# eg. SYB1,SybRepMonCheck,CRITICAL,80,IMAGSYB2
# eg. SYB1,SybRepMonCheck,CRITICAL,80,
# eg. SYB1,SybRepMonCheck,ERROR,60
#
#########################################
The sybase threshold manager
Snapshot Win32 Services
cd win32_batch_scripts/interactive
PcServiceCheckerInit.ksh
Install web server scripts
a) copy the contents of cgi-bin to the web server scripts directory you identified for your use
b) chmod 755 these scripts to make them executable (unix only)
c) try to run mimi.pl when in that directory. Mimi is a cgi-bin script - so it will hang asking for parameters if it runs successfully. It might also give you a command not found or library not found message.
d) you might need to change the hashbang (first line) to point to your perl
e) try running printenv.pl from your web browser... this is a very simple script that should always work.
f) try running mimi.pl from your web browser
#!/usr/local/bin/perl-5.8.1
use lib qw(/apps/sybmon/dev/lib)
my($COMPANYNAME)="YOUR COMPANY";
BEGIN {
if( ! defined $ENV{SYBASE} or ! -d $ENV{SYBASE} ) {
if( 1==2 ) { print 'doh'; }
} elsif( -d "/export/home/sybase" ) {
$ENV{SYBASE} = "/export/home/sybase";
} elsif( -d "/apps/sybase" ) {
$ENV{SYBASE} = "/apps/sybase";
}
}
}
RUN monitor.pl and eventviewer.pl
perl eventviewer.plRun fix_db.pl to for initial db config errors
ADDITIONAL CONSOLE REPORTS
SCHEMA GENERATION
DNS Montitoring
Scheduling the batch jobs
Win32 Scheduling
Unix Scheduling
export EDITOR=vi # presuming u like vi
crontab -e
<vi window>
:r crontab.txt
:wq
Your own scheduled tasks
# the following job compare a server to its dr copy
1 22 * * * /perl/bin/perl /apps/sybmon/dev/ADMIN_SCRIPTS/bin/datacompare.pl -Usa -SSYB1 -Pxxx -sSYB1DR -pxxx -uxxx -h > /apps/sybmon/dev/data/html_output/Rowcount_Compare_Prod_DR.html 2>&1
0 10,12,14,16,18 * * 1-5 /usr/local/bin/perl-5.8.1 /apps/sybmon/dev/ADMIN_SCRIPTS/monitoring/RunMimiReport.pl --SUBJECT="2 Hour Unix Status Report" --MAILTO=def@bac.com,abc@abc.com --REPORT=Unix2Hour --TIME="2 Hours" > /apps/sybmon/dev/data/GEM_BATCHJOB_LOGS/RunMimiReport_Unix2Hour 2> /apps/sybmon/dev/data/batchjob_errors/RunMimiReport_Unix2Hour
38 9 * * 0 /usr/local/bin/perl-5.8.1 /apps/sybmon/dev/ADMIN_SCRIPTS/bin/copy_syslogins.pl -FSYB1 -Usa -Pxxx -tSYB2 -usa -pyyy > /apps/sybmon/dev/data/GEM_BATCHJOB_LOGS/copy_syslogins_SYB1.log 2>/apps/sybmon/dev/data/batchjob_errors/copy_syslogins_SYB1.log
18,48 * * * * /usr/bin/nice /usr/local/bin/perl-5.8.1 /apps/sybmon/dev/ADMIN_SCRIPTS/monitoring/cisco_logmon.pl --INFILE=/var/log/cisco.log --TODAYONLY >/apps/sybmon/dev/data/GEM_BATCHJOB_LOGS/cisco_logmon.log 2>/apps/sybmon/dev/data/batchjob_errors/cisco_logmon.log
5,15,25,35,45,55 * * * * /usr/local/bin/perl-5.8.1 /apps/sybmon/dev/ADMIN_SCRIPTS/monitoring/unix_monitor.pl --INFILE=/var/log/messages --TODAYONLY --EXCLUDEFILE=/apps/sybmon/dev/ADMIN_SCRIPTS/bin/solaris.excl --MAXLINES=100000000 --HTML --OUTFILE=/apps/sybmon/dev/data/html_output/unix_monitor.html >/apps/sybmon/dev/data/GEM_BATCHJOB_LOGS/unix_monitor.log 2>/apps/sybmon/dev/data/batchjob_errors/unix_monitor.log
Directory security
How To Upgrade GEM
perl upgrade.pl
perl upgrade.pl to finalize the installation. This step is MANDATORY and will perform a variety of steps like updating your configuration files and re-installing your alarm database. During the period you are upgrading - your GEM batch jobs will probably fail and send you alarm mail. Ignore these failures notifications.
This output is documentation for the SQL Technologies Installation Guide.
copyright © 1998-2008 By
SQL Technologies