The topic for #zenoss is: Zenoss Developers will be here Thursday 11am EDT
9:55:06 AM otakup0pe: oh i forgot about this lil' party
9:59:39 AM otakup0pe: so who likes performance metrics
9:59:56 AM mrayzenoss: oh yeah!
mrayzenoss has changed the topic to: Zenoss Developers are here
10:00:06 AM mrayzenoss: JP and I will be hosting the session today, he should be here in a second
10:00:33 AM otakup0pe: the only question is what's the patch submission process
10:00:46 AM otakup0pe: i meant the only question -i have- is
10:00:48 AM mrayzenoss: other Zenoss devs may come and go, like cgibbons and npmccallum
10:02:11 AM npmccallum: If I'm on IRC, I'm usually idling in here...
10:02:12 AM mrayzenoss: patch submission is easy. Open a ticket, attach the patch. Fill out the contributor agreement and we patch it
10:02:22 AM npmccallum: can't say I'm always around though
10:02:27 AM explosiv0SX: I have a question: shall I just fire it off?
10:02:32 AM jb: sure.
10:02:44 AM otakup0pe: mrayzenoss: word i'll check out the contrib agreement
10:02:54 AM npmccallum: explosiv0SX: go ahead
10:02:59 AM mrayzenoss: otakup0pe: http://www.zenoss.com/forms/contribute
10:03:07 AM explosiv0SX: What's are zenoss' plans re: rest/api or web services going forward?
10:03:24 AM explosiv0SX: I see some xml methods in the source and I see methods that return JSON.
10:03:30 AM explosiv0SX: which is the way forward?
10:03:34 AM mrayzenoss: explosiv0SX: so far it's been kinda ad-hoc, we add things as needed
10:03:52 AM mrayzenoss: we have talked about making it more rigorous and formal, which would be more useful for external users
10:04:16 AM mrayzenoss: not SOAP formal, just standardizing it
10:04:23 AM mrayzenoss: and being consistent
10:04:25 AM explosiv0SX: right -- SOAP is a little heavy-handed.
10:04:35 AM otakup0pe: consistency++
10:04:37 AM explosiv0SX: REST -> XML or JSON is more than fine.
10:05:06 AM explosiv0SX: so no plans to deprecate any of the JSON or XML methods?
10:05:19 AM mrayzenoss: no, everybody uses them
10:05:33 AM mrayzenoss: well, I don't know if every single one is in use
10:05:39 AM explosiv0SX: great.
10:05:40 AM mrayzenoss: but I haven't heard anything about deprecating
10:05:45 AM npmccallum: explosiv0SX: if we do deprecate them, they are marked as such before there removal...
10:05:56 AM otakup0pe: yeah that makes more sense than just leaving them in for ever.
10:06:03 AM mrayzenoss: so you'll have at least a release to get ready
10:06:07 AM explosiv0SX: great.
10:06:10 AM npmccallum: explosiv0SX: but I don't know that we've ever actually removed a method
10:06:10 AM explosiv0SX: thank you.
10:06:17 AM explosiv0SX: doesn't appear so ;-)
10:06:37 AM npmccallum: explosiv0SX: we're a bit like GNOME in that regard
10:06:43 AM explosiv0SX: right on.
10:06:56 AM mrayzenoss: we are planning on deprecating RHEL 4 with the next release, and Zip-style ZenPacks
10:07:05 AM mrayzenoss: not web services, but deprecations
10:07:57 AM npmccallum: and I assume when that happens some code will probably die off at some point, but most of it isn't really external stuff
10:08:22 AM npmccallum: the most important APIs that people care about are usually device and event management
10:08:46 AM otakup0pe: oh here's a question. was there already rest methods for total memory/swap and i just couldn't find them ?
10:09:26 AM npmccallum: otakup0pe: I'm not sure what you mean... are you trying to get the current memory usage on a device?
10:09:38 AM otakup0pe: no the total memory/swap installed on a device
10:09:59 AM otakup0pe: i couldn't find rest methods so i ended up adding them myself heh
10:10:27 AM otakup0pe: i.e. totalSwapString from operatingsystem.py (iirc)
10:11:53 AM explosiv0SX: otakup0pe: you can get it like: find('myserver').os.exportXml(sys.stdout)
10:12:09 AM explosiv0SX: but not sure if that helps because of that pesky output stream parameter.
10:13:00 AM explosiv0SX: btw -- that was written for zendmd.
explosiv0SX is now known as rak (10:13:20 AM)
10:13:44 AM ckrough: What is the recommended datasource type for ethernet traffic? COUNTER or DERIVE? I'm trying to avoid spikes when interface counters roll over unexpectedly.
10:15:22 AM otakup0pe: rak: that answer didn't make sense ? i meant a rest method.
10:15:38 AM otakup0pe: let me just make a patch and it will make sense :3
10:17:46 AM rak: well, this leads to another question:
10:18:03 AM rak: I'd love to get device info with: http://zenoss.corp.goldlasso.com/zport/dmd/Devices/Server/Linux/devices/myserver/exportXml
10:18:09 AM rak: the method is accessed.
10:18:29 AM rak: but an error is thrown saying it's missing a param.
10:18:36 AM rak: This parameter is the output stream.
10:18:58 AM rak: is there anything I can pass to this method so say -- use the current response stream?
10:19:22 AM otakup0pe: http://pastebin.ca/1520574 was all i added btw
10:20:39 AM otakup0pe: hmm exportXml throws not found on some devices and throws an error on other devices for me. but i'm at work where i only have access to the (outdated) vmware appliance
10:20:52 AM rak: cool. I probably could do the same to expose the exportXml function..
10:21:06 AM otakup0pe: yeah the trick is the freakin @rtype tag
10:21:20 AM otakup0pe: that seems to let zope know about the method
10:22:42 AM jplouis: ckrough: I believe zenoss uses DERIVE with a RRD Min of 0 for interfaces
10:23:32 AM ckrough: jplouis: actually, reading up on it just now, the recommended method is COUNTER with a max.
10:24:02 AM ckrough: jplouis: device with a min will get a log of unknowns during normal counter rollovers apparently
10:24:26 AM ckrough: jplouis: derive I mean, not device
10:27:18 AM jplouis: from the RRD docs "so for high bandwidth interfaces and a 32bit counter, DERIVE with min=0 is probably preferable"
10:31:10 AM daMaestro: does anyone know how to create a report that takes interface stats from specific devices and give a total number of bits transferred in a given time period
10:31:24 AM daMaestro: so, it will actually total the rrd data
10:33:02 AM npmccallum: otakup0pe, rak: there is a better way to get things like total memory
10:33:10 AM otakup0pe: npmccallum: hooray !
10:33:27 AM npmccallum: otakup0pe, rak: http://:8080/zport/dmd/Devices/Server/Linux/devices//hw/getProperty?id=totalMemory
10:33:35 AM otakup0pe: nice
10:33:41 AM otakup0pe: getProperty is that a zope thing ?
10:33:42 AM npmccallum: you can do that with any property
10:33:56 AM npmccallum: I don't recall if it is a zope thing or not
10:34:16 AM rak: ok, that'll do nicely.
10:34:22 AM npmccallum: jplouis: do you know if getProperty comes from zope? or is it a zenoss thing?
10:34:37 AM otakup0pe: looks like a zope-cmf thing ?
10:34:48 AM otakup0pe: word thanks man if we are ever at the same conference i'll buy you a beer
10:34:54 AM jplouis: I believe from Zope
10:35:07 AM npmccallum: otakup0pe: let me know what conference to show up to and I'll take you up on it
10:37:26 AM ckrough: jplouis: Im running 64bit counters, take a look at the line in the doc right after the one you pasted, do you take that to mean 64bit with DERIVE and a max, or 64bit with COUNTER and a max
10:37:57 AM npmccallum: otakup0pe: I'll be at OLF
10:39:00 AM jplouis: I read it as COUNTER with a max
10:39:15 AM mrayzenoss: otakup0pe: me too
10:39:32 AM jb: where is OLF?
10:39:55 AM jb: orlando?
10:40:06 AM mrayzenoss: Ohio
10:40:09 AM jb: ah
10:40:11 AM mrayzenoss: Ohio Linux Fest
10:40:13 AM jb: you guys coming to chi anytime soon?
10:40:18 AM mrayzenoss: actually yes
10:40:26 AM mrayzenoss: our Product Manager is headed up there
10:40:37 AM mrayzenoss: not sure who else is going, he's talking to some customers
10:40:46 AM mrayzenoss: jb: are you on the list?
10:41:07 AM jb: hm, I haven't heard anything about it..
10:41:15 AM jb: i went to a campit a few months ago
10:41:38 AM jb: i'd be interested though..
10:42:09 AM otakup0pe: eh i'm in montreal and in the middle of a release cycle so i won't be going to con's any time soon
10:42:16 AM otakup0pe: heh that should have been a sad emoticon
10:42:25 AM mrayzenoss: jb: I'll hook you up, he was looking for customers and core users in Chicago
10:42:33 AM otakup0pe: btw i should have some video of my third gen sl/zenoss mashups once i figure out fraps
10:42:40 AM otakup0pe: and remember how2machinima
10:42:43 AM mrayzenoss: otakup0pe: awesome
10:42:46 AM jb: mrayzenoss: yeah, pass him my contact info if you don't mind..
10:42:48 AM jb: is it brandon?
10:43:27 AM mrayzenoss: yeah
10:43:43 AM jb: argh, i think i actually accidentally deleted an email about vmware from him yesterday
10:44:00 AM mrayzenoss: I'll ask him to resend that too
10:44:17 AM jb: thanks
10:46:47 AM raddy: Hello Everybody
10:47:15 AM raddy: Can anybody suggest a good regexp for monitoring postgres process?
10:48:09 AM raddy: When i just use postgres, it shows lot of processes.
10:49:21 AM npmccallum: isn't postmaster the name of the master process? (I'm just guessing here, its been a while since I used postgres...)
10:49:45 AM npmccallum: woah, I was right: http://www.postgresql.org/docs/8.1/static/app-postmaster.html
10:53:52 AM raddy: Monitoring master process was useless
10:54:08 AM raddy: As the memory usage n'all very 2-5 MB
10:54:25 AM raddy: Monitoring postgres process is important,
10:54:29 AM ckrough: what are you trying to do?
10:57:52 AM jb: however, if postmaster dies, you are SOL
10:59:47 AM raddy: ckrough : I want to monitor postgres memory usage.
11:00:07 AM ckrough: so your not looking for availability, your looking for usage. gotcha
11:04:27 AM mrayzenoss: Just a heads up, the ZenPack Contest only has 9 days left
11:04:41 AM mrayzenoss: so if you were planning on entering, please send it them in soon
11:04:55 AM chudler_: thanks, I have one or two to put in at the last minute.
11:12:11 AM raddy: ckrough : I can monitor availability seperately
11:12:26 AM jb: mrayzenoss: is there any interest in zenpacks that use zenwinperf?
11:12:39 AM raddy: ckrough : I want to monitor performance metrics for postgres process.
11:13:01 AM mrayzenoss: jb: not sure what to do with Enterprise-dependendent zenpacks
11:13:09 AM jb: yeah..
11:19:20 AM otakup0pe: here's another questin actually. what specifically does it mean when getRRDValue returns 204. that the last snmp query failed ?
11:20:03 AM otakup0pe: oh wait it does that for 0 responses nm >_<
11:25:06 AM mrayzenoss: thanks to everyone who stopped by, I'll have a transcript up later on today
11:25:23 AM mrayzenoss: I'll still be around, but the devs are off the hook
mrayzenoss has changed the topic to: Millionth Zenoss Download coming soon: http://tinyurl.com/ncgs5p (11:26:37 AM)
9:55:06 AM otakup0pe: oh i forgot about this lil' party
9:59:39 AM otakup0pe: so who likes performance metrics
9:59:56 AM mrayzenoss: oh yeah!
mrayzenoss has changed the topic to: Zenoss Developers are here
10:00:06 AM mrayzenoss: JP and I will be hosting the session today, he should be here in a second
10:00:33 AM otakup0pe: the only question is what's the patch submission process
10:00:46 AM otakup0pe: i meant the only question -i have- is
10:00:48 AM mrayzenoss: other Zenoss devs may come and go, like cgibbons and npmccallum
10:02:11 AM npmccallum: If I'm on IRC, I'm usually idling in here...
10:02:12 AM mrayzenoss: patch submission is easy. Open a ticket, attach the patch. Fill out the contributor agreement and we patch it
10:02:22 AM npmccallum: can't say I'm always around though
10:02:27 AM explosiv0SX: I have a question: shall I just fire it off?
10:02:32 AM jb: sure.
10:02:44 AM otakup0pe: mrayzenoss: word i'll check out the contrib agreement
10:02:54 AM npmccallum: explosiv0SX: go ahead
10:02:59 AM mrayzenoss: otakup0pe: http://www.zenoss.com/forms/contribute
10:03:07 AM explosiv0SX: What's are zenoss' plans re: rest/api or web services going forward?
10:03:24 AM explosiv0SX: I see some xml methods in the source and I see methods that return JSON.
10:03:30 AM explosiv0SX: which is the way forward?
10:03:34 AM mrayzenoss: explosiv0SX: so far it's been kinda ad-hoc, we add things as needed
10:03:52 AM mrayzenoss: we have talked about making it more rigorous and formal, which would be more useful for external users
10:04:16 AM mrayzenoss: not SOAP formal, just standardizing it
10:04:23 AM mrayzenoss: and being consistent
10:04:25 AM explosiv0SX: right -- SOAP is a little heavy-handed.
10:04:35 AM otakup0pe: consistency++
10:04:37 AM explosiv0SX: REST -> XML or JSON is more than fine.
10:05:06 AM explosiv0SX: so no plans to deprecate any of the JSON or XML methods?
10:05:19 AM mrayzenoss: no, everybody uses them
10:05:33 AM mrayzenoss: well, I don't know if every single one is in use
10:05:39 AM explosiv0SX: great.
10:05:40 AM mrayzenoss: but I haven't heard anything about deprecating
10:05:45 AM npmccallum: explosiv0SX: if we do deprecate them, they are marked as such before there removal...
10:05:56 AM otakup0pe: yeah that makes more sense than just leaving them in for ever.
10:06:03 AM mrayzenoss: so you'll have at least a release to get ready
10:06:07 AM explosiv0SX: great.
10:06:10 AM npmccallum: explosiv0SX: but I don't know that we've ever actually removed a method
10:06:10 AM explosiv0SX: thank you.
10:06:17 AM explosiv0SX: doesn't appear so ;-)
10:06:37 AM npmccallum: explosiv0SX: we're a bit like GNOME in that regard
10:06:43 AM explosiv0SX: right on.
10:06:56 AM mrayzenoss: we are planning on deprecating RHEL 4 with the next release, and Zip-style ZenPacks
10:07:05 AM mrayzenoss: not web services, but deprecations
10:07:57 AM npmccallum: and I assume when that happens some code will probably die off at some point, but most of it isn't really external stuff
10:08:22 AM npmccallum: the most important APIs that people care about are usually device and event management
10:08:46 AM otakup0pe: oh here's a question. was there already rest methods for total memory/swap and i just couldn't find them ?
10:09:26 AM npmccallum: otakup0pe: I'm not sure what you mean... are you trying to get the current memory usage on a device?
10:09:38 AM otakup0pe: no the total memory/swap installed on a device
10:09:59 AM otakup0pe: i couldn't find rest methods so i ended up adding them myself heh
10:10:27 AM otakup0pe: i.e. totalSwapString from operatingsystem.py (iirc)
10:11:53 AM explosiv0SX: otakup0pe: you can get it like: find('myserver').os.exportXml(sys.stdout)
10:12:09 AM explosiv0SX: but not sure if that helps because of that pesky output stream parameter.
10:13:00 AM explosiv0SX: btw -- that was written for zendmd.
explosiv0SX is now known as rak (10:13:20 AM)
10:13:44 AM ckrough: What is the recommended datasource type for ethernet traffic? COUNTER or DERIVE? I'm trying to avoid spikes when interface counters roll over unexpectedly.
10:15:22 AM otakup0pe: rak: that answer didn't make sense ? i meant a rest method.
10:15:38 AM otakup0pe: let me just make a patch and it will make sense :3
10:17:46 AM rak: well, this leads to another question:
10:18:03 AM rak: I'd love to get device info with: http://zenoss.corp.goldlasso.com/zport/dmd/Devices/Server/Linux/devices/myserver/exportXml
10:18:09 AM rak: the method is accessed.
10:18:29 AM rak: but an error is thrown saying it's missing a param.
10:18:36 AM rak: This parameter is the output stream.
10:18:58 AM rak: is there anything I can pass to this method so say -- use the current response stream?
10:19:22 AM otakup0pe: http://pastebin.ca/1520574 was all i added btw
10:20:39 AM otakup0pe: hmm exportXml throws not found on some devices and throws an error on other devices for me. but i'm at work where i only have access to the (outdated) vmware appliance
10:20:52 AM rak: cool. I probably could do the same to expose the exportXml function..
10:21:06 AM otakup0pe: yeah the trick is the freakin @rtype tag
10:21:20 AM otakup0pe: that seems to let zope know about the method
10:22:42 AM jplouis: ckrough: I believe zenoss uses DERIVE with a RRD Min of 0 for interfaces
10:23:32 AM ckrough: jplouis: actually, reading up on it just now, the recommended method is COUNTER with a max.
10:24:02 AM ckrough: jplouis: device with a min will get a log of unknowns during normal counter rollovers apparently
10:24:26 AM ckrough: jplouis: derive I mean, not device
10:27:18 AM jplouis: from the RRD docs "so for high bandwidth interfaces and a 32bit counter, DERIVE with min=0 is probably preferable"
10:31:10 AM daMaestro: does anyone know how to create a report that takes interface stats from specific devices and give a total number of bits transferred in a given time period
10:31:24 AM daMaestro: so, it will actually total the rrd data
10:33:02 AM npmccallum: otakup0pe, rak: there is a better way to get things like total memory
10:33:10 AM otakup0pe: npmccallum: hooray !
10:33:27 AM npmccallum: otakup0pe, rak: http://:8080/zport/dmd/Devices/Server/Linux/devices//hw/getProperty?id=totalMemory
10:33:35 AM otakup0pe: nice
10:33:41 AM otakup0pe: getProperty is that a zope thing ?
10:33:42 AM npmccallum: you can do that with any property
10:33:56 AM npmccallum: I don't recall if it is a zope thing or not
10:34:16 AM rak: ok, that'll do nicely.
10:34:22 AM npmccallum: jplouis: do you know if getProperty comes from zope? or is it a zenoss thing?
10:34:37 AM otakup0pe: looks like a zope-cmf thing ?
10:34:48 AM otakup0pe: word thanks man if we are ever at the same conference i'll buy you a beer
10:34:54 AM jplouis: I believe from Zope
10:35:07 AM npmccallum: otakup0pe: let me know what conference to show up to and I'll take you up on it
10:37:26 AM ckrough: jplouis: Im running 64bit counters, take a look at the line in the doc right after the one you pasted, do you take that to mean 64bit with DERIVE and a max, or 64bit with COUNTER and a max
10:37:57 AM npmccallum: otakup0pe: I'll be at OLF
10:39:00 AM jplouis: I read it as COUNTER with a max
10:39:15 AM mrayzenoss: otakup0pe: me too
10:39:32 AM jb: where is OLF?
10:39:55 AM jb: orlando?
10:40:06 AM mrayzenoss: Ohio
10:40:09 AM jb: ah
10:40:11 AM mrayzenoss: Ohio Linux Fest
10:40:13 AM jb: you guys coming to chi anytime soon?
10:40:18 AM mrayzenoss: actually yes
10:40:26 AM mrayzenoss: our Product Manager is headed up there
10:40:37 AM mrayzenoss: not sure who else is going, he's talking to some customers
10:40:46 AM mrayzenoss: jb: are you on the list?
10:41:07 AM jb: hm, I haven't heard anything about it..
10:41:15 AM jb: i went to a campit a few months ago
10:41:38 AM jb: i'd be interested though..
10:42:09 AM otakup0pe: eh i'm in montreal and in the middle of a release cycle so i won't be going to con's any time soon
10:42:16 AM otakup0pe: heh that should have been a sad emoticon
10:42:25 AM mrayzenoss: jb: I'll hook you up, he was looking for customers and core users in Chicago
10:42:33 AM otakup0pe: btw i should have some video of my third gen sl/zenoss mashups once i figure out fraps
10:42:40 AM otakup0pe: and remember how2machinima
10:42:43 AM mrayzenoss: otakup0pe: awesome
10:42:46 AM jb: mrayzenoss: yeah, pass him my contact info if you don't mind..
10:42:48 AM jb: is it brandon?
10:43:27 AM mrayzenoss: yeah
10:43:43 AM jb: argh, i think i actually accidentally deleted an email about vmware from him yesterday
10:44:00 AM mrayzenoss: I'll ask him to resend that too
10:44:17 AM jb: thanks
10:46:47 AM raddy: Hello Everybody
10:47:15 AM raddy: Can anybody suggest a good regexp for monitoring postgres process?
10:48:09 AM raddy: When i just use postgres, it shows lot of processes.
10:49:21 AM npmccallum: isn't postmaster the name of the master process? (I'm just guessing here, its been a while since I used postgres...)
10:49:45 AM npmccallum: woah, I was right: http://www.postgresql.org/docs/8.1/static/app-postmaster.html
10:53:52 AM raddy: Monitoring master process was useless
10:54:08 AM raddy: As the memory usage n'all very 2-5 MB
10:54:25 AM raddy: Monitoring postgres process is important,
10:54:29 AM ckrough: what are you trying to do?
10:57:52 AM jb: however, if postmaster dies, you are SOL
10:59:47 AM raddy: ckrough : I want to monitor postgres memory usage.
11:00:07 AM ckrough: so your not looking for availability, your looking for usage. gotcha
11:04:27 AM mrayzenoss: Just a heads up, the ZenPack Contest only has 9 days left
11:04:41 AM mrayzenoss: so if you were planning on entering, please send it them in soon
11:04:55 AM chudler_: thanks, I have one or two to put in at the last minute.
11:12:11 AM raddy: ckrough : I can monitor availability seperately
11:12:26 AM jb: mrayzenoss: is there any interest in zenpacks that use zenwinperf?
11:12:39 AM raddy: ckrough : I want to monitor performance metrics for postgres process.
11:13:01 AM mrayzenoss: jb: not sure what to do with Enterprise-dependendent zenpacks
11:13:09 AM jb: yeah..
11:19:20 AM otakup0pe: here's another questin actually. what specifically does it mean when getRRDValue returns 204. that the last snmp query failed ?
11:20:03 AM otakup0pe: oh wait it does that for 0 responses nm >_<
11:25:06 AM mrayzenoss: thanks to everyone who stopped by, I'll have a transcript up later on today
11:25:23 AM mrayzenoss: I'll still be around, but the devs are off the hook
mrayzenoss has changed the topic to: Millionth Zenoss Download coming soon: http://tinyurl.com/ncgs5p (11:26:37 AM)
