I am looking to display the number of robots deployed in a specific time period. Is there a location in the NSM database that houses a "Date of Creation" for the robots? I have looked but nothing really stands out from what I have seen.
There is no "create date" in the NiS. You'll find the alive_time and check_time which is quite useless in finding out when the robot was initially installed. However, I think I have the remedy. The following NAS script will query the robots and extract the directory stats on the '.' (i.e. NMS install directory) and finds the robot directory. It then prints it all with the robot address and the date (plus UTC). You can extend the script to ask for hubs prior to asking for robots.
Hope this helps,
robots = nimbus.request("hub","getrobots")
-- robot arguments
args = pds.create()
for ridx,r in pairs(robots["robotlist"]) do
dl = nimbus.request(r.addr,"directory_list",args)
for k,e in pairs(dl["entry"]) do
if e.name == "robot" then
printf ("%-40s created %s (UTC %d)",r.addr, timestamp.format (e.created,"%Y.%m.%d %H:%M"), e.created)
----------- Executing script at 08.11.2010 14:49:53 ---------- /Development/Asker/xpcase created 2008.08.21 12:49 (UTC 1219315769) /Development/Asker/xqaf-xp-dw created 2010.09.21 12:03 (UTC 1285063428)
Thank you carstein, I did find a different solution to my quest. Here is the SQL script.
SELECT COUNT(*) as "Number of robots"FROM [NimbusSLM].[dbo].[GRP_SERVER]WHERE created between '11/01/2010' and '11/30/2010'
Any flaws in this logic?
The logic is fine, the problem is that this table is about to be unsupported. The grp_server probe that maintains this information (actually designed spesifically for - Enterprise Console) will be replaced with the datamodel supporting the CM tables. E.g CM_COMPUTER_SYSTEM, CM_CONFIGURATION_ITEM etc.
Awsome.. So using your code would be a better bet then?
I'm afraid so... The preferred solution would be to have this in the NiS, e.g. the CM_NIMBUS_ROBOT table, but as of now this information is simply not present. We would need to make the robot report its "create" date, and then pass it backwards into the infrastructure.
Might this be in the audit probe if you turn audit on upon deployedment. Just a thought.
Thank you again Carstein.. being new to all this I now must ask what must be a very stupid question for you. Where do I run this code from ? Sorry for my ignorance.
You can copy the code earlier in this thread into the NAS script editor (double-click nas in the Infrastructure Manager - IM) and enable the NAS auto-operator (unless enabled) and access the scripts under the scripts tab under the auto-operator tab.
Right-click and select new to create a new script, then paste the code in and save/run.
Wonderful, thank you Carstein. I ran the script and it did perform as stated. On the downside, it returned 2 results..
/MedQuistNOC/NOC_HUB_01/mq1dstnoc01 created 2009.07.14 06:43 (UTC 1247568198)/MedQuistNOC/NOC_HUB_01/mq1-hc-sql-01 created 2010.10.12 12:31 (UTC 1286901066)
These two robots are on the same hub, and the primary hub of the entire domain. I am missing 2 more tiers of robots, 2 robots in our DMZ and all the client robots out in the field. Aprox 230 robots.
Now all these are connected via tunnels, I assume this might be causing the problem?
Here is Carstein's script with some extra logic to cycle through all of the hubs:
hubs = nimbus.request("hub","gethubs")-- robot argumentsargs = pds.create()pds.putString (args,"directory",".")pds.putInt (args,"type",1)pds.putInt (args,"detail",1)for hidx,h in pairs(hubs.hublist) do robots = nimbus.request(h.addr,"getrobots") for ridx,r in pairs(robots["robotlist"]) do dl = nimbus.request(r.addr,"directory_list",args) for k,e in pairs(dl["entry"]) do if e.name == "robot" then printf ("%-40s created %s (UTC %d)",r.addr, timestamp.format (e.created,"%Y.%m.%d %H:%M"), e.created) end end endendpds.delete (args)
Note there is no error checking in this script. Each call to the nimbus.request() function should probably accept a second return value containing the return code from the request. If the return code is 0, all is well. If not, the return code gives you an idea what went wrong. That way when you encounter a problem, the script can potentially continue on with the next hub/robot rather than dying. Completely optional, of course.