Uploaded image for project: 'Observium'
  1. Observium
  2. OBS-438

Storage Submodule selective disable by host

Details

    Description

      Although AIX does return storage data in the Host Resources MIB, it is not particularly useful due to the portion of AIX's LVM that is returned in the Host Resource Storage (Logical Volume focused instead of Filesystem focused). As a result, I would like to work on one or more storage submodules (modeled after the existing hrstorage submodule) that are able to return more useful data about the AIX LVM status (physical volume usage, volume group usage, logical volume usage, and filesystem usage). I have already started working on this and have made a decent amount of headway with capturing the LVM data returned by AIX's IBM-AIX-MIB.

      I have two concerns with how the storage model currently works and would like to bounce some ideas off of you on how to approach it. First, the data returned by the AIX MIBs is significantly more comprehensive than what it returns in the Host Resources. As a result, I would like to disable the hrstorage storage submodule completely for my AIX systems (which will always return useful LVM data in the AIX MIBs). I'm thinking an OS config element which, if it exists, disables the specified storage submodule. If the config element does not exist, no storage submodules would be ignored. In order to do this, you would probably need a new version of include-dir.inc.php or an alternate that allows the specification of an array of "ignore" modules.

      Ex. (forgive my rudimentary PHP knowledge)

      (includes/definitions.inc.php)
      ...
      $config['os'][$os]['storage']['ignore'] = array("hrstorage");
      ...

      (includes/discovery/storage.inc.php)
      ...
      $include_dir = "includes/discovery/storage";
      $include_ignores = $config['os'][$device['os']]['storage']['ignore'];
      include("includes/include-dir.inc.php");
      ...

      (includes/include-dir.inc.php)
      ...
      if(!in_array($file, $include_ignores))
      {
      ... //perform the include

      My second concern is that the storage module creates a single aggregate graph for all of the storage submodules' data. I think it would be useful to have the storage submodule create a graph per storage submodule that is discovered for a device. With respect to the device overview, perhaps an aggregate is used for the device banner at the top and then the individual graphs in the storage section on the right are just grouped by submodule. Alternatively/Additionally, it would maybe be nice to have a separate storage submodule tab underneath the Device Health -> Disk Usage tab in addition to the aggregate.

      I have not yet delved into the UI code in Observium, so I don't have a good feel for how difficult it would be to do some of UI work. I am confident that I could create a storage submodule patch that ignores the module on an os basis, but I wanted to open the discussion with you to make sure that it would fit in with your vision before I started on that.

      Attachments

        Activity

          [OBS-438] Storage Submodule selective disable by host

          Ability to blacklist modules/mibs by OS was added some time ago.

          adama Adam Armstrong added a comment - Ability to blacklist modules/mibs by OS was added some time ago.

          I have created JIRA OBSERVIUM-442 as a patch submission for the first two pieces of this issue (using IBM-AIX-MIB for filesystem usage on AIX instead of HOST-RESOURCES-MIB).

          As the ideas for better representation of the different layers of virtualized storage get fleshed out, I will revisit the AIX storage discovery and poller modules and update them appropriately.

          Mike

          reinholdmc Michael Reinhold added a comment - I have created JIRA OBSERVIUM-442 as a patch submission for the first two pieces of this issue (using IBM-AIX-MIB for filesystem usage on AIX instead of HOST-RESOURCES-MIB). As the ideas for better representation of the different layers of virtualized storage get fleshed out, I will revisit the AIX storage discovery and poller modules and update them appropriately. Mike

          We actually have NetApp storage as well, so I would be more than happy to help with that where possible.

          One idea that I have been toying with today is having a storage group concept - basically another attribute that could then be used for grouping the storage elements together. For instance, the physical disks could be put in a "Physical" group (PV for AIX LVM terminology). The next level up could be the "Aggregation" group (VG in AIX, Aggregate in NetApp?). Then "Logical" (LV in AIX, Volume in NetApp?). Then "Filesystem" (FS in AIX, not sure where the NetApp LUN falls in).

          Maybe that concept could be generalized so that the storage submodules can define their own grouping levels or use an existing level and the storage module does the grouping and the display...

          For the original purpose of this ticket, I'm going to do two things if you think it makes sense:

          1 - make an AIX FS Storage module that gets the filesystem information, since that is what the Host Resource MIB seems to target on most systems. Without the right way to display it, the PV, VG, and LV info would just be noise.

          2 - take a look at adding the "ignore" functionality to the include_dirs so that the user can configure an os to ignore specific storage modules (in my use case, ignore host resources and just show the AIX FS module).

          Once I have those done, tested, and submitted, I can help with whatever other portion of the storage monitoring that would take Observium in the right direction for all the different use cases (AIX, NetApp, EMC, etc)...

          Mike

          reinholdmc Michael Reinhold added a comment - We actually have NetApp storage as well, so I would be more than happy to help with that where possible. One idea that I have been toying with today is having a storage group concept - basically another attribute that could then be used for grouping the storage elements together. For instance, the physical disks could be put in a "Physical" group (PV for AIX LVM terminology). The next level up could be the "Aggregation" group (VG in AIX, Aggregate in NetApp?). Then "Logical" (LV in AIX, Volume in NetApp?). Then "Filesystem" (FS in AIX, not sure where the NetApp LUN falls in). Maybe that concept could be generalized so that the storage submodules can define their own grouping levels or use an existing level and the storage module does the grouping and the display... For the original purpose of this ticket, I'm going to do two things if you think it makes sense: 1 - make an AIX FS Storage module that gets the filesystem information, since that is what the Host Resource MIB seems to target on most systems. Without the right way to display it, the PV, VG, and LV info would just be noise. 2 - take a look at adding the "ignore" functionality to the include_dirs so that the user can configure an os to ignore specific storage modules (in my use case, ignore host resources and just show the AIX FS module). Once I have those done, tested, and submitted, I can help with whatever other portion of the storage monitoring that would take Observium in the right direction for all the different use cases (AIX, NetApp, EMC, etc)... Mike

          There are a lot of things that could/should be done with the storage setup. It probably needs to be split into physical/logical at the very minimum.

          I'm currently looking at how to fit netapp stuff in, and it has 3 different "levels" of storage, physical, logical and filesystem, all of which have a different set of data that can be stored.

          I'm not sure how the best way to do it is, so i'm open to suggestions

          (we have a similar issue with ports and varying levels of data available depending upon type and device, and have never solved it acceptably)

          adam.

          adama Adam Armstrong added a comment - There are a lot of things that could/should be done with the storage setup. It probably needs to be split into physical/logical at the very minimum. I'm currently looking at how to fit netapp stuff in, and it has 3 different "levels" of storage, physical, logical and filesystem, all of which have a different set of data that can be stored. I'm not sure how the best way to do it is, so i'm open to suggestions (we have a similar issue with ports and varying levels of data available depending upon type and device, and have never solved it acceptably) adam.

          I just had another thought that I wanted to add:

          With the AIX LVM storage modules, it would be useful to show some additional data about the storage devices. LVM has the following additional data that it would be useful for Observium to display:

          Physical Volumes:
          State
          Number of Logical Volumes

          Volume Groups:
          State
          Number of Active Physical Volumes
          Number of Logical Volumes
          Number of Open Logical Volumes

          Logical Volumes:
          State
          Volume Group
          Type

          Filesystem:
          State
          Type
          Logical Volume
          INodes Total / INodes Used

          This type of information would make the storage portion of the UI show as much additional information as the Ports tab and would be extremely valuable for LVM storage devices.

          Anyway, I don't want to get too pie in the sky. First things first, what would be the best way to prevent the hrstorage from discovering and polling, perhaps by an os config element. Second, what would be an easy way to allow the additional storage modules to show their graphs and extra data (maybe additional tabs next to the standard storage Disk Usage tab).

          reinholdmc Michael Reinhold added a comment - I just had another thought that I wanted to add: With the AIX LVM storage modules, it would be useful to show some additional data about the storage devices. LVM has the following additional data that it would be useful for Observium to display: Physical Volumes: State Number of Logical Volumes Volume Groups: State Number of Active Physical Volumes Number of Logical Volumes Number of Open Logical Volumes Logical Volumes: State Volume Group Type Filesystem: State Type Logical Volume INodes Total / INodes Used This type of information would make the storage portion of the UI show as much additional information as the Ports tab and would be extremely valuable for LVM storage devices. Anyway, I don't want to get too pie in the sky. First things first, what would be the best way to prevent the hrstorage from discovering and polling, perhaps by an os config element. Second, what would be an easy way to allow the additional storage modules to show their graphs and extra data (maybe additional tabs next to the standard storage Disk Usage tab).

          People

            adama Adam Armstrong
            reinholdmc Michael Reinhold
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: