|
Replies:
9
-
Last Post:
Aug 8, 2008 2:56 PM
by: eschrock
|
|
|
Posts:
76
From:
Registered:
5/26/06
|
|
|
|
Sensor design doc now available
Posted:
Jun 8, 2007 11:00 AM
|
|
Folks,
Phase I of the Sensor Abstraction Layer project has been posted to the
project page. See http://opensolaris.org/os/project/sensors for more
information.
Cindi
_______________________________________________
fm-discuss mailing list
fm-discuss at opensolaris dot org
|
|
|
Posts:
804
From:
Menlo Park, CA
Registered:
3/9/05
|
|
|
|
Re: Sensor design doc now available
Posted:
Jun 8, 2007 10:48 PM
in response to: cynthia
To: Communities » fm » discuss
|
|
Cool stuff. I haven't finished going over it all, but I did notice one typo:
In section 2.4, in the bottom right table cell:
"indicates whether or not the alert cache should automatically to the resolved state..."
It also looks like section 4.1 could use some formatting ("Ambient air ...")?. I can't really follow this section.
- Eric
|
|
|
|
|
Posts:
804
From:
Menlo Park, CA
Registered:
3/9/05
|
|
|
|
Re: Sensor design doc now available
Posted:
Jun 9, 2007 2:59 PM
in response to: cynthia
To: Communities » fm » discuss
|
|
Cindi -
I've had a chance to take a closer look at the design doc. It all looks
great, though I have a few high-level questions. These might belong as
"future phases", but it would help to have some explanation in the
design document to know that the issues are being considered.
How do indicators relate to this work? I see them mentioned when
disucssing the FMRI syntax, but nowhere else. Are indicators related to
this work beyond the FMRI syntax, or is it completely separate? Is
there a separate project to define the role of indicators in libtopo and
Solaris?
From an implementation perspective, it would help to outline how the
facility nodes would will in libtopo. How do I read sensor values from
the nodes? Do they have all the standard properties of a topo node,
minus the obvious restriction of not having any children?
Is there going to be any standardization on the properties exported by a
sensor node? I'm imagining what it would take to construct a generic
sensor browser. While most of this is outside the scope of phase 1, and
falls under objective #3 (ability to watch sensors), it seems like some
minimal design decisions need to made just to prototype phase 1 and
justify the architecture.
We want the ability to export arbitrary payloads via sensors, but it
seems like if we're not careful we can end up with a fragmented
namespace that makes monitoring difficult. Looking towards the future,
it would seem beneficial to define some common set of properties across
all sensors, even something as basic as "value", "units", and
(optionally) "threshold".
As a nit, does 'RTN' have to be capitalized? It seems like all the
events in the registry use lowercase names, and the all caps name looks
a little off. Although your fmdump example output uses lowercase, so
maybe this is just a case of inconsistency in the document.
Thanks,
- Eric
|
|
|
|
|
Posts:
76
From:
Registered:
5/26/06
|
|
|
|
Re: Re: Sensor design doc now available
Posted:
Jun 10, 2007 2:33 PM
in response to: eschrock
|
|
Eric Schrock wrote:
> Cindi -
>
> I've had a chance to take a closer look at the design doc. It all looks
> great, though I have a few high-level questions. These might belong as
> "future phases", but it would help to have some explanation in the
> design document to know that the issues are being considered.
>
> How do indicators relate to this work? I see them mentioned when
> disucssing the FMRI syntax, but nowhere else. Are indicators related to
> this work beyond the FMRI syntax, or is it completely separate? Is
> there a separate project to define the role of indicators in libtopo and
> Solaris?
Support for indicators are really orthogonal to this project but I have
included the definition as part of the facility definition as it makes
sense.
>
>>From an implementation perspective, it would help to outline how the
> facility nodes would will in libtopo. How do I read sensor values from
> the nodes? Do they have all the standard properties of a topo node,
> minus the obvious restriction of not having any children?
Implemtation-wise, facility (sensor and indicator) nodes are just leaf
topo nodes. We can attach properties and methods just like we do for
other types of topo nodes. I see the manipulation and access of
indicators happening via topo methods exported by (hopefully) standard
properties. In this way, the consumer of an indicator does not need to
know the implementation details of how we read or write an indicator.
This is similar to the sensor provider layer but can happen as soon as
we support facilities in libtopo rather than a future phase of this
project. Your point below applies here as well. We need to come up
with a standard name-type space for indicator props.
I have working prototype of topo facility nodes so we can start thinking
about this right away.
>
> Is there going to be any standardization on the properties exported by a
> sensor node? I'm imagining what it would take to construct a generic
> sensor browser. While most of this is outside the scope of phase 1, and
> falls under objective #3 (ability to watch sensors), it seems like some
> minimal design decisions need to made just to prototype phase 1 and
> justify the architecture.
>
> We want the ability to export arbitrary payloads via sensors, but it
> seems like if we're not careful we can end up with a fragmented
> namespace that makes monitoring difficult. Looking towards the future,
> it would seem beneficial to define some common set of properties across
> all sensors, even something as basic as "value", "units", and
> (optionally) "threshold".
Agreed and the sooner we start thinking about what we want to monitor
and how the sooner we can define the namespace. If you have any ideas,
I would like to hear them.
>
> As a nit, does 'RTN' have to be capitalized? It seems like all the
> events in the registry use lowercase names, and the all caps name looks
> a little off. Although your fmdump example output uses lowercase, so
> maybe this is just a case of inconsistency in the document.
We've gone back and forth on that. The fault manager tends to use caps
for acronyms (FRU, ASRU, etc...) so I tried to be consistent with that.
>
> Thanks,
>
> - Eric
> --
> This message posted from opensolaris.org
> _______________________________________________
> fm-discuss mailing list
> fm-discuss at opensolaris dot org
_______________________________________________
fm-discuss mailing list
fm-discuss at opensolaris dot org
|
|
|
|
|
Posts:
1,364
From:
US
Registered:
4/27/05
|
|
|
|
Re: Re: Sensor design doc now available
Posted:
Jun 10, 2007 3:55 PM
in response to: cynthia
|
|
So we have sensors, and indicators. What about control points? E.g. I
want to be able to have a common framework for fans, etc. (That way I
can have a rule that says
if (component.temp() > component.temp.warn_threshold() &&
component.has_fan() && component.fan.get_speed() <
component.fan.maxspeed()) {
component.fan.increase_speed();
}
without knowing anything about the implementation of component, or fans.
Also, is this framework really just for system-health related items, or
should there be some overlap, e.g. with lid switches on laptops? (Which
are just another sensor, in implementation.)
-- Garrett
cindi wrote:
>
>
> Eric Schrock wrote:
>> Cindi -
>>
>> I've had a chance to take a closer look at the design doc. It all looks
>> great, though I have a few high-level questions. These might belong as
>> "future phases", but it would help to have some explanation in the
>> design document to know that the issues are being considered.
>>
>> How do indicators relate to this work? I see them mentioned when
>> disucssing the FMRI syntax, but nowhere else. Are indicators related to
>> this work beyond the FMRI syntax, or is it completely separate? Is
>> there a separate project to define the role of indicators in libtopo and
>> Solaris?
>
> Support for indicators are really orthogonal to this project but I
> have included the definition as part of the facility definition as it
> makes sense.
>
>>
>>> From an implementation perspective, it would help to outline how the
>> facility nodes would will in libtopo. How do I read sensor values from
>> the nodes? Do they have all the standard properties of a topo node,
>> minus the obvious restriction of not having any children?
>
> Implemtation-wise, facility (sensor and indicator) nodes are just leaf
> topo nodes. We can attach properties and methods just like we do for
> other types of topo nodes. I see the manipulation and access of
> indicators happening via topo methods exported by (hopefully) standard
> properties. In this way, the consumer of an indicator does not need
> to know the implementation details of how we read or write an indicator.
>
> This is similar to the sensor provider layer but can happen as soon as
> we support facilities in libtopo rather than a future phase of this
> project. Your point below applies here as well. We need to come up
> with a standard name-type space for indicator props.
>
> I have working prototype of topo facility nodes so we can start
> thinking about this right away.
>
>>
>> Is there going to be any standardization on the properties exported by a
>> sensor node? I'm imagining what it would take to construct a generic
>> sensor browser. While most of this is outside the scope of phase 1, and
>> falls under objective #3 (ability to watch sensors), it seems like some
>> minimal design decisions need to made just to prototype phase 1 and
>> justify the architecture.
>>
>> We want the ability to export arbitrary payloads via sensors, but it
>> seems like if we're not careful we can end up with a fragmented
>> namespace that makes monitoring difficult. Looking towards the future,
>> it would seem beneficial to define some common set of properties across
>> all sensors, even something as basic as "value", "units", and
>> (optionally) "threshold".
>
> Agreed and the sooner we start thinking about what we want to monitor
> and how the sooner we can define the namespace. If you have any
> ideas, I would like to hear them.
>
>>
>> As a nit, does 'RTN' have to be capitalized? It seems like all the
>> events in the registry use lowercase names, and the all caps name looks
>> a little off. Although your fmdump example output uses lowercase, so
>> maybe this is just a case of inconsistency in the document.
>
> We've gone back and forth on that. The fault manager tends to use
> caps for acronyms (FRU, ASRU, etc...) so I tried to be consistent with
> that.
>>
>> Thanks,
>>
>> - Eric
>> --
>> This message posted from opensolaris.org
>> _______________________________________________
>> fm-discuss mailing list
>> fm-discuss at opensolaris dot org
> _______________________________________________
> fm-discuss mailing list
> fm-discuss at opensolaris dot org
_______________________________________________
fm-discuss mailing list
fm-discuss at opensolaris dot org
|
|
|
|
|
Posts:
76
From:
Registered:
5/26/06
|
|
|
|
Re: Re: Sensor design doc now available
Posted:
Jun 10, 2007 5:51 PM
in response to: gdamore
|
|
Garrett D'Amore wrote:
> So we have sensors, and indicators. What about control points? E.g. I
> want to be able to have a common framework for fans, etc. (That way I
> can have a rule that says
>
> if (component.temp() > component.temp.warn_threshold() &&
> component.has_fan() && component.fan.get_speed() component.fan.maxspeed()) {
> component.fan.increase_speed();
> }
>
> without knowing anything about the implementation of component, or fans.
We could extend the facility type to include component associations like
fans. In that way, we can define:
hc://chassis=0/fan=0
hc://chassis=0/chip=1/cpu=0
hc://chassis=0/chip=1/cpu=0?control=hc://chassis=0/fan=0
hc://chassis=0/chip=1/cpu=0?sensor=temperature
With libtopo, you may export these FMRIs with properties and methods,
such that:
hc://chassis=0/fan=0
property list:
fan-maxspeed=100
fan-get-speed() (property method)
fan-set-speed()
hc://chassis=0/chip=1/cpu=0
property list:
get-temp()
hc://chassis=0/chip=1/cpu=0?sensor=temperature
property list:
get-temp()
warn-threshold()
Of course, we could probably do the same thing with properties attached
to the CPU temperature sensor node and not extend the FMRI namespace:
hc://chassis=0/chip=1/cpu=0?sensor=temperature
property list:
get-temp()
warn-threshold()
fan=hc://chassis=0/fan=0
fan-maxspeed=100
fan-get-speed()
fan-set-speed()
BTW, libtopo documentation is coming very soon along with an updated
version of the fmd programmer's reference manual.
> Also, is this framework really just for system-health related items, or
> should there be some overlap, e.g. with lid switches on laptops? (Which
> are just another sensor, in implementation.)
If you're asking is this a framework suitable for system events, I'd say
no and refer you to sysevent. If you're asking can sysevents be used in
telemetry analysis, I'd say yes.
Cindi
_______________________________________________
fm-discuss mailing list
fm-discuss at opensolaris dot org
|
|
|
|
|
Posts:
79
From:
CA
Registered:
6/14/05
|
|
|
|
Re: Re: Sensor design doc now available
Posted:
Jun 12, 2007 10:09 AM
in response to: gdamore
To: Communities » fm » discuss
Cc: OpenSolaris » discuss
|
|
> Agreed and the sooner we start thinking about what we want to monitor
> and how the sooner we can define the namespace. If you have any
> ideas, I would like to hear them.
For the "how" part, why not simply use SNMP. Sensor monitoring is included in net-snmp 5.4.1 (and other versions). It currently uses the LM-SENSORS-MIB, which is really old and clumsy and designed specifically for the LM75 chip.
I'd like to see us create a new, up-to-date MIB to specifically support Sun sensors, but given this is an open source project, perhaps we could approach the open source sensors community and work towards a common MIB.
|
|
|
|
|
Posts:
1
From:
Prague
Registered:
2/7/08
|
|
|
|
Re: Sensor design doc now available
Posted:
Jul 25, 2008 4:15 AM
in response to: cynthia
To: Communities » fm » discuss
|
|
Sorry for maybe offtopic question.
What is the current state of the project? Is it still alive? Where can I get some info?
Thanks,
Pavel.
|
|
|
|
|
Posts:
804
From:
Menlo Park, CA
Registered:
3/9/05
|
|
|
|
Re: Sensor design doc now available
Posted:
Jul 25, 2008 10:17 AM
in response to: pavel_b
|
|
On Fri, Jul 25, 2008 at 04:15:34AM -0700, Pavel Bures wrote:
> Sorry for maybe offtopic question.
> What is the current state of the project? Is it still alive? Where can I get some info?
The first phase of this - libtopo facility nodes and support for
IPMI-based sensors - will be putback to the current build (96). This
will be followed shortly after by support for SES sensors and
indicators, hopefully also in build 96.
After that, the immediate plan is to add support for fan and PSU
diagnosis based on this sensor data, as well as generalizing the
disk-monitor module to manage indicators for disks in SES enclosures.
The long term plans described in the design doc (alerts, monitors, etc)
are less clear, but we'll working on those once the immediate objectives
are achieved.
Hope that helps,
- Eric
--
Eric Schrock, Fishworks http://blogs.sun.com/eschrock
_______________________________________________
fm-discuss mailing list
fm-discuss at opensolaris dot org
|
|
|
|
|
Posts:
804
From:
Menlo Park, CA
Registered:
3/9/05
|
|
|
|
Re: Sensor design doc now available
Posted:
Aug 8, 2008 2:56 PM
in response to: eschrock
|
|
FYI -
The first phase of this was putback to snv_96 as planned. Blog entries
here:
http://blogs.sun.com/robj/entry/a_sensor_abstraction_layer_for
http://blogs.sun.com/eschrock/entry/ses_sensors
As for the next phases, I'm about halfway done with a fan/psu diagnosis
prototype so that one shouldn't take too long.
- Eric
On Fri, Jul 25, 2008 at 10:17:03AM -0700, Eric Schrock wrote:
> On Fri, Jul 25, 2008 at 04:15:34AM -0700, Pavel Bures wrote:
> > Sorry for maybe offtopic question.
> > What is the current state of the project? Is it still alive? Where can I get some info?
>
> The first phase of this - libtopo facility nodes and support for
> IPMI-based sensors - will be putback to the current build (96). This
> will be followed shortly after by support for SES sensors and
> indicators, hopefully also in build 96.
>
> After that, the immediate plan is to add support for fan and PSU
> diagnosis based on this sensor data, as well as generalizing the
> disk-monitor module to manage indicators for disks in SES enclosures.
>
> The long term plans described in the design doc (alerts, monitors, etc)
> are less clear, but we'll working on those once the immediate objectives
> are achieved.
>
> Hope that helps,
>
> - Eric
>
> --
> Eric Schrock, Fishworks http://blogs.sun.com/eschrock
> _______________________________________________
> fm-discuss mailing list
> fm-discuss at opensolaris dot org
--
Eric Schrock, Fishworks http://blogs.sun.com/eschrock
_______________________________________________
fm-discuss mailing list
fm-discuss at opensolaris dot org
|
|
|
|
|
