J Wiltse

Members
  • Content Count

    9
  • Joined

  • Last visited

  • Days Won

    2

Community Reputation

2 Neutral

About J Wiltse

  • Rank
    Community Member

Recent Profile Visitors

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

  1. FYI, the JAR that exists on the collectors now jt400-full-6.0.jar does work, and has been working. There was a problem with our datasource when I made the previous comment. Thanks again to the logicmonitor team.
  2. We often get requests from our clients that say "Show me everything you're monitoring for me". I think it makes sense as a new standard report type, although i understand it will be extremely difficult for Logicmonitor to create. Nonetheless, Here would be my suggestion for this: In some ways, organized like the UI For each host, a list of all the datasources that apply Option to include the host properties in a table format. For each datasource that applies to the host: Name of Datasource List of instances/instance groups Datapoint List, with Thresholds Somehow show overridden thresholds this is the key, but also the challenge It may simply be too large of a task with too little support, but by posting it here, i hope that many people share this need, so that we can get it accepted for the roadmap.
  3. I support the suggestion, and there is at least one significant difference between host-level properties and putting them on the group. In our case, it's the API. We use the API to manage host properties. When you do a "getHost", there is no way to distinguish between properties that are on the host level, versus inherited from a group. Thus, we work with all properties at the host level, and mange them via an API. Still, when we add a host, we often want to clone one from the cluster, including hidden credential properties, and there's no way to do so.
  4. We currently get emails to our ticket system any time an SDT is created, just like we get alert notifications. Now, we're trying to move off of email-based notification to webhooks based notification (for everything). We'd like lots of different logicmonitor events to be sent as webhooks, not just alerts. For example: Creation of SDT Disablement of Alerts Changing of a Threshold Potentially, anything that occurs in the access log. This is a big request, and would require a lot of additions to the webhooks UI, and the backend. However, it seems like the type of thing that would bring logicmonitor one step further into being fully automate-able for developers and large deployments.
  5. Hi, when we get webhooks, we have to do an API call for each one because the following critical information is lacking in the webhooks: InSDT AckedAckedOnLocalAckedComment Without this information, the "acked" webhook is kind of silly, it doesn't have any of the key information.
  6. Allen, I'm glad you posted this, as we have a related request. I have posted our related request on the previous feature request system as well. I've thought about this in very deep detail over the past 2 years. It's a VERY difficult problem to solve, as there are a lot of "what ifs" and a lot of use cases and preferences. I'll provide a description of the problem from our point of view. The threshold report is the closest approximation, but pretty far from the solution. In theory, it does show all thresholds that exist (not counting eventsources or batch jobs). Also, with it's asterisk representing "All matching items", the report represents the shortest possible report providing the most information. In theory, one could extrapolate that a certain host/ds/instance would be subject to a certain threshold on the report, if one knew the properties of the host. However it's indirect information, and those looking at the reports cannot see which hosts/instances a given threshold would apply to. It also doesn't show what instances were discovered and exist. The other extreme is a CSV of every host, with every Datasource, every instance, every metric, every threshold. We've seen this from other monitoring tools, and it's equally undesirable. There's too much data. My vote would be for a carefully crafted middle-ground, which will take a lot of trial and error. Somehow, the lowest-level items need to be enumerated and the threshold shown (for items with thresholds), but organized in such a way that it's intuitive to navigate. And of course, the other challenge is how to do this in all 3 formats: CSV, Excel, HTML. That's the "problem summary" for a "Monitored Items" report, from our point of view. I'm interested if others are looking for the same type of report. I also wonder if there are any new accommodations for this in the upcoming improvements to reporting .