The TADDM GUI only shows you a subset of the information that's stored in the database. The rest of the information can be found by accessing the database directly or using the command line ($COLLATION_HOME/dist/sdk/bin/api.sh). If you use the command line, the easiest way to get information about an object is if you have its GUID, with:
api.sh find [--depth num] --guid THE_GUID
but you need to get the GUID first. It's actually easy - just drag and drop an icon from the GUI into Notepad, and what you'll see will be similar to:
<DragInformation><Node><Name>SVC-2145-GYUR0XSVC01-IBM</Name><ClassName>com.collation.platform.model.topology.storage.StorageSubSystem</ClassName><SubType>com.collation.platform.model.topology.storage.StorageSubSystem</SubType><CollationType>topology.storage.StorageSubSystem</CollationType><ID>459DBBF7B68832D98A1C414EA1E5E2EF</ID><IconName>storagesub</IconName></Node></DragInformation>
The part in bold is the GUID. Easy as that.
Thursday, December 10, 2009
Wednesday, December 9, 2009
Framework Monitoring in ITM
If you are looking to monitor Tivoli Framework from ITM, the best way is to develop an Universal agent or agent builder to pull framework metrics using your custom script. Needless to say, Framework provides a vast array of commands that can easily be scripted to get you the metrics you needed.
If you are looking to monitor basic server components such as TMR, ManagedNode, epmgr and gateways and if you are at Framework 4.3.1 or later, you are in luck. You don't even need to develop an MDL. Framework 4.3.1 provides a new component called tmfmon that provides necessary MDLs and commands that can be readily imported into Universal agent.
You need to take a look at $BINDIR/../generic/tmfmon/README file on how to implement this solution.
If you are looking to monitor basic server components such as TMR, ManagedNode, epmgr and gateways and if you are at Framework 4.3.1 or later, you are in luck. You don't even need to develop an MDL. Framework 4.3.1 provides a new component called tmfmon that provides necessary MDLs and commands that can be readily imported into Universal agent.
You need to take a look at $BINDIR/../generic/tmfmon/README file on how to implement this solution.
Wednesday, December 2, 2009
Some quick notes on CCMDB 7.2
These aren't clear or verbose at this point, but I wanted to get the info out to anyone who wants it:
TADDM 7.2 and CCMDB 7.2 are out now, and they seem to work just great.
The TADDM 7.1.1.5 -> 7.2 upgrade works amazingly well, tho it takes several hours if you have lots of data
Java 1.6_17 (the latest as of a couple of weeks ago) JRE doesn't work with the TADDM GUI. You need to use an older version (1.6_07 works like a champ).
New in TADDM 7.2 is an "explore" feature in a topology view. This lets you add additional relationships to a view. So you can right-click a machine and select "Explore", then select what relationships you want displayed, then you can select which other objects that are associated via those relationships will be displayed. Kinda nifty.
CCMDB 7.2 has a new CI topology view. This is a nice feature so you don't have to launch over to TADDM just to see topology info.
In CCMDB 7.2, the "Admin" workstation is no longer limited to just Windows - Linux is supported (so you can run the CCMDB Launchpad from a Linux machine).
TADDM 7.2 and CCMDB 7.2 are out now, and they seem to work just great.
The TADDM 7.1.1.5 -> 7.2 upgrade works amazingly well, tho it takes several hours if you have lots of data
Java 1.6_17 (the latest as of a couple of weeks ago) JRE doesn't work with the TADDM GUI. You need to use an older version (1.6_07 works like a champ).
New in TADDM 7.2 is an "explore" feature in a topology view. This lets you add additional relationships to a view. So you can right-click a machine and select "Explore", then select what relationships you want displayed, then you can select which other objects that are associated via those relationships will be displayed. Kinda nifty.
CCMDB 7.2 has a new CI topology view. This is a nice feature so you don't have to launch over to TADDM just to see topology info.
In CCMDB 7.2, the "Admin" workstation is no longer limited to just Windows - Linux is supported (so you can run the CCMDB Launchpad from a Linux machine).
Tuesday, November 17, 2009
SQLite Database
If you have been using CSV/flat file as a persistent storage for your scripts, you should really checkout, SQLite. It gives you the power of RDBMS while without the complexity that comes with it. Any SQLite database you create is nothing but a file. It provides locking, transaction support, joins, etc. With ".dump" command, it can generate the SQL commands to reproduce the whole schema.
Did I mention, this database format is supported by ActivePerl, by default? You can use the standard Perl DBI module to manage this database.
Also, there is a CLI tool called sqlite3 (~500K) that lets you run all database manipulation and SQL commands. And, if it is good enough for Google Android and Apple Safari, chances are it should be robust enough for my needs.
Here is a simple Perl script to access this database from Perl.
#!/usr/bin/perl
use DBI;
my $dbh = DBI->connect('dbi:SQLite:dbname=sample.db',',');
$sql = qq{ CREATE TABLE MYCERT ( num int not null, name varchar(20) ); };
$dbh->do($sql);
$sql = qq{ INSERT INTO MYCERT VALUES(1, 'ITM'); };
$dbh->do($sql);
$sql = qq{ INSERT INTO MYCERT VALUES(2, 'Omnibus'); };
$dbh->do($sql);
$dbh->disconnect();
Did I mention, this database format is supported by ActivePerl, by default? You can use the standard Perl DBI module to manage this database.
Also, there is a CLI tool called sqlite3 (~500K) that lets you run all database manipulation and SQL commands. And, if it is good enough for Google Android and Apple Safari, chances are it should be robust enough for my needs.
Here is a simple Perl script to access this database from Perl.
#!/usr/bin/perl
use DBI;
my $dbh = DBI->connect('dbi:SQLite:dbname=sample.db',',');
$sql = qq{ CREATE TABLE MYCERT ( num int not null, name varchar(20) ); };
$dbh->do($sql);
$sql = qq{ INSERT INTO MYCERT VALUES(1, 'ITM'); };
$dbh->do($sql);
$sql = qq{ INSERT INTO MYCERT VALUES(2, 'Omnibus'); };
$dbh->do($sql);
$dbh->disconnect();
Thursday, November 5, 2009
To AB, or not to AB
If you are looking to develop custom monitoring solution in ITM, ITM gives you two options, viz. an eclipse GUI based Agent Builder tool or Universal Agent (UA). Which one would you choose? While the agent builder is shiny and easy to use, UA solution has its own advantages. Read on to know some of the pros and cons of each approach.
Agent Builder based solution makes sense for the following scenarios.
1) If you want to deploy something real quick and easy, then Agent Builder is a good candidate for your needs. Once you are familiar with the agent builder interface, you can create a custom monitoring agent literally in minutes. Moreover, there are not many typos/mistakes you can make with the Agent Builder's GUI based approach.
2) If you generally prefer GUI method over CLI methods, you will like Agent Builder more.
3) If you want to pull from data sources such as JDBC, WMI, NT Event Log, Service Control Manager, etc, then you should be build an agent builder agent with few clicks. UA will require lot of work as you may have write your own code to pull data from these data sources.
4) If you want to integrate the custom monitoring deployement with your current agent deployment methods, then obviously agent builder is the way to go. Deploying agent builder is very much the same as deploying any other agent.
Universal Agent based solution makes sense for the following scenarios.
1) If you want to minimize the number of agents you want to manage, then you are better of with UA. For example, if your requirement is to deploy 'n' custom monitoring solutions, typically agent builder would require 'n' agents, whereas in case of UA, one agent should be able to perform all 'n' monitoring activities.
2) Let me prefix this statement with a caveat. Check with your IBM representative for all licensing related information. Since one UA can handle multiple monitoring tasks, the licensing costs of UA based solution is typically lower than that of Agent Builder.
3) If you have been using UA for a long time, you can deploy the UA solution as quickly as an Agent Builder solution. More over, UA works pretty reliably.
4) If your monitoring requirements needs advanced summarization capabilities, then UA provides more advanced features than agent builder. Again, some of these tasks can be done using by modifying the itm_agent_toolkit.xml file, but it is just that the Agent Builder capabilities in this regard is not fully known yet.
Hope this information is helpful in your next custom monitor deployment.
Agent Builder based solution makes sense for the following scenarios.
1) If you want to deploy something real quick and easy, then Agent Builder is a good candidate for your needs. Once you are familiar with the agent builder interface, you can create a custom monitoring agent literally in minutes. Moreover, there are not many typos/mistakes you can make with the Agent Builder's GUI based approach.
2) If you generally prefer GUI method over CLI methods, you will like Agent Builder more.
3) If you want to pull from data sources such as JDBC, WMI, NT Event Log, Service Control Manager, etc, then you should be build an agent builder agent with few clicks. UA will require lot of work as you may have write your own code to pull data from these data sources.
4) If you want to integrate the custom monitoring deployement with your current agent deployment methods, then obviously agent builder is the way to go. Deploying agent builder is very much the same as deploying any other agent.
Universal Agent based solution makes sense for the following scenarios.
1) If you want to minimize the number of agents you want to manage, then you are better of with UA. For example, if your requirement is to deploy 'n' custom monitoring solutions, typically agent builder would require 'n' agents, whereas in case of UA, one agent should be able to perform all 'n' monitoring activities.
2) Let me prefix this statement with a caveat. Check with your IBM representative for all licensing related information. Since one UA can handle multiple monitoring tasks, the licensing costs of UA based solution is typically lower than that of Agent Builder.
3) If you have been using UA for a long time, you can deploy the UA solution as quickly as an Agent Builder solution. More over, UA works pretty reliably.
4) If your monitoring requirements needs advanced summarization capabilities, then UA provides more advanced features than agent builder. Again, some of these tasks can be done using by modifying the itm_agent_toolkit.xml file, but it is just that the Agent Builder capabilities in this regard is not fully known yet.
Hope this information is helpful in your next custom monitor deployment.
Wednesday, October 14, 2009
Including Javascript functions in your BIRT reports
BIRT provides a very tight integration with Java/Java Script for customizing your reports. Most of the time, you embed your JavaScript within your reports and you have to modify each of the reports if something need to be changed.
However, there is a better way especially for some frequently used functions. You can put them in a .js file and re-use them across your reports. Here is how to do it.
1. Create a set of Java Script functions (such as for logging, modifying your queries, etc) and put it in a file. (e.g. GbsFunctions.js)
2. Save the file under somewhere under your resource directory, which can be set using Window->Preferences->Report Design->Resource->Resource folder within Eclipse. (e.g. resourcedir/GBS/scripts/GbsFunctions.js).
3. Now add the following XML tag to your XML source of the reports. Make sure that the XML you add doesn't result in malformed XML. (e.g. add just before <data-sources> tag).
<list-property name="includeScripts">
<property>GBS/scripts/GbsFunctions.js</property>
</list-property>
4. Now, you can access the functions listed in GbsFunctions.js within BIRT.
Hope you find this useful.
However, there is a better way especially for some frequently used functions. You can put them in a .js file and re-use them across your reports. Here is how to do it.
1. Create a set of Java Script functions (such as for logging, modifying your queries, etc) and put it in a file. (e.g. GbsFunctions.js)
2. Save the file under somewhere under your resource directory, which can be set using Window->Preferences->Report Design->Resource->Resource folder within Eclipse. (e.g. resourcedir/GBS/scripts/GbsFunctions.js).
3. Now add the following XML tag to your XML source of the reports. Make sure that the XML you add doesn't result in malformed XML. (e.g. add just before <data-sources>
<list-property name="includeScripts">
<property>GBS/scripts/GbsFunctions.js</property>
</list-property>
4. Now, you can access the functions listed in GbsFunctions.js within BIRT.
Hope you find this useful.
Thursday, October 8, 2009
A great new draft Redbook is available
Integrating Tivoli Products
It's got lots of good information on integrating ITM, ITNM, TADDM, CCMDB, TBSM, etc., and is well worth the read.
It's got lots of good information on integrating ITM, ITNM, TADDM, CCMDB, TBSM, etc., and is well worth the read.
Subscribe to:
Posts (Atom)