- observium - lists.observium.org

Ubuntu Distro Upgrade
by Peter Derissen 14 Mar '19

14 Mar '19

Hello, Currently we are running Observium Pro 19.2.9712 (stable) on Ubuntu 16.04.6 LTS Can I run a Distro upgrade to 18.04.2 without any problems? Met vriendelijke groet, Peter Derissen Eurofiber Nederland Network Engineer Safariweg 25-31 +31 (0)6 11587110 3605 MA Maarssen [EF-logo_rood_RGB -handtekening]<http://www.eurofiber.nl/> Volg ons op Twitter<https://twitter.com/Eurofiber> | Linkedin<https://www.linkedin.com/company/eurofiber> | Youtube<https://www.youtube.com/user/Eurofibergroup> ******** IMPORTANT NOTICE ******** This e-mail (including any attachments) may contain information that is confidential or otherwise protected from disclosure and it is intended only for the addressees. If you are not the intended recipient, please note that any copying, distribution or other use of information contained in this e-mail (and its attachments) is not allowed. If you have received this e-mail in error, kindly notify us immediately by telephone or e-mail and delete the message (including any attachments) from your system. Please note that e-mail messages may contain computer viruses or other defects, may not be accurately replicated on other systems, or may be subject of unauthorized interception or other interference without the knowledge of sender or recipient. Eurofiber only sends and receives e-mails on the basis that Eurofiber is not responsible for any such computer viruses, corruption or other interference or any consequences thereof. Eurofiber Nederland B.V. is registered in the Chamber of Commerce of Amsterdam with number 34134377, VAT number NL 8088.51.524 B01. Eurofiber N.V. has its registered office at Belgicastraat 5 bus 7, 1930 Zaventem and is registered under national number 0435.204.851.

5 6

Oxidized for config management & notifications
by Colin Stubbs 14 Mar '19

14 Mar '19

All, I've added the first stage of a patch for better Oxidized support via the existing JIRA ticket from 2016, https://jira.observium.org/browse/OBS-1986 What I'm building is what I've described in the JIRA comment, which basically means that we shift to using the Oxidized API properly rather than files on an immediately accessible filesystem. Not too hard to write and the rest of it'll be done shortly. But I am very interested in feedback about Oxidized. Particularly as the project is in need of maintainers to really keep it going - https://github.com/ytti/oxidized#help-needed Are you using it? How well's it going? Do you agree with what I'm proposing to add to Observium and see value in it? (See below) OR; have you found something better and have since moved away from Oxidized to another OSS or a COTS product? NOTE: Rants about Ruby/Oxidized or SVN/git being bad exist in the same leaky mentally challenged boat as rants about RANCID/Perl being bad. Don't bother. At the moment the main thing that's missing from the existing reuse of the RANCID code in an Oxidized environment; is the ability to see diffs when it's a git repo rather than Subversion. A secondary issue with the existing RANCID support is that the Observium web interface needs access to SVN/configs via the file system. So you either need run Oxidized on the same box; or export the file system to it using NFS/etc. There's a lot of reasons why you might be wanting to run Oxidized elsewhere and don't want to expose a file system from it back to your Observium implementation. -- From JIRA -- The ideal integration here would actually utilise the Oxidized API so the Oxidized system can exist anywhere; rather than on a file system immediately accessible to the Observium webUI. e.g. config from https://oxidized-not-obserivum-server.org.tld/node/fetch/[NODE] Observium would also expose a list of hosts (may already be in API?); that Oxidized would use as a list of devices to monitor, https://github.com/ytti/oxidized/blob/master/docs/Sources.md#source-http Syslog (SNMP trap to syslog where necessary) alerting matches for config change events would trigger Oxidized based collection of new config; which in turn would trigger Oxidized based alerts in close to real time for changes. -Colin

2 2

observium alerting not working any more in last version?
by Farshid Abediny 12 Mar '19

12 Mar '19

Hello, we are using observium community edition and in last version we were able to add alert checker but in latest version its not possible, should we upgrade to pro version? THnak you.

3 2

Re: [Observium] Ignoring Interfaces in Discovery
by Mike Stupalov 08 Mar '19

