Joe Skup

  • Content count

  • Joined

  • Last visited

  • Days Won


Everything posted by Joe Skup

  1. Update- I found the solution: Edit agent.conf: 1. collector.xxxx.enable=false on every unused/unneeded datasource collection mechanism. 2. eventcollector.xxxx.enable=false on every unused/unneeded eventsource collection mechanism. 3. sbproxy.pool.connections=25 4. sbproxy.linux.threadPoolSize=60 5. collector.snmp.threadpool=25 6. discover.workers=5 In my case, I pretty much am monitoring the collector machine only, and I've only left snmp, script & webpage-related collectors enabled and this seems to have done the trick. The last few configurations might not be necessary..but everything seems to be working fine with these configs..!
  2. I know that it is not exactly recommended/reliable to use a 1GB/1CPU Core machine to monitor...but it seems that installing a "nano" sized collector on a t2.micro AWS instance and having it just monitor itself brings the AWS instance to a screeching halt. I am seeing that when the collector is running, top shows that CPU pegs to 100% almost nonstop. Memory is not hit quite as bad..but it does get up there to use 500mb+ But the CPU load average is 5+ cores and it makes the system unusable. Sometimes this causes the instance to throw status alerts & even crash. Question: Has anybody been able to tweak the wrapper.conf etc files to make the collector CPU load less demanding?
  3. I've made a custom script datasource that mainly leverages Active Discovery (if any instances are found in the resultset, it alerts) and so I don't need the data collection interval at all--I just use a Datapump collector and alert on true, when instances are detected. My datasource would benefit from additional "Discovery schedule" options that are < 15 minutes. Run AD every 3 minutes, for instance, would be ideal. Currently, the only dropdown selections are: (1) once per day, (2) once per hour, (3) once per 15 minutes, or (4) when the datasource changes. I am using once per every 15 minutes, which is the highest resolution option that is currently available for instance discovery. This work, but because my alerting simply depends on the presence of a resultset in the discovery routine of the datasource, then--at best--I am only "polling" for data/alerts every 15 minutes. Thank you for considering this request. - Joseph
  4. Hi Matt, Thanks for the quick response! I understand that AD wasn't designed for this purpose. But I think as the IT ecosphere and needs evolve, monitoring tools should also follow. ;-) Instance-level properties and PropertySources were a huge improvement in this direction, so thank you for supporting this new feature!! I've thought about reducing my needs to a simple datapoint value. But--in this case--that information is just a little too vague.. Sure, it gets the job done for alerting purposes. But I'd like to be able to know which members show up in the AD resultset, and at the same time also populate some extraneous information about these instances. Ie, the error message that is being displayed for these members..and other information which I am now successfully recording via Instance-level properties. This allows me to export that information as ##alert message tokens## > data placed directly in the JIRA tickets which are created from these alerts using custom HTTP delivery/"integration" webhook. That is working perfectly and it is more useful information for the engineers on my team who are responding to these JIRA tickets, vs a simple value. Thanks for the help but my request still holds! And thanks for considering. - Joseph
  5. A small added feature that would really enhance the usability would be to add broad arrows to the sides of all graphs in the product and provide a seamless "scrolling" through history.
  6. On the Alerts page it sometimes gets hard to scroll left/right with long lists of alerts. Currently the scrollbar is at the bottom of the page and it is static. FR: Please make a persistent horizontal scrollbar that is separated off the main table.
  7. Hi--I see on the Script Active Discovery page that there is a new type of token that can be used for instances in script-based instance discovery called "Second Part Alias". What is this and how exactly is it used? Maybe can you provide an example of how it is being used in the product currently? I am particularly interested in storing more information about instances ("instance custom properties") if possibel..which coukd then be sourced in an alert message/ if it can be used for this purpose in any way that would be ideal. Awesome forum & support site BTW
  8. Great to know that this is on the roadmap!! Still curious about what Second Part Alias is used for--thanks!