Forum Discussion

stcavernelis's avatar
stcavernelis
Icon for Neophyte rankNeophyte
12 days ago
Solved

Process monitoring (Linux)

I have a requirement to monitoring Linux processes - and am really hoping that someone has done something similar.

Initially I thought the datasource "LinuxNewProcesses_byProperty" would meet the requirements as you just need to specify the process/processes to monitor. However I need a solution that would allow me to almost concatenate processes. eg. a resource could exist in multiple groups where group one may configure monitoring for process x, but the other group may configured monitoring for process y.

Effectively it shouldn't be overwriting the property field, but just adding to it.

The one way I can think of doing this is multiple datasources - but that seems very very clunky.

Alternatively a combination of group properties and using the API to build the contents of another property... to make it just a little bit more interesting the processes MUST be running on the servers. So if they are not found during discovery, an alert must be raised.

 

 

  • Stuart_Weenig's avatar
    Stuart_Weenig
    12 days ago

    You wouldn't need to use the API. You could just build a property source that reads in the list of groups the device belongs to using `hostProps.get("system.groups")` or `hostProps.get("system.staticgroups")` and builds a single property to apply to the device. You wouldn't need the API at all.

    It could look something like this:

    propValue = []
    hostProps.get("syste.groups").each{group->
        switch(expression){
            case "Applications/App A":
                propValue.add("app_a_service"); break;
            case "Another group/Tartanic":
                propValue.add("tartanic_process_name"); break;
            // etc.
        }
    }
    println(propValue.join("|"))
    return 0

    This is off-the-cuff code; tweak as necessary.

8 Replies

  • Not sure i follow entirely your goal. What about something like this? You can have instances that have the same display name, but not the same ID (wildvalue) within the same DS. However, if you were to add grouping to the property list, you could easily add the group to the id (wildvalue) to make it unique. You could add the group as an ILP and group by that automatically. Discovery wouldn't actually contact the device at all. That would all happen during collection. If data can't be collected for the service, it would fill a value for a "process missing" datapoint. The above linked DS may be a good starting place for you.

  • Thanks Stuart - I don't think I quite explained my goal as clearly as I would have liked to (but regardless I will go through the DS you provided)

    let's say I have 3 servers. Server1, Server2 and Server 3. Each of them are expecting to run specific processes. eg.

    Server1 - Process1, Process2, Process3

    Server2 - Process1, Process6, Process8

    Server2 - Process1, Process2, Process8, Process10

    My challenge is the logic to config monitoring like this. If I used group properties - the same server could belong to multiple groups, but how would that affect the property where the processes are specified?

     

    • Stuart_Weenig's avatar
      Stuart_Weenig
      Icon for Legend rankLegend

      Ah, i see what you mean now. You would definitely not want to specify this property in more than one branch of the tree. If you did, the inheritance would be not determinable. Well, technically, the "deeper" group would win. Two groups with the same depth would go based on group id (can't remember if it's highest or lowest that wins). 

      So, you would either want to limit yourself to a single branch of the tree where this property is defined, or you would want to create a dedicated group structure where this is defined. There is no merging of properties when it comes to property inheritance.

      We are an MSP, so we have a branch of our tree that branches per customer then has subgroups under each customer. This is where we specify properties like this. The device exists in other groups, but we don't specify properties like this on those other groups. By keeping these properties only on the customers branch of the tree, we only have to worry about parent/child inheritance instead of trying to figure out 2nd cousin inheritance as well (if that makes sense). 

      The same applies for threshold overrides. We only do threshold overrides on this customers branch of the group tree. Global overrides happen at /Customers while other overrides go somewhere under there.

      • stcavernelis's avatar
        stcavernelis
        Icon for Neophyte rankNeophyte

        Would it be a bit clunky to use the API to build process property name list based on group membership?

        ie. server1 is in process(x) group and process(y) group, a property on the resource is then updated to monitor process-x and process-y

        There are just so many variations on our side. Some servers have common processes, while others are very specific or have a combination of processes.