08 Mar '19

Hi, really as I see, this is firmware/hardware issue. Better write TAC to Cisco. I added ifType ignoring in validate ports (for this os) in r9755. But I see too many not exist Oids, I'm not sure this will help you.. Benjamin Moore wrote on 07/03/2019 17:58: > This is a cisco RV340 small business router > > On Thu, Mar 7, 2019 at 1:47 AM Mike Stupalov <mike(a)observium.org > <mailto:mike@observium.org>> wrote: > > Hi, > > what OS on device? > > Please show/attach debug discovery for device: > ./discovery.php -d -h <device> > > And snmpwalk for ifTable: > > snmpwalk -v2c -c <community> -m IF-MIB <device> .1.3.6.1.2.1.2.2 > > Yes, Ports ignored because empty ifType. > Usually it makes no sense to observe them, because all other > counters are missing too. > > But if in ifTable exist counters for this device, I will add > exclude for os. > > Benjamin Moore via observium wrote on 06/03/2019 20:25: >> Can someone tell me how to get Observium to NOT ignore >> interfaces? I'm assuming that it is ignoring them due to the >> fact that they don't have ifTypes assigned - >> ##### Module Start: ports ##### >> >> o Caching OIDs ifDescr ifAlias ifName ifType ifOperStatus >> o Caching DB 0 ports >> o Discovering ports XX VLAN1(12)XXXXXXXX >> +---------+-----------+-----------+---------+--------+-------------+---------+ >> | ifIndex | ifDescr | ifName | ifAlias | ifType | Oper >> Status | Ignored | >> +---------+-----------+-----------+---------+--------+-------------+---------+ >> | 9 | WAN2 | WAN2 | ... | | >> | yes | >> | 10 | WAN1 | WAN1 | ... | | | >> yes | >> | 12 | VLAN1 | VLAN1 | ... | l2vlan | >> | no | >> | 25 | LAN4 | LAN4 | ... | | down >> | yes | >> | 26 | LAN3 | LAN3 | ... | | down | >> yes | >> | 27 | LAN2 | LAN2 | ... | | down >> | yes | >> | 28 | LAN1 | LAN1 | ... | | up >> | yes | >> | 29 | WAN_PORT1 | WAN_PORT1 | ... | | up >> | yes | >> | 30 | WAN_PORT2 | WAN_PORT2 | ... | | down >> | yes | >> | 51 | USB1 | USB1 | ... | usb | >> | yes | >> | 52 | USB2 | USB2 | ... | usb | | >> yes | >> +---------+-----------+-----------+---------+--------+-------------+---------+ >> LAN1 and WAN PORT 1 are the two interfaces I need to have monitored. >> _______________________________________________ >> observium mailing list >> observium(a)observium.org <mailto:observium@observium.org> >> http://postman.memetic.org/cgi-bin/mailman/listinfo/observium > > -- > Mike Stupalov > Observium Limited, http://observium.org > -- Mike Stupalov Observium Limited, http://observium.org

1 0

Re: [Observium] Ignoring Interfaces in Discovery
by Benjamin Moore 08 Mar '19

08 Mar '19

