Observium IPMI pass-through

Leave a Reply

Comment as a guest.

 
  1. Thanks for the idea, I implemented something similar (but using the new unix agent architecture instead of the ugly snmp extends) in r3781 today.

    1. Yeah, I think at the time I added the above quick hack, the unix agent subsystem was not yet available in Observium. It will make adding regular apps/services much easier. Will check your rev soon, thanks for adding it.

    1. Hi Martin, this was pretty old code, and in the meantime, a lot has changed within Observium. I’ve updated the post with a better way of doing it.

  2. Without any details it’s hard to know what the problem could be.

    Please use the instructions in the beginning of the post (UPDATE 05/04), and check logs to make sure Observium can connect to xinetd/check_mk. Use ./poller.php -d -h in the Observium path to see the debugging details.

    Also, make sure ipmitool sensor does not generate any errors on the client.

    1. I appreciate your help 🙂

      I’ve checked everything I can think of. I can see the data is provided correctly on the client server. Running the poller on the Observium machine with debug shows that it’s reading the information correctly (voltages, fan speed, etc) however nothing is being shown in Observium for this particular machine. I just don’t know why.

      1. What do you see on the Settings > Sensors page for the specific client ?

        Normally it should show all the sensors that have been found.

        Also, you did add the 2 additional columns in the database ?

        If the sensors do not show on the Sensors settings page, look at the debug info of ./poller.php -d for INSERT queries. It should normally execute these queries for adding the sensors. Copy/paste one of these queries and see what your SQL server reports as error.

        Query should be something similar to
        INSERT INTO `sensors` (`poller_type`,`sensor_class`,`device_id`,`sensor_oid`,`sensor_index`,`sensor_type`,`sensor_descr`,`sensor_divisor`,`sensor_multiplier`,`sensor_limit`,`sensor_limit_warn` ,`sensor_limit_low`,`sensor_limit_low_warn`,`entPhysicalIndex`,`entPhysicalIndex_measured`,`measured_class`,`measured_entity`) VALUES (‘agent’,’power’,’10’,”,’6′,’agent’,’Power Supply 1′,’1′,’1′,’142.5′,”,”,”,”,”,”,”);

        1. There’s nothing on the sensors page for this particular device. I didn’t need to add the additional columns as they were already in place (I have other servers that poll IPMI but using an actual IPMI device). I saved the output of poller.php -d and there are no INSERT commands at all. With discovery.php -d there are 2 INSERT commands but nothing to do with the sensors.

          I can see in the poller.php -d output that sensors have been found though – the data is listed at the start. Running check_mk_agent on the client machine returns all of the correct data too.

  3. Not sure if it’s related.. but I’ve just discovered that since updating to the latest Observium.. all my graphing has stopped working completely too!

  4. DO NOT TELL PEOPLE TO MODIFY THEIR DATABASE STRUCTURE

    I WILL FIND YOU AND PUNCH YOU IN YOUR FUCKING HEAD.

      1. We have an autoupdate mechanism which relies on the database being in an expected state. You can’t modify it yourself.

        Similarly you can’t tell people to modify code, because that breaks the SVN updating system to.

        1. You are right, since my Observium was on dbSchema 61, and it did not include those columns, I foolishly thought it was not (yet) included in the update.

          Not sure why it did not use 044.sql to update the db, which Tom pointed out includes the specific sql queries.

          Will refrain from posting core code updates in the future, with Check_MK this will not be necessary anymore anyway.

Read Next

Sliding Sidebar