I configured observium to use the http-auth method combined with our web sso system. I believe it is OpenAM, but I’m a consumer of the service and not someone who maintains it.
I’m mentioning this because the docs state there are no known users of http-auth. It works well, and required no configuration on my part. I just have to create users for each person that match their campus NetIDs.
This is incredibly useful.
Anyone else getting a jpgraph error 25008 when trying to view Accurate
Graphs in Traffic Accounting? I don't frequent this area very often and
just noticed it today.
Regards,
SG
hello,
I want to setup alerts inside of observium to notify us if any links go
down basically. Nothing fancy but just link connectivity/ping tests maybe.
Is the alerting feature only available on the paid version?
Thanks,
Darian
I have deleted a router that we no longer have in Observium, it is now back and replicates multiple times throughout the week, how can I keep this from happening, I have used both command line and web interface to delete.
Thanks
Mike
Got something very odd going on...after testing Observium, I purchased it and installed it onto a clean Ubuntu VM. Everything went fine, I added devices, cron job, etc and started to get some graphs. But yesterday and todays graphs are all blank. When I drill-down to a specific interface and click on real-time, I get these odd spikes where it shows 31Mbps In (which is high for this port). I did a side-by-side comparison to the test VM I setup with the free version of Observium and the real-time is working correctly there.
[cid:image001.jpg@01CFB7C1.2D1F4970]
__________________________________________
Anthony Polselli, Chief Technology Officer
Natural Networks, Inc.
10225 Barnes Canyon Rd. Suite A105
San Diego, CA 92121
anthony(a)naturalnetworks.com<mailto:anthony@naturalnetworks.com>
http://www.naturalnetworks.com<http://www.naturalnetworks.com/>
(619) 222-3232 office
(858) 202-0301 fax
Hi,
I've got one problem with logs from cisco catalyst switches.
On switches logs looks fine but in observium i have something like that "%
:"
Other vendors looks fine in logs. Where could be the problem?
Tomasz Karczewski
Administrator Sieci
tkarczewski(a)man.olsztyn.pl
http://www.man.olsztyn.plhttp://www.uwm.edu.pl
tel. (89) 523 45 55 fax. (89) 523 43 47
Ośrodek Eksploatacji i Zarządzania
Miejską Siecią Komputerową OLMAN w Olsztynie
Uniwersytet Warmińsko-Mazurski w Olsztynie
Hi Guys,
Our observium (latest) 0.14.8.5749 has for some time been showing
devices up and down in the event log, graphs missing chucks of
information as well.
As an example, here is the memory usage on one ubnt box, but, its the
same for others too (network / memory )
http://gyazo.com/18db347a5d49e557c082f343b8e96ea5
Here is the copy of the event log for the device :
http://gyazo.com/4324c896e6cc268a8869d17c80964340
I can't seem to narrow it down.
The machine is running Ubuntu 12.04.5 LTS and as mentioned above,
latest Observium.
Any ideas where to poke ? Its not a single device, its multiple
devices. The only thing so far I have not swapped out is the server
observium sits on.
--
Kind regards,
Chris
Hi,
Just noticed that the CBQoS stuff has gone active recently (which is very cool) - currently we get all this via (very) painful integration with Cacti.
On looking closer I've found what I think is an issue, but stand ready to be corrected. What I think is happening is that Observium is considering packets the Cisco counted as "Exceeded" to have been "Dropped" where in reality they were just re-marked and transmitted normally.
As an example, here is the graph for gi3/1 (class-default) on a 6500 chassis:
Here is the output of the show policy-map int gi3/1:
GigabitEthernet3/1
Service-policy input: <name>
class-map: <Class A> (match-any)
Match: protocol arp
Match: access-group name <ACL A1>
Match: access-group name <ACL A2>
police :
32000 bps 102400 limit 102400 extended limit
Earl in slot 3 :
1377162657 bytes
5 minute offered rate 2280 bps
aggregate-forwarded 1377162657 bytes action: transmit
exceeded 0 bytes action: drop <- Zero drops
aggregate-forward 2520 bps exceed 0 bps
class-map: class-default (match-any)
Match: any
police :
40000000 bps 3200000 limit 3200000 extended limit 1000000000 pir-bps
Earl in slot 3 :
10562039041987 bytes
5 minute offered rate 11748848 bps
aggregate-forwarded 10562039041987 bytes action: set-dscp-transmit
exceeded 297846881624 bytes action: policed-dscp-transmit
violated 0 bytes action: drop <- Zero drops
aggregate-forward 13842064 bps exceed 0 bps violate 0 bps
So in summary, there have never been any actual drops on the port, only re-marking of the DSCP (incrementing the exceeded counter) and then a transmit.
Since the re-marking occurs in the "exceeded" counter, I think Observium is considering them as dropped, instead of just exceeded. This also messes up the pre-policy and post-policy counters, because it implies that traffic didn't make it through when in reality it all did. We use re-marking extensively and so all of the CBQoS graphs show incorrect drop and post-policy information.
Either that or we've got a bug/misconfiguration (or I just don't get it), so maybe someone else can confirm? Let me know what debug info is needed if it helps :)
Cheers!
Robert Williams
Custodian Data Centre
Email: Robert(a)CustodianDC.com
http://www.CustodianDC.com
Hi Observium team,
Earlier this week the global route table hit 512k prefixes, so I was looking in Observium how many prefixes each peer announces.
But there is something wrong that I can't explain and it could be a bug.
This morning I upgraded to the latest (paid) version r5747, that didn't change this.
For peer 195.69.144.192 my Juniper router shows 89 received prefixes:
rtr1> show bgp neighbor 195.69.144.192 | match prefixes
Active prefixes: 47
Received prefixes: 89
Accepted prefixes: 89
Advertised prefixes: 7
Via snmp on the router:
This peer has index 155, and Peer with index 155 has 89 prefixes:
rtr1> show snmp mib wal decimal 1.3.6.1.4.1.2636.5.1.1.2.1.1 | match 144.192 | match PeerIndex
jnxBgpM2PeerIndex.0.1.195.69.144.49.1.195.69.144.192 = 155
rtr1> show snmp mib wal decimal 1.3.6.1.4.1.2636.5.1.1.2.6.2 | match \.155\. | match Prefixes
jnxBgpM2PrefixInPrefixes.155.1.1 = 89
jnxBgpM2PrefixInPrefixesAccepted.155.1.1 = 89
jnxBgpM2PrefixInPrefixesRejected.155.1.1 = 42
jnxBgpM2PrefixOutPrefixes.155.1.1 = 7
Via snmp on the Observium server:
snmpwalk -v3 -l authPriv -u ***** -a SHA -A ****** -x AES -X ******* rtr1 1.3.6.1.4.1.2636.5.1.1.2.6.2 | grep \.155\.
iso.3.6.1.4.1.2636.5.1.1.2.6.2.1.7.155.1.1 = Gauge32: 89
iso.3.6.1.4.1.2636.5.1.1.2.6.2.1.8.155.1.1 = Gauge32: 89
iso.3.6.1.4.1.2636.5.1.1.2.6.2.1.9.155.1.1 = Gauge32: 42
iso.3.6.1.4.1.2636.5.1.1.2.6.2.1.10.155.1.1 = Gauge32: 7
But the graphs looks like this, with only 8 prefixes:
[cid:image001.png@01CFB7A9.99364360]
And even worse for our transit provider:
rtr1> show bgp neighbor 195.69.144.34 | match prefixes
Active prefixes: 158327
Received prefixes: 505071
Accepted prefixes: 505070
Advertised prefixes: 7
snmpwalk -v3 -l authPriv -u ***** -a SHA -A ***** -x AES -X ****** rtr1 1.3.6.1.4.1.2636.5.1.1.2.6.2.1 | grep '\.4\.1\.1'
iso.3.6.1.4.1.2636.5.1.1.2.6.2.1.7.4.1.1 = Gauge32: 505068
iso.3.6.1.4.1.2636.5.1.1.2.6.2.1.8.4.1.1 = Gauge32: 505066
iso.3.6.1.4.1.2636.5.1.1.2.6.2.1.9.4.1.1 = Gauge32: 346727
iso.3.6.1.4.1.2636.5.1.1.2.6.2.1.10.4.1.1 = Gauge32: 7
[cid:image002.png@01CFB7AC.69D3A650]
This behavior seems to have changed around March 1st.
Any thoughts?
Met vriendelijke groet, kind regards,
Erwin Heringa
SIDN | Meander 501 | 6825 MD | Postbus 5022 | 6802 EA | ARNHEM
T +31 (0)26 352 55 59 | F +31 (0)26 352 55 05
erwin.heringa(a)sidn.nl | www.sidn.nl