Just checking - did you get my response? On Thu, Mar 7, 2019 at 8:58 AM Benjamin Moore <buldamoosh(a)gmail.com> wrote: > This is a cisco RV340 small business router > > On Thu, Mar 7, 2019 at 1:47 AM Mike Stupalov <mike(a)observium.org> wrote: > >> Hi, >> >> what OS on device? >> >> Please show/attach debug discovery for device: >> ./discovery.php -d -h <device> >> >> And snmpwalk for ifTable: >> >> snmpwalk -v2c -c <community> -m IF-MIB <device> .1.3.6.1.2.1.2.2 >> >> Yes, Ports ignored because empty ifType. >> Usually it makes no sense to observe them, because all other counters >> are missing too. >> >> But if in ifTable exist counters for this device, I will add exclude for >> os. >> >> Benjamin Moore via observium wrote on 06/03/2019 20:25: >> >> Can someone tell me how to get Observium to NOT ignore interfaces? I'm >> assuming that it is ignoring them due to the fact that they don't have >> ifTypes assigned - >> ##### Module Start: ports ##### >> >> o Caching OIDs ifDescr ifAlias ifName ifType ifOperStatus >> o Caching DB 0 ports >> o Discovering ports XX VLAN1(12)XXXXXXXX >> >> +---------+-----------+-----------+---------+--------+-------------+---------+ >> | ifIndex | ifDescr | ifName | ifAlias | ifType | Oper Status | >> Ignored | >> >> +---------+-----------+-----------+---------+--------+-------------+---------+ >> | 9 | WAN2 | WAN2 | ... | | | yes >> | >> | 10 | WAN1 | WAN1 | ... | | | yes >> | >> | 12 | VLAN1 | VLAN1 | ... | l2vlan | | no >> | >> | 25 | LAN4 | LAN4 | ... | | down | yes >> | >> | 26 | LAN3 | LAN3 | ... | | down | yes >> | >> | 27 | LAN2 | LAN2 | ... | | down | yes >> | >> | 28 | LAN1 | LAN1 | ... | | up | yes >> | >> | 29 | WAN_PORT1 | WAN_PORT1 | ... | | up | yes >> | >> | 30 | WAN_PORT2 | WAN_PORT2 | ... | | down | yes >> | >> | 51 | USB1 | USB1 | ... | usb | | yes >> | >> | 52 | USB2 | USB2 | ... | usb | | yes >> | >> >> +---------+-----------+-----------+---------+--------+-------------+---------+ >> LAN1 and WAN PORT 1 are the two interfaces I need to have monitored. >> >> _______________________________________________ >> observium mailing listobservium@observium.orghttp://postman.memetic.org/cgi-bin/mailman/listinfo/observium >> >> >> -- >> Mike Stupalov >> Observium Limited, http://observium.org >> >>

1 0

Re: [Observium] OBS-2925 - Ping Only Hosts / OBS_SNMP_SKIP flag / snmp_skip attribute
by Colin Stubbs 07 Mar '19

07 Mar '19

