Joe Skup

  • Content Count

  • Joined

  • Last visited

  • Days Won


Community Reputation

4 Neutral

About Joe Skup

  • Rank

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  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 n
  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 a
  3. 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
  4. 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 onc
  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. Great to know that this is on the roadmap!! Still curious about what Second Part Alias is used for--thanks!
  8. 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