Dashboard Sharing – An Inline Framing Method
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: Quote Dashboard Sharing allows you to send a “snapshot view of your Dashboards to colleagues or customers. This is particularly useful for generating a visual report of your infrastructure's overall status at a specific moment in time. Dashboards are shared via email as linked web pages. The recipients of these Dashboards will be given read-only access to the Dashboard. 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 Quote Shared dashboards are available to users based on the permissions configured by their role and should be created for any dashboard that will be viewed by more than one person. 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.82Views0likes4CommentsWidget for ping monitoring
Hi Everyone! I'm trying to figure out how to create a widget, that will show the top ten servers that have a ping of above 100ms. I can make the standard ping widget, but I don't see a way to limit the graph to those servers that have a high ping. Do I need to use the virtual datapoint? Or, maybe I need clarification on what it means when I select top 10 on an average, or maxrtt datapoint. Thanks!57Views1like6CommentsConfigSource that writes outputs to dashboard
A while back I published some very simple ConfigSources to monitor your collector .conf files: a href="https://communities.logicmonitor.com/topic/1345-collector-configsources/" rel="">https://communities.logicmonitor.com/topic/1345-collector-configsources/ Here's an adaptation that writes the various collected configs to a dashboard, writing each of the config outputs to a text widget. Notes: THIS IS A PROOF OF CONCEPT. No warranty is given or implied (value of your investments may go down as well as up, check with your health professional before taking this medicine, etc). Please test before deploying! As with all data within LogicMonitor (or any system), be aware of access rights of users - in this case to whatever Dashboard(s) the config data will be presented on. Be sure to configure your Roles and Users such that only users who have legitimate need to see this data can access whatever Dashboard(s) you send it to. This uses the REST API v1 to verify the target dashboard exists or create it if it doesn't, and also to create / update the text widgets. It will therefore need an API token for an account with management permission for the relevant Dashboard(s), with ID and Key values set as device properties apiaccessid.key and apiaccesskey.key. All of the API interaction is contained with a groovy checkpoint, rather than within the config collection script, so this could very simply be copied into other ConfigSources. The same logic could be used in other LogicModules, such as to write non-numeric outputs of SQL queries or any data collection methods to dashboards. While this provides no history retention as written, it will show current / most recent values. Within the script you can define the desired Dashboard path, e.g. 'Collector Configs/Groovy Check' (default as presented here), Dashboard name (hostDisplayName is the default), widget name format (hostDisplayName: wildvalue) and other initial parameters such as widget colour scheme, description, etc. This is written for REST API v1. One day I may get around to updating it for v2, for greater efficiency, but today is not that day. Tomorrow is not looking likely either. Dashboard text widgets do have a maximum character limit (65,535 characters). I don't think I've seen a collector config near to or in excess of this, so I have no idea whether a larger config from another device would be truncated or whether the widget creation would fail. Other widgets on the dashboard are unaffected by this script creating and updating widgets; likewise later manual changes to widget size, colours, etc should be respected; updates should be to the text content of the widgets only, so the target dashboard could contain other data from the device. For example, it might look a bit like this: Known issues: On the first config collection for a multi-instance ConfigSource like this, and where the target dashboard does not already exist, only one widget will be created in the dashboard. This is because all instances collect more or less simultaneously, and each determines the dashboard is not initially present. Each, therefore, attempts to create the dashboard and as soon as the first instance does so, the others will fail as they cannot create a dashboard that (now) already exists. This could be coded around with a simple delay / re-check on failure, but I haven't had time, and the second config collection will create all expected widgets without issue. Additionally, if you create the dashboard first, this issue will not occur.21Views0likes4CommentsDashboard Widget for Reports
File this in the "nice to have" bucket. I would like to keep my dashboard-only customers in front of LM as much as possible. Today, Reports can be viewed from running the report inside the Reports tab, or scheduled/emailed out. How about adding a widget that could access a selected report, formatted for HTML. This provides a single place to review most recent, and past report-runs without leaving the dashboard, and allows users to correlate Report output with other information shown on the dashboard. Today we can use the URL from an HTML Report, and stuff it into the HTML Widget. Managing this manually is difficult since new runs of the report will have a unique URL, so the HTML widget would then need to be updated with the current HTML Report URL. I tried to do this myself using LM RPC/REST but cannot find any API calls to access the Reports. Thoughts?21Views1like2CommentsSLA Widget
I believe that we have found a bug, right now if more than one service monitor is set under the SLA Monitor Widget the results seems to be the average. example; graph 1 = 100 % uptime graph 2 = 50% uptime Combined SLA widget(graph 1 and 2) = LogicMonitor is returning 75% where I would expect to it return the lowest uptime percentage which would be 50%.17Views0likes0CommentsMake Instance Groups searchable/filterable
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, Bastian16Views3likes2CommentsDashboard graph widgets - aggregate by instance name / device group name
We have several clustered devices where metrics are gathered on each node. However, the instances across each node are identical. When attempting to graph this data, this means that I would need to add a new datapoint for each instance and use a glob pattern to select the devices from which to pull those instances. This can mean that a lot of time goes into creating these graphs if there are several instances to monitor. Examples: Three Solr nodes - each servicing search requests for the same 10 collections. In order to see the total number of GET requests for each of those collections, I would need to create a graph that has 10 individual datapoints. Instead, I would like to add one datapoint and have the graph intelligently aggregate all instances that have the same name, regardless of the node. Several device groups exist under a parent group. If I want to see the average CPU utilization across each of these groups on a single graph, I would need to add a separate datapoint for each group. A potential solution could be to allow the integration of regex instead of glob patterns to allow for capture groups. Otherwise a simple checkbox for "aggregate instances by device group" and "aggregate instances by instance names" when selecting aggregated graph types would be extremely useful and time-saving.15Views0likes0CommentsMaximum Number of Dashboards in Slideshow
Hello all, This is my first time posting a question in the forums. I wanted to know if there is a limit to the number of Dashboards that can be added to a Slideshow dashboard rotation? I work in my company's NOC (network operations center) and have somewhere in the neighborhood of 70 dashboards that my group needs to keep track of. It seems the number of dashboards I can add before a previously added dashboard is removed is 26. Does anyone know if this is a hard limit or is this a setting that our LM administrators can adjust? Looking forward to responses, Steve V.15Views1like1CommentTime 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 , 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.14Views0likes0Comments