I know where you're at... but, 0) No refactoring required - this is part of the point of the patch ( I would not have even attempted this if it wasn't so easy... ) and my long writeup for Mike given he hadn't actually looked at JIRA yet. Uses existing code/architecture - bit flag and device attributes - to mark a device as "don't do any SNMP to this device right now" 1) Observium uses fping... 2) Smokeping is horrible - can provide great value sure, but horrible to use, and again, extra tool. I'm a long way from unfamiliar with it and have both used it many years ago, and considered it for our current environments. Not useful to us. 3) Smokeping is not integrated to Observium if the device is not monitored by SNMP - this is fine when it's just you or a small team of people who understand this and are happy to flick between interfaces and how to work with Smokeping. Not great when you have a larger team and you really just need one interface on a monitor in your operations room that tells everyone everything that's up/down/problematic right now. Particularly not fine when your level 1's can't really login on CLI and edit config files etc. 4) IP SLA's - vendor specific thing. I love them in the right environment. Fantastic tool and capability to have in a network. We have zero Cisco in this situation and don't want to add a device specifically for this. 5) Your description sounds like it's just you in this environment... and if email fails, or you're hit by a bus, no one else knows there's a problem let alone how your alerting solution works and how to maintain it. Also, manual investigation/access to history. By having Observium do the ping we get to leverage the alerting capabilities inherent to it, e.g. email/webhook/PagerDuty/OpsGenie/VictorOps etc etc etc., as well as the webUI for visual alert notification and access to graphs/history. It's actually a simpler and cleaner solution; unless you value seeing the min/max/average/jitter values that IP SLA or Smokeping can help you see. In which case it's not what you need. -Colin Email: cstubbs @ gmail . com On Sun, 3 Mar 2019 at 22:44, Ryan Huff <ryanhuff(a)outlook.com> wrote: > I really do understand this Colin, on a deeper level than you might > imagine ;). I have no vested interest either way personally, I’m just > offering some unsolicited thoughts... > > I always looked at this specific topic like asking a 10lbs. (4.5kg or > 0.7149 stones) sledge hammer to drive a nail. Sure, it can do it but it’ll > probably be messy and ugly because a sledge hammer was never meant to drive > nails, and when you use tools in ways they weren’t really designed for, > things can get messy. Just use a hammer instead. > > I have done three things to achieve icmp only monitoring and also stick > within the base code (as a developer, I hate mucking with base code or > re-inventing wheels when I want to do different things). Icmp-only > monitoring to me, always just seemed silly (not in purpose) to try and work > into an existing and established application that didn’t already do it. > > It’s just too easy of a problem to solve otherwise, than to go to the > time/expense of refactoring an application IMHO. > > - I use RTT SLAs to monitor next hop devices (which OBS is fabulous at > picking up), assuming the device hopped from is SLA capable and OBS > monitored. > > - I use Fping (Smokeping) integrated with OBS. Using the Smokeping web > wrapper makes a great RTT only tool, and you also have the OBS integration > for when it makes sense to use on OBS devices. > > - I have a small (very small) bash script that reads a text file of IP > address and launches one thread per device to run continuous pings. Not a > very scalable script, but like you, I only need it for a very few limited > cases. The script uses sendmail to email me if it can’t reach something. > > Thanks, > > Ryan > > On Mar 3, 2019, at 06:35, Colin Stubbs via observium < > observium(a)observium.org> wrote: > > Hi Mike, > > They're in the JIRA ticket, but sure, here's some inserted to this email. > > I'm aware of Adam/your preference to reject or simply ignore the regular > requests for this kind of feature, and the confusion it causes new users > considering Observium for use in their organisations when they find out > they can't do the most basic of monitoring to something using Observium. > > A great many of your users would gain a lot of value from being able to > add a few ping only hosts. > > Why build, manage and integrate (to other tools) another ping based > monitoring system when all you need is to monitor a handful of devices with > ping only; simply because those devices fail to offer SNMP for some reason? > > Anything that does have a working SNMP service can and should be monitored > with SNMP to gain greater insight into what's happening on it... but not > everything does. > > No one in their right mind should attempt to use Observium as a system > which monitors massive numbers of DNS names or IP's with ping only, there > are better systems out there for that, but there are so many situations in > a which an Observium install can and should be able to monitor some devices > ping only. > > I've associated the ticket with the two previous JIRA requests for this > feature; which Adam rejected. > > They were just feature requests as I recall; no code proposed. Totally > understandable you guys didn't want to work on the feature when it's not > really what you feel Observium is for. > > Rejecting this now when you have just been gifted working code, that > modifies things fairly minimally, and simply leverages the ping information > that's already occurring to each and every device (that ping is not > disabled for), and uses an existing method to mark devices so that further > SNMP based polling does not occur... would make no sense. > > That said; I totally understand if you want me to fix/add/improve things > before considering it further - simply communicate what's necessary and > I'll do that. > > So, for anyone else on the list, who wants the feature; now is your best > chance to add your voice and explain why this kind of feature is of use to > you. Because you're probably not going to get it otherwise. > > We've been using this internally since early 2017... I just got around to > updating Observium to the latest and greatest (reasons, terrible terrible > reasons...), and had to update my patch. > > But, I'd really prefer not to have to maintain a patch, and I definitely > don't want to have to publish it so others can use it and cause Observium > Ltd further dramas because of it. > > How many hosts do we monitor ping only? > > Six. A grand total of six. Everything else has SNMP in some form; and we > want as much info as we can extract from them via it - which is why we love > Observium. Nothing else compares for SNMP based monitoring IMHO. > > Most of those ping only devices are next hop service provider devices just > outside our network, for which they won't give us any kind of SNMP access. > Ping'ing them offers a small (very small!) degree of insight into link > latency/loss from us to them (manual comparison I must admit), and/or > potential device problems for the thing that's currently responding for > that IP. > > Hey look... a perfect use case for this feature... > > The others are devices that we use but which simply don't offer SNMP > because vendor X didn't bother to add net-snmp to their standard build for > CentOS/Ubuntu/whatever weird and wonderful Linux distro they built them on; > when they really should have. Don't care much just need to know they're on > the network in some way and want a long track record of response time to > them. > > Hey look... a perfect use case for this feature... > > Not surprisingly we don't want to have to operate and maintain a separate > system for six IP's. Alerting can be flappy because Observium/fping is only > sending a single ICMP echo - we're OK with that and don't even really want > more pings which would lead to average values anyway - and we've worked > around flaps with delays and automatic suppression of duplicate alerts in > our alert management and escalation tool. > > The six are monitored by IP; the DNS hostname test below was simply to > double check there was no issue with this and a DNS name. Just a hostname > that I've never managed to forget and use a lot to ping test connectivity > out. > > Also, I just realised that the "Skip ping" option is no longer > automatically hidden in device settings when "Skip SNMP" is checked; I'll > add an updated diff in JIRA shortly after I look at the JS for that again. > > <Capture.PNG> > > <observium_ping_only_screens3.PNG> > > <observium_ping_only_screens4.png> > > <observium_ping_only_screens5.PNG> > > > On Sun, 3 Mar 2019 at 18:07, Mike Stupalov <mike(a)observium.org> wrote: > >> Ohh my dear.. >> >> Which really benefit to use Observium for ping_only hosts? >> >> Pls show (screenshots) how this devices displayed on your install. >> >> Colin Stubbs via observium wrote on 03/03/2019 07:43: >> >> >> For the benefit of anyone on the list who doesn't use JIRA... and also so >> that others who support (want/need) this feature can comment. >> >> https://jira.observium.org/browse/OBS-2925 >> <https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fjira.obse…> >> >> Attached patch defines OBS_SNMP_SKIP flag and uses snmp_skip device >> attribute, similar to OBS_PING_SKIP and ping_skip, in order to have hosts >> that are ping only. >> >> Ping only hosts can still have the Observium Unix Agent installed >> (tested), and other poller modules such as IPMI enabled (untested). >> >> Tested: >> >> 1. Add/remove/rename ping only hosts via CLI >> 2. Add/remove ping only hosts via webUI >> 3. View/interact ping only hosts via webUI - SNMP specific >> features/menus etc are hidden while skip SNMP is enabled >> 4. Alerting - device_status equals 0 && device_status_type equals >> ping - will trigger alerts for host down/recovery events >> 5. Shifting a previously SNMP contactable host to ping only by >> ticking skip SNMP box - old SNMP graphs/etc are maintained and remain >> available - remove skip SNMP box and SNMP polling begins again >> >> Things I know kind of don't work right now: >> >> 1. Location override - poller/discovery doesn't seem to perform >> geocoding and whatever else is happening there >> >> Things that could be improved: >> >> 1. Unix Agent poller module etc is enabled by default for all hosts, >> for ping only hosts, perhaps it should be disabled by default? Will improve >> performance by reducing the number of processes that hang while the 10s >> default connect timeout happens. >> >> Totally untested: >> >> 1. Use of autodiscovery SNMP skip - should work in theory, unsure if >> those parts of the patch should actually be used though. Some people out >> there may actually want to add anything that does respond to ping and can >> be found thru adjacency and routing protocol info etc?? >> >> >> >> Patch generated from recent trunk, touches files as below, >> >> [root@desktop observium]# diff -r -u observium-trunk root | grep -v >> ^Only > ping_only_hosts.diff >> [root@desktop observium]# cd root >> [root@desktop root]# svn status >> M add_device.php >> M html/pages/addhost.inc.php >> M html/pages/device/edit/device.inc.php >> M html/pages/device/edit.inc.php >> M html/pages/device/graphs.inc.php >> M html/pages/device/perf.inc.php >> M includes/config-variables.inc.php >> M includes/defaults.inc.php >> M includes/definitions.inc.php >> M includes/discovery/functions.inc.php >> M includes/functions.inc.php >> M includes/polling/functions.inc.php >> M poller.php >> M rename_device.php >> [root@desktop root]# svn info | grep ^Revision >> Revision: 9704 >> [root@desktop root]# >> [root@desktop observium]# mv ping_only_hosts.diff >> ping_only_hosts_r9704.diff >> >> -Colin >> >> Email: cstubbs @ gmail . com >> >> _______________________________________________ >> observium mailing listobservium@observium.orghttp://postman.memetic.org/cgi-bin/mailman/listinfo/observium <https://nam01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpostman.me…> >> >> >> -- >> Mike Stupalov >> Observium Limited, http://observium.org >> <https://nam01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fobservium.…> >> >> _______________________________________________ > observium mailing list > observium(a)observium.org > > https://nam01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpostman.me… > >

