DX Unified Infrastructure Management

  • 1.  UIM 8.1: Capturing alarms on an additional separate & independent database

    Posted May 17, 2015 05:52 AM

    We have a UIM 8.1 setup which collects data from more than 15 location and configured many pre-processing rules at NAS for suppressing alarms. Due to some compliance requirement, need to capture all alarms into a separate database for future investigation, scrutiny, and reference. I might want to use another SQLite DB for this purpose, so I can import the SQLite DB files to another Nimsoft setup or use SQLite browser for querying the DB.

     

    How do I plugin to the message bus and read data for this purpose ?

     

    Thanks

    Richard



  • 2.  Re: UIM 8.1: Capturing alarms on an additional separate & independent database

    Posted May 19, 2015 11:44 PM

    My suggestion would be to set up an attach queue on your current UIM hub with a subject of "alarm"

     

    Create a second hub with nas and its dependencies.

     

    On this second hub, create a get queue that attaches to the attach queue on the first hub.

     

    -Garin



  • 3.  Re: UIM 8.1: Capturing alarms on an additional separate & independent database

    Posted May 20, 2015 12:12 AM

    Garin's suggestion sounds good to me too, I'd also like to add you probably want to make sure to extend the retention time for alarms and transactions on that secondary nas hub.

     

    -jon



  • 4.  Re: UIM 8.1: Capturing alarms on an additional separate & independent database

    Posted Jun 05, 2015 06:25 AM

    Thanks Jon, point noted

     

    Richard



  • 5.  Re: UIM 8.1: Capturing alarms on an additional separate & independent database

    Posted May 29, 2015 01:04 AM

    Thanks Garin.

     

    We are doing this in our current setup. Can we have more than one queue and use one of them for this purpose?

     

    Richard



  • 6.  Re: UIM 8.1: Capturing alarms on an additional separate & independent database
    Best Answer

    Posted May 29, 2015 06:55 AM

    Yes.

     

    Think of an attach queue as a bucket with an indication of what should go into it. And a hub can host as many queues (buckets) as you want (or up to about a hundred depending on your OS)

     

    In the simplest case, you have a hub with a single attach queue with a subject of *. So * matches everything so every message that comes into the hub goes into that "*" bucket.

     

    If you wanted just alarms to be able to go somewhere else too, then you create a second attach queue (bucket) with a subject of alarm.

     

    Now when a message with an alarm subject comes into the hub, a copy goes into the "*" bucket and a copy goes into the second "alarm only" bucket because it matches that subject too.

     

    If a QOS message comes into the hub, it matches the "*" subject so goes into that bucket but it doesn't match the alarm subject so it doesn't go into the second bucket.

     

    -Garin



  • 7.  Re: UIM 8.1: Capturing alarms on an additional separate & independent database

    Posted May 29, 2015 07:07 AM

    Thanks Garin

     

    You answered my doubt. It really helps

     

    Richard



  • 8.  Re: UIM 8.1: Capturing alarms on an additional separate & independent database

    Posted May 29, 2015 12:40 PM

    One other thing that I found misleading originally with the product is that sales and pre-sales tech support will talk about the "message bus" and how "you put something on the bus" and "it gets where it needs to go". The implication is that this is automatic for everything. In reality, only some communications fall into this "automatic and don't have to think about it" category.

     

    With regards to any communications that have a "subject" associated with them (this is my classification - possibly there are communications that violate this), they only go as far as the first hub they can reach. Then they are kept there if there is an attach queue with a matching subject or they are thrown away (hub 7.71 or 7.80 includes an alarm for the event where a message arrives and is thrown away - finally). The message will then stay in that attach queue indefinitely unless something pulls it out. For that to happen you have to have a get queue on another hub "up stream" towards where the message is intended to go.

     

    There are also a handful of probes that include independent message passing within them - nas for instance has it;s own replication messaging that can forward messages it knows about to another nas without using the queuing infrastructure.

     

    It can get confusing how to get data from one place to another with all the possilbe combinations.

     

    -Garin