2 Replies Latest reply on Jul 1, 2019 8:52 AM by EDOARDO SPELTA

    TrueSight - Extract Monitors <> CI association

    Olivier Kovacs
      Share This:

      Hi there.


      For the last 3-4 years, we've been designing our service models using the Admin console.  For this, we've been creating each CI and setting up the relations manually - all is working fine so far.  We have over 3500 CIs, with over 4000 relationships, in about 110 distinct service models.


      We are now moving to CMDB as the source of our service models and have an issue.
      There are a lot of monitors (I mean a lot!) associated to various CIs in these models.  Some are from the WUM_KM, some are number/string extracts using Monitoring Studio...there are quite a few.


      We need to figure out a way to list all these monitors so that once our CIs are moved (or linked) to CMDB, we can re-link the monitors to the right CIs.


      Currently, the only way we know of is manualy doing it, which is an insane job - open each CI in the Admin Console, list the monitors (if any), go to the next one, ...

      We are looking for a way (Db query, mquery, report, ...) to extract this info so we know how to re-do it on CMDB. (CI <> Monitor)


      Would any of you have an idea, or have gone through this before?


      I'm open to suggestions - anything that can help me go through this tedious work.


      Thanks for the help!



        • 1. Re: TrueSight - Extract Monitors <> CI association
          Charles Kelley

          You shouldn't have to export that if you are on the latest release of TrueSight.  You can migrate your manual model into the CMDB with the sim2cmdb cli, see Recommended steps to migrate a service model to BMC Atrium CMDB - Documentation for BMC TrueSight Infrastructure Managem…


          At one time in BPPM 9.6, there was a problem where that monitor to CI association was lost after migration to the CMDB and publishing the CI's back after sim2cmdb.


          That was fixed in defect DRTSO-43968 back in a hotfix for BPPM 9.6 FP2, and is fixed in TrueSight 11.3.01 as well.

          • 2. Re: TrueSight - Extract Monitors <> CI association
            EDOARDO SPELTA


            i've been looking for the same answer for some time now and only got some partial results which i still have to confirm.


            With this query i think i'm able to find out which manual monitor associations i have done though the bppm admin console:


            select i.ci_id,mo.displayname,icfg.instname

            from instanceinfo_cfg icfg inner join attribute_meta am on (icfg.motypeid = am.motypeid) inner join mo_meta mo on (mo.motypeid=icfg.motypeid) inner join item_cfg i on (i.itemid=icfg.moinstid)

            where i.ci_id <> ' ' and am.tablename <> '' order by icfg.moinstid,am.dispname


            In this query i had to second-guess the following (and still don't know if i'm right..):

            1) ci_id <> 0: when this filed is empty i think the monitor is automatically associated to its original device, so it was not manually re-associated via admin console.

            2) tablename <> '': when tablename is empty i guess it's an "internal" monitor, nothing that is related to patrol km classes, data collection and metrics..


            Moreover having the ci_id is useless as i need to find out ci names BUT as far as i understood proactivenet sybase only contains ci_ids.

            I can find out ci names using rest APIs but using one call for every record returned by the previous query is slow and cumbersome.


            Still, this is not enough: if you use a lot of agentless monitoring, in my case Sentry Monitoring Studio, you also need to list something more than the monitor instance names: you need to know, in case of a studio web request, which url that monitor is monitoring, in case of a studio command you need to know which command you're executing, in case of a studio string search you need to know the string you're looking for and so on.


            My problem is that i cannot find any of these information (which are basically the CMA policy details) except in the PATROLAGENT_PCFGTL table, which has all these information in one single column (unbelievable..) but contains no relations with monitor IDs, only to patrolagent IDs.


            Anybody has more info or comments about this ?