9 9

Distributed poller
by Luca Sasdelli 07 Mar '19

07 Mar '19

Hi all, does it exist any updated doc about the distributed polling? What about the drop-down "Poller" menu under general device settings? Thanks! Luca

1 0

Ignoring Interfaces in Discovery
by Benjamin Moore 07 Mar '19

07 Mar '19

Can someone tell me how to get Observium to NOT ignore interfaces? I'm assuming that it is ignoring them due to the fact that they don't have ifTypes assigned - ##### Module Start: ports ##### o Caching OIDs ifDescr ifAlias ifName ifType ifOperStatus o Caching DB 0 ports o Discovering ports XX VLAN1(12)XXXXXXXX +---------+-----------+-----------+---------+--------+-------------+---------+ | ifIndex | ifDescr | ifName | ifAlias | ifType | Oper Status | Ignored | +---------+-----------+-----------+---------+--------+-------------+---------+ | 9 | WAN2 | WAN2 | ... | | | yes | | 10 | WAN1 | WAN1 | ... | | | yes | | 12 | VLAN1 | VLAN1 | ... | l2vlan | | no | | 25 | LAN4 | LAN4 | ... | | down | yes | | 26 | LAN3 | LAN3 | ... | | down | yes | | 27 | LAN2 | LAN2 | ... | | down | yes | | 28 | LAN1 | LAN1 | ... | | up | yes | | 29 | WAN_PORT1 | WAN_PORT1 | ... | | up | yes | | 30 | WAN_PORT2 | WAN_PORT2 | ... | | down | yes | | 51 | USB1 | USB1 | ... | usb | | yes | | 52 | USB2 | USB2 | ... | usb | | yes | +---------+-----------+-----------+---------+--------+-------------+---------+ LAN1 and WAN PORT 1 are the two interfaces I need to have monitored.

