Paul, Thanks for the quick response. How do we bring up this application without the "init" script. Do we have to compile and run this GO Script -- the main.go and influx.go ??
Regards, ~Ramya. On Wed, Aug 24, 2016 at 3:22 AM, Paul Stuart <[email protected]> wrote: > The init script is for sys v style init (old school), not systemd. It's > not necessary for running the program itself -- it's there to run it as a > service. > > On Tue, Aug 23, 2016 at 2:53 AM, <[email protected]> wrote: > >> Hi Paul, >> >> I would like to use this influxsnmp plugin. But unable to get it up and >> running. Does this have anything to do with the initctl in the influxsnmp >> start scripts ?? I am using CentOS and it uses systemctl for upstart i >> believe. >> >> As I am pretty new to GO, am not sure what is going wrong. Your help >> would be highly appreciated. >> >> Thanks. >> >> >> On Wednesday, 30 September 2015 00:24:14 UTC+5:30, Paul Stuart wrote: >> > Give this a try and let me know if it works for you: >> https://github.com/paulstuart/influxsnmp >> > >> > On Monday, September 28, 2015 at 2:00:30 PM UTC-7, Dan Mahoney wrote: >> > >> > >> > >> > >> > I am brand new to InfluxDB, and I'm trying to put together a monitoring >> system to serve as a failsafe to our commercial monitoring software. The >> monitor system will use small machines as data collectors, polling devices >> for data via SNMP and relaying the data to InfluxDB (we need to use >> multiple collectors, as my network has multiple nodes around the world, >> with partial IP address duplication between data centers). I will be >> grabbing SNMP data from a few hundred devices, and will be pulling multiple >> OIDs (sometimes as many a couple dozen) from each device. >> > >> > My initial thought is to lay out my schema like this: >> > value, >> > collector=<collector>, >> > device=<device IP>, >> > devClass=<device class - DNCC, CDS, etc>, >> > OID=<numeric OID>,i >> > name=<alpha OID name>, >> > tableIndex=<index key if needed>, >> > retCode= <measurement status code>, >> > value=<returned value> <time stamp> >> > >> > devClass would indicate the type of device being referred to (CDS, >> DNCC, util, etc), OID would be the numeric string representation of the >> value ('1.3.6.1.2.1.2.2.1.16'), name would contain the human-readable >> equivalent of the OID ('ifOutOctets'), tableIndex would be blank for simple >> values or a numeric index for a table-type value (like ifTable), and >> retCode would be used to capture exceptional status information that needs >> to be used by the post-colelction data handler. >> > >> > >> > My thought is that with a schema like that I would be able to submit >> queries like "select loadAvg1Min from Master where collector='EU' , >> devClass='SGW'", etc. My question is, would using this number of tags have >> any serious drawbacks? Would querying on multiple tags like that run too >> slowly to be practical? Any other problems you can see with my plan? >> > >> > I plan to stuff a bunch of data into InfluxDB from my current >> monitoring system, just so that I can experiment with how much inserting >> data imposes, how the queries behave, etc. I won't be inserting real data >> for a while yet, as I still have to write my SNMP collector and the data >> post-processor, but if anyone can point out flaws in my schema design I >> might be able to avoid some pain. >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > -- >> > >> > >> > >> > -------------------------- >> > Dan Mahoney >> > [email protected] >> > >> > >> > "How you behave towards cats here below determines your status in >> Heaven." >> > Robert Heinlein >> > >> > "There are two means of refuge from the miseries of >> > life - music and cats" - Albert Schweitzer >> >> -- >> Remember to include the InfluxDB version number with all issue reports >> --- >> You received this message because you are subscribed to a topic in the >> Google Groups "InfluxDB" group. >> To unsubscribe from this topic, visit https://groups.google.com/d/to >> pic/influxdb/wnGWZgF0lSw/unsubscribe. >> To unsubscribe from this group and all its topics, send an email to >> [email protected]. >> To post to this group, send email to [email protected]. >> Visit this group at https://groups.google.com/group/influxdb. >> To view this discussion on the web visit https://groups.google.com/d/ms >> gid/influxdb/c1032566-eea1-4396-90e6-9a0e1b7e958d%40googlegroups.com. >> For more options, visit https://groups.google.com/d/optout. >> > > -- > Remember to include the InfluxDB version number with all issue reports > --- > You received this message because you are subscribed to a topic in the > Google Groups "InfluxDB" group. > To unsubscribe from this topic, visit https://groups.google.com/d/ > topic/influxdb/wnGWZgF0lSw/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > [email protected]. > To post to this group, send email to [email protected]. > Visit this group at https://groups.google.com/group/influxdb. > To view this discussion on the web visit https://groups.google.com/d/ > msgid/influxdb/CAG4S1gjWdgDY3GzhgOnY_hE4V4yCV% > 3D5bA7giJXrA6OieyULRiA%40mail.gmail.com > <https://groups.google.com/d/msgid/influxdb/CAG4S1gjWdgDY3GzhgOnY_hE4V4yCV%3D5bA7giJXrA6OieyULRiA%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- Remember to include the InfluxDB version number with all issue reports --- You received this message because you are subscribed to the Google Groups "InfluxDB" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/influxdb. To view this discussion on the web visit https://groups.google.com/d/msgid/influxdb/CAJac%2BNu6k4VvU6Wjkonvu3btqBmwpzA9zjQ_Tv0A-2Jvmfo3fg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
