• Content Count

  • Joined

  • Last visited

Posts posted by CBU BA DUDE

  1. If this hasn't been noticed, can I move it to a forum that is meant to bring attention to problems with your system?  Aside from this being in the "Feature Requests" forum - it's more of a FIX since your exports of tabular data are incorrectly formatted.

    CSV is for table data, not white-space.  Maybe try outputting your content with white-space into a PDF and keep your CSV/XLSX exports tabular?

  2. The website overview report does not allow for column selections so website downtime exports don't contain fields for monitor object properties/custom properties.

    To enable more robust reporting, those additional fields (properties) are needed to visual data into appropriate segments.  Our executive team needs to be briefed on application level availability (web services) with breakdown of the data by client, product, business service, environment, supplier etc.  The monitor properties and custom fields we store in the services table provide the detail and should be made available for reporting.

  3. The SLA report does not have an option to include information about SDT if the event is in the past.  Since reports are often developed to look at sla information post-event it's imperative that report columns be added that reflect historical SDT info as well.

    I recommend not just including the sdted field to indicate whether or not the alert began in a SDT window, but to instead add a new field/column for % in SDT or SDT Duration that provides an indicator as to how much of that alert's period was happening in a SDT window.


    Planned maintenance window is 2-4.  IT change initiated at 2:30 and services are brought down.  Alert generates and flags true for insdt and sdted (i think).

    If the change goes bad and services are still down at 4 AM the insdt flag is set to false (i think).  The change implementer restores service at 4:30 and the alert clears.  To report on downtime for that alert correctly we would need to know what portion of that downtime occurred within or outside of SDT.

    If we assumed that since the alert was generated in an SDT window (sdted=true) the entire duration was planned then we are incorrect an SLA report on downtime for that instance check would be false.

  4. Most often, when people export to a csv or excel format their intent is to receive table data in a tabular format because they're going to pivot it out, chart it, or conduct some sort of analytics/BI function.

    It would be nice if your csv exports didn't require manipulation of the data to remove erroneous data/whitespace for consumability as a table datasource.  This is specifically a problem in Website Overview reports.

    • Upvote 2
  5. For context, I'm a consumer of LogicMonitor csv/excel report exports only - I am required to aggregate my exports outside of LogicMonitor so I can use the availability data from our website endpoint checks to build Tableau Reports.

    Thus, it would be incredibly helpful to my organization if I could obtain an export (csv/excel) from LogicMonitor that contained all webservices downtime (NOT aggregated and reported as ##h ##m ##s) with datetimes for each period of missed polls (downtime).

    For example, each line in the spreadsheet contain the endpoint details and the start/stop time.  For periods of flapping, each there would be multiple lines for the same endpoint, each with their own start and end times.

    Knowing when downtime is occurring AND knowing if it occurred during a scheduled maintenance period are essential pieces of information necessary to advance availability reporting for our cloud applications and ensure we maintain our SLA (which discounts application downtime for planned maintenance).  I draw out my data daily, via a website overview report that excludes SDT from the reported downtime in a csv export.

  6. When investigating an event it would be nice to export a monitor's raw data, graph, alerts, even properties, etc. straight from the monitor's page without having to load the reporting user interface.

    Please look into adding a csv/excel/pdf, etc. export of the data displayed on the associated tab (raw data, graphs, alerts, info).  You already have all the information needed to compile the export with a single click.  If additional filters are needed to narrow a data-set then I'm sure those can be brought on-screen where the other filters are placed up in the header.


    • Upvote 1