Search the Community

Showing results for tags 'Dashboards'.



More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • LogicModule Exchange
    • LM Exchange
    • LM Staff Contributions
  • Product Announcements
    • LogicMonitor Notices
  • LogicMonitor Product Q&A
    • Feature Requests
    • Ask the Community
    • From the Front

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


Found 8 results

  1. We have a use case to show "Response Times" from a subset of configured Websites. Ideally I'd like this to be in the Big Number widget. We also want to able to chart a subset of my Websites' response times over time in the Chart widget. Anyone found a useful workaround to achieve this? Would LM consider "upgrading" widgets to allow the presentation of Website data? Currently only the SLA widget seems capable of handling Website data.
  2. Often times we receive LM Administrators and Users requesting for a method to share dashboards with a target internal or external audience. ‘Share’ in the LM Vocabulary may take on two meanings: I. Sharing Dashboards II. For the sake of article – Dashboard Shares These terms might not be as conspicuous to the actual objective. For clarity – let us briefly describe each key-functionality: I. Sharing Dashboards This is explained in our article: https://www.logicmonitor.com/support/dashboards-and-widgets/managing-dashboards/sharing-dashboards/ An example - Sharing a Static 'System Uptime' Dashboard Key components of this function - Snapshot view, Reports To further explain, it is much alike to the Reports Generation Feature, and literally a static snapshot view of the Dashboard. So we’ve been getting users on our email and chat channels asking for a more interactive Dashboard view, and while our support page briefly mentions this here: II. Shared Dashboards https://www.logicmonitor.com/support/dashboards-and-widgets/managing-dashboards/how-are-dashboards-created/ Therefore the key components are; live Dashboards, interactive, require the setup of role-based access credentials to log in. A further discourse on this method, this requires a User to be setup with Role Adjustments accordingly set for the target user/audience. This requires a credential or a login to the portal. A scenario would be for MSPs - You may set this to a read-only user for a target customer who may not require management or modification level settings. think . e.g( Extranet, or DMZ). This, however, requires the User/Customer to still access the LM Portal, and, login to be able to view the Dashboards. Furthermore, this might be an impediment if you’d like to set the Dashboard on a Display/ Monitor Screen where you might not be able to enter the User Credentials at any time / at all. An extension or workaround to this is in the utilization of inline frames (iframes); it is briefly discussed on this page: https://www.logicmonitor.com/support/dashboards-and-widgets/overview/what-are-dashboards/ This post would further explain, and demonstrate this method for the benefit of our Users and their corresponding internal/ external audience. Steps: 1) Role Based Setup: Firstly we'll need to create a 'View-Only' Role/User on this setup. In this case - we'll be creating a role that has a 'View' only access to the Dashboard - in our example- the 'Tutorial' Dashboard. Subsequently, we'll likewise need to create a User and assign on this ‘view-only’ role View permissions for Dashboards. See example below: Note that the email provided should be one where the external customer does not have access. 2) The inline iframe setup method. 2a) Declare the credentials on the embedded URL - https://portalname.logicmonitor.com/santaba/uiv3/dashboard/index.jsp?c=portalname&u=XXX&p=YYY#dashboard=14 where: c=company(portalname) u=username (in our case XXX) p=password (in our case YYY) dashboard= dashboard ID number ( in our example id =14) - see below screenshot to determine the Dashboard ID 2b) Paste that URL into a browser to interpret the URL. 2c) User would have a live display of the Dashboard, and can toggle the time-range, but with no rights/ability to edit the configuration, ( and, doesn’t require a login!). N.B. Note that Device or Alert specific data will appear if the user is given permissions to view on that particular Device Group. i.e. if User has permissions to view Device Group A, the Dashboard will only display with Data specific to Device Group A.
  3. One of the biggest frustrations for us with LogicMonitor is breaking a bunch of dashboards and alerts if we move device groups to another location in the overall device group tree. For example: Say we have a nested device group called "Infrastructure/Hosts". Now our environment has changed a bit, and we want to add better organization to support the new changes to our environment. We move the hosts group to the following location "Infrastructure/PhysicalDevices/Hosts". All alert rules and dashboards that were filtering on "Infrastructure/Hosts" have now been broken, even though the devices in the group need the same alerting and dashboards. Now we have to go through and fix each Alert Rule and Dashboard Widget that used "Infrastructure/Hosts" to now point to "Infrastructure/PhysicalDevices/Hosts". As you can imagine, as environments scale up and evolve, subgroups are going to be moved around all the time. Redoing dashboards and alerts every time this happens adds a tremendous amount of labor, and can lead to people missing changes, leaving behind broken alerts or dashboards that you may not find out about until an emergency has already happened. What we're proposing: "Sticky" device group handling - If a group or subgroup used in an Alert Rule or Dashboard changes location, this location should automatically be updated and reflected in the dashboard. This is how most modern applications handle this sort of thing anyway, and it's a huge time saver. Given the critical nature of this tool's function, this would go along way towards preventing accidentally breaking monitoring that companies rely on to keep their environments running.
  4. Mosh

    Dashboard Sharing

    Please make the blue bar with the PRINT link an optional item to display. We often temporarily share dashboards for management to use in presentations and the blue "PRINT" bar takes up screen real-estate. I'd to have a checkbox that I can tick to hide the print option and blue bar in the dashboard sharing dialog.
  5. Hello, We'd like to request some more usage for instance groups. Right now, it's just not very useful to group instances on a datasource. We have shared devices with datasources belonging to different teams and we have to create dashboards and alarm rules regarding those. Right now, we have to use the wildcard filter in a "creative" way to have shared device alerts and dashboards from different teams configured. It would be really helpful if the instance-group name could be used in Filters. Use-Case: * To configure alert rules for shared devices for different teams, we can group all datasource-instances in instance groups named "teamname" and then filter on "teamname", this works even when we use "*" for device/devicegroup, as long as instancegroup "teamname" is persistent over multiple shared devices. * To have dashboards for shared devices on a per-team base, we can filter for the teamname when creating those dashboards. This also works with "*" as device/devicegroup query, so instances on new devices will be added automatically. Regards, Bastian
  6. It would be great if graphs could auto-scale using a logarithmic function so as to display data that tends to have wide variances. Currently, if one instance has an extremely high value, all other instances in the graph appear at the very bottom. A checkbox on the custom graph page should allow the graph to scale appropriately so as to keep that data visible.
  7. Haniz

    Time after (Up)time

    Time after (Up)time It’s one of the days that an unsung hero gets his chance to make a mark on the world.And who might this be? The floor function [x], also called the greatest integer function or integer value (Spanier and Oldham, 1987), gives the largest integer less than or equal to x. The floor function is not-normally implemented in the LM perspective – often brushed off, but it got its day when we had a user on chat who was looking on creating a dashboard which has server uptime in days instead of seconds. And so I tried devising a Big Number Widget that would include a virtual datapoint in it with the following calculation to display seconds into days: Fig1. Initial UptimeDays setup without the floor() function. UptimeSeconds/60/60/24 Where UptimeSeconds references a pre-calculated Complex Datapoint from the WinSystemUptime Datasource. Alas – this was not presenting days in a helpful manner. It was displaying days with a decimal point. Quoting from the chat : “that uptime display widget you created would be grand if it showed the days. it says 0,4 at the minute, does that meant 0.4 days?” And so we needed to figure on another method. A colleague of ours, a wizard from the magical realm of complex datapoints pointed out to us something powerful, that could display seconds, minutes and days even – And, with this, the second hand unwinds... By using the floor() function appended to the original expression – we could actually calculate: The day rounded to the nearest lowest integer. floor(UptimeSeconds/ 60/ 60 /24) For example if we had the result of 2.4 days from the UptimeSeconds/6000/60/24 calculation – it will present us the result as 2 – to the smallest following integer. Fig2. Complex Datapoints for Days, Hours and Minutes with the floor function And on the Hours Datapoint: floor((UptimeSeconds-(days*86400))/3600) Where 86400 represents the number of seconds in a day – 60 * 60 *24 = 86400. and 3600 represents the number of seconds in an hour - 60 * 60 =3600. This calculates the number of total hours (excluding the amount already converted and apportioned into the Days metric) , and again the floor function rounds the number hours to the smallest following integer. For example - 2.4 days - 0.4 is then carried over to the hours, which equates to 9.6 hours, and with the application of the floor function it will reflect 9 hours, with the balance of 0.6 hours to be calculated on the Minutes Datapoint. And lastly on the Minutes Datapoint: floor((UptimeSeconds-(days*86400)-(hours*3600))/60) Where 86400 represents the number of seconds in a day – 60 *60 *24 = 86400. and 3600 represents the number of seconds in an hour - 60 * 60 =3600. and 60 represents the number of seconds in a minute. This does the same again, number of total minutes excluding those previously factored in the days (*24) and and the hours (*60), rounded to the smallest following integer. And therefore, the floor() function has been very useful in this case to catch the Days, Hours and Minutes, have them precisely presented on the Big Number Widget - which the team could display on the dashboard to wait on -- Time after Time. Fig 3. Uptime Days,Hours and Minutes on the Big Number Widget References: https://www.logicmonitor.com/support/datasources/creating-managing-datasources/datapoint-expressions/ http://mathworld.wolfram.com/FloorFunction.html Credits to David Lee for pointing out on the powerful capabilities of the floor function.
  8. nrichards

    Nested/Cascading Dashboards

    I've been looking at how best to represent the status of a service / application using Dashboards within LogicMonitor. It would be really useful if we could nest/cascade dashboards, so that you could represent items at a very high-level (e.g. overall status of your datacentre infrastructure) and then be able to drill down through underlying dashboards, etc. I've found that a similar functionality request was submitted some time ago by another member, but that was back in 2014.