none
Health model for instance reference RRS feed

  • Question

  • Hi,

    I need some help to see if this is even possible.

    I have a class called Endpoint. All Endpoints are discovered from a CSV file. So I have in my environment around 100 instances of Endpoint.

    Some of these endpoints reference other endpoints. Say for example, Endpoint A references endpoints B and C. I would like to model this into SCOM so that the health of B and C roll-up to A.

    I read from the documentation regarding relationships that a hosts relationship affects the existence of child objects. In this case B and C. I don't want this to happen as I am worried that we get some unpredictable behavior if I undiscover A (B and C would be deleted as well, right?)
    Containment relationship doesn't really fit what I need and finally reference relationship doesn't support health roll-up. So, that leaves me with a lot of headscratching and the question: How do I achieve this? My gut feeling tells me that I am forced to use a hosts relationship, but I am honestly not sure what happens with depency monitor and endpoints B and C in that case. I suspect they would remain available in SCOM since they will be discovered as normal unhosted objects at the next discovery cycle, but I am far from being sure about it.

    Can somebody help me?

    br

    Jesper


    /Jesper Rune Larsen (https://enlightementthroughcuriousity.blogspot.dk/)

    Wednesday, August 21, 2019 10:32 AM

Answers

  • Well if you have a way to know which interface rely on which, you actually do have a way to discriminate them.

    I'm just throwing ideas as they come, but maybe you could create something like that :

    - A "REST pool" class discovered for each "master" interface

    - A "REST pool member" class discovered for each of the interfaces the "master" relies on

    - A containment relationship between these

    Wednesday, August 21, 2019 12:41 PM
  • Maybe you'll need some kind of "Parent" class which would be parent to your endpoint class.  The "Parent" class would have 2 attributes [string]Name & [boolean]Rollup.  The parent class would have a dependency rollup which would be enabled or disabled depending on the Rollup attribute. (Dynamic groups and overrides may help).  You would then have a default "Parent" class instance in which the Rollup would be false and all the "unlinked" EndPoints would be child of.  Those that are linked would be under a single "Parent" class. 

    Discovery would be simple (in PowerShell) if you have control on the .CSV, just add the column "Parent" and leave blank for none.  In PoSH, group by your CSV by parent and you can add every parent and child in a Jiff.

    To control alerts you can create dynamic groups of EndPoints depending on Parent Rollup.  You may even skip the Rollup attribute and replace it by your naming convention (say "default" as parent name = no rollup).

    As CyrAz stated, hard to say without knowing how your software works and what your plan is on monitoring.

    Wednesday, August 21, 2019 12:57 PM

All replies

  • Before even talking about what type of relationship you can use, are you sure it's possible to establish relationships between instances of the same class?

    I'm not saying it's not possible, but I never thought about it that way...

    Wednesday, August 21, 2019 12:02 PM
  • In all honesty, I hadn't even thought about that. I don't know if that's a showstopper.

    /Jesper Rune Larsen (https://enlightementthroughcuriousity.blogspot.dk/)

    Wednesday, August 21, 2019 12:08 PM
  • There probably is a way to change the health model in a way that would reflect that hosting in a better way, but it's hard to say without knowing how works the software you want to monitor...

    And I must admit I myself had quite a bit of headscratching involved in finding a proper health model for some softwares !

     
    • Edited by CyrAz Wednesday, August 21, 2019 12:15 PM
    Wednesday, August 21, 2019 12:14 PM
  • The software is a communications hub for many applications. The endpoints are REST interfaces that need to be available. Some of these interfaces rely on other interfaces. There really is no way to discriminate between the interfaces.

    /Jesper Rune Larsen (https://enlightementthroughcuriousity.blogspot.dk/)

    Wednesday, August 21, 2019 12:27 PM
  • Well if you have a way to know which interface rely on which, you actually do have a way to discriminate them.

    I'm just throwing ideas as they come, but maybe you could create something like that :

    - A "REST pool" class discovered for each "master" interface

    - A "REST pool member" class discovered for each of the interfaces the "master" relies on

    - A containment relationship between these

    Wednesday, August 21, 2019 12:41 PM
  • Maybe you'll need some kind of "Parent" class which would be parent to your endpoint class.  The "Parent" class would have 2 attributes [string]Name & [boolean]Rollup.  The parent class would have a dependency rollup which would be enabled or disabled depending on the Rollup attribute. (Dynamic groups and overrides may help).  You would then have a default "Parent" class instance in which the Rollup would be false and all the "unlinked" EndPoints would be child of.  Those that are linked would be under a single "Parent" class. 

    Discovery would be simple (in PowerShell) if you have control on the .CSV, just add the column "Parent" and leave blank for none.  In PoSH, group by your CSV by parent and you can add every parent and child in a Jiff.

    To control alerts you can create dynamic groups of EndPoints depending on Parent Rollup.  You may even skip the Rollup attribute and replace it by your naming convention (say "default" as parent name = no rollup).

    As CyrAz stated, hard to say without knowing how your software works and what your plan is on monitoring.

    Wednesday, August 21, 2019 12:57 PM
  • Thank you for your answers. Having read through them a few times, I think I will try to model the master/client model with a containment relationship.

    Thank you very much for dishing in.


    /Jesper Rune Larsen (https://enlightementthroughcuriousity.blogspot.dk/)

    Friday, August 23, 2019 7:56 AM