Thats the plan, we are moving all critical monitoring to librenms, better anyway cause we can keep long term without impacting powercodes db size. It just is a pita to decide what to leave for tier 1 support to be able to see in powercode since librenms is a little less user friendly
On Thu, Dec 12, 2019 at 6:05 PM Matt Hoppes < mattli...@rivervalleyinternet.net> wrote: > May I suggest using Powercode to ping your devices and use something like > librenms to graph them? > > Either that or you may need a more powerful machine to keep up. My guess > is the RRD files may have looped and got corrupted. > > On Dec 12, 2019, at 6:58 PM, Steve Jones <thatoneguyst...@gmail.com> > wrote: > > I had thought I identified which probes werent working, but its not > limited to single OIDs, its across the board and random, thus far they > haven been able to provide any functional probe report. > > One of the probe issues we found is that editing a device and changing its > type, thus changing its probes, leaves the internal probe index name the > same as the old probe (caused a major issue when we had a bunch of alvarion > alerts when we dont have it anymore). worse yet is alot of the probes did > work, but now dont. TBH, powercode should just do like theyre doing with > bandwidth management/accounting and hand it off to a third party. basically > make powercode an API skeleton/aggregator into systems that actually > function reliably and make the core of powercode a glorified quickbooks > instance/schedule management system > I think the database is corrupt, but they apparently have no integrity > checks. Im to the point that ive asked them about wiping the entirety of > the probes and the rrd data as they have had to do twice in the past. this > is a major pain, losing all that historic data, but considering without > checking every single device, we dont know whats even probing and what is > not and its random. Not to mention it would be nice to know the probe > alerts will present with the actual probe names again. > Way back in the day when the probing would fail over a bad OID there was a > log i could check, but apparently thats not how it logs now. Powercode has > always had an abysmally fragile probe system. > If anybody can point me to logs, id be more than grateful. > > The API authentication was just the last thing with their mikrotik > integration. They have garbage documentation, their support refuses to > provide instruction sets, points you to outside consultants, which i find > it odd that a consultant would have access to powercode documentation that > neither powercode, nor powercodes paying customers have access to, maybe > its some contract, though linktechs is unaware of it, maybe theres a secret > handshake i need to know. I find it absolutely ignorant that every time i > update an ip range, powercode will delete the gateway from the mikrotik and > ill have to go add it again. I literally can think of zero valid reason for > it to do that. For whatever reason DHCP doesnt work, installed on the > mikrotik, or using the powercode interface to set up a relay, yet when i > configure a straight relay it works just fine. I have no major issue witht > hat as id rather manage the relay myself so powercode doesnt randomly > delete that too. > I dont like that it set up a queue on the test router for my bosses > personal account though i had exactly zero equipment added to the BMU and > at the time, no ip ranges defined. > > Powercode has always ebbed and flowed, but right now its deplorable, being > forced back to the third party router BMU is fine, i liked the imagestreams > they made us deploy, then forced us to buy their BMUs. But at least in the > imagestream days they actually supported their requirements. Theres the > sesai or whatever flavor third party junk theyre pimping this week, just > like all the others they pimped then dropped, so im not all that interested > in going that route. Im still holding a grudge that on the morning of my > wedding I woke to powercode randomly deciding to have massive phantom usage > spikes (again) . Id recomend to the bosses migrating to another system, but > the grass is never greener, if we move away, wed be better served to pay > somebody to build us a proper solution, it would be cheaper than sasai or > whetever is the flavor of the month with powercode. Or go to any of the > free open source solutions out there since we are being forced to spin up > all kinds of other servers anyway to mitigate their shortcomings. Powercode > is still better than a bunch of spreadsheets though. > > that turned into more of a rant than anticipated, seeing my credentials in > plain text just set me off, glad we arent hosted > > On Thu, Dec 12, 2019 at 5:15 PM Josh Luthman <j...@imaginenetworksllc.com> > wrote: > >> Your complaint seems to be probes and the Mikrotik API authentication. >> If you have broken probes, it's your setup as they're working for me and >> many others. What exactly isn't working? What OIDs? The only caveat I'd >> say is that if one OID is broken in the query, they start responding poorly >> - it's done this way for scaling and irrelevant if you've got it set up >> right. >> >> Not sure about the API auth but I do agree it should be secured. >> >> Josh Luthman >> Office: 937-552-2340 >> Direct: 937-552-2343 >> 1100 Wayne St >> Suite 1337 >> Troy, OH 45373 >> >> >> On Thu, Dec 12, 2019 at 4:35 PM Steve Jones <thatoneguyst...@gmail.com> >> wrote: >> >>> Powercode has become quite a joke. Half our probes havent worked for >>> months and they dont even respond to the ticket. We had to spin up Librenms >>> just to get monitoring data >>> >>> Trying to integrate mikrotik BMUs and having issues, they have zero >>> legitimate documentation and when you ask whats supposed to be >>> happening they tell you to seek out a consultant and that the info may be >>> proprietary. >>> >>> Thats all bad enough, but i figure ill do some packet sniffing to find >>> out what the communication is between the billing server and the mikrotik, >>> maybe find out I misconfigured something, come to find out the nitwits are >>> sending out the authentication in PLAIN TEXT. They dont even have a >>> disclaimer when you add one of these. but christ, if youre operating an off >>> network BMU, your infrastructure credentials are getting tossed into the >>> ether like its nothing. >>> >>> I wish simon hadnt left >>> -- >>> AF mailing list >>> AF@af.afmug.com >>> http://af.afmug.com/mailman/listinfo/af_af.afmug.com >>> >> -- >> AF mailing list >> AF@af.afmug.com >> http://af.afmug.com/mailman/listinfo/af_af.afmug.com >> > -- > AF mailing list > AF@af.afmug.com > http://af.afmug.com/mailman/listinfo/af_af.afmug.com > > -- > AF mailing list > AF@af.afmug.com > http://af.afmug.com/mailman/listinfo/af_af.afmug.com >
-- AF mailing list AF@af.afmug.com http://af.afmug.com/mailman/listinfo/af_af.afmug.com