2 1

Ping-only devices
by Ryan Huff 03 Mar '19

03 Mar '19

I really do understand this, on a deeper level than might be imagined ;). I have no vested interest either way personally, I’m just offering some unsolicited thoughts... I always looked at the “ping only” topic like asking a 10lbs. (4.5kg or 0.7149 stones) sledge hammer to drive a nail. Sure, it can do it but it’ll probably be messy and ugly because a sledge hammer was never meant to drive nails, and when you use tools in ways they weren’t really designed for, things can get messy. Just use a hammer instead. I have done three things to achieve icmp only monitoring and also stick within the base code (as a developer, I hate mucking with base code or re-inventing wheels when I want to do different things). Icmp-only monitoring to me, always just seemed silly (not in purpose) to try and work into an existing and established application that didn’t already do it. It’s just too easy of a problem to solve otherwise, than to go to the time/expense of refactoring an application IMHO. - I use RTT SLAs to monitor next hop devices (which OBS is fabulous at picking up), assuming the device hopped from is SLA capable and OBS monitored. - I use Fping (Smokeping) integrated with OBS. Using the Smokeping web wrapper makes a great RTT only tool, and you also have the OBS integration for when it makes sense to use on OBS devices. - I have a small (very small) bash script that reads a text file of IP address and launches one thread per device to run continuous pings. Not a very scalable script, but like you, I only need it for a very few limited cases. The script uses sendmail to email me if it can’t reach something. Thanks, Ryan

1 0

2nd TRY | Generating alerts with firewall sessions thresholds
by Gordon Cheng (gocheng) 01 Mar '19

01 Mar '19

Hi all, We are looking for a way to generate alerts from Observium (19.1.9661) when exceeding certain number of sessions on a Cisco firewall. Is it something easily achievable? [cid:image001.png@01D4CEE1.B8160000] Thanks. - Gordon

2 3