Contents
Tips and Tricks
under development
Using “Run-as-Owner” Reports for Dashboards and Dashboard Panels
We have found that there is a common need for a dashboard to provide information about a topic/domain where the target audience does not and should not have access to the underlying data (index). In this situation, a dashboard needs to be able to deliver analytics (tables, visualizations, etc.) to a user, through the access granted some other account. One way to achieve this is what we refer to as the “Run as Owner” approach.
Background
Dashboards are designed for interactive user experiences; it makes sense that they are, by default, “Run as User” interfaces. I.e., unless intentionally developed otherwise, the permissions of the logged-in user will be used when executing the queries of the dashboard against the underlying data (Splunk indexes).
In contrast, Reports (or “Saved Searches”), can be configured with the click of a button to “run as” either the user or some other specified account (Splunk refers to this other account, the “Owner”). I.e., when configured to “Run as Owner”, a Report can be accessed by a user and the Report will “Run as” some other account specified by the person who developed the Report, presumably an account with the necessary privileges needed to “run” the search.
Unfortunately, there is no easy “button” to configure a dashboard to “Run as Owner”. Splunk offers a path to this, however, by supporting the use of Reports (configured to “Run as Owner”) to drive dashboard queries.
Guidance
The guidance below is intended to help dashboard developers implement a full “Run as Owner” dashboard … while optimizing for flexibility (i.e., the ability to use dashboard “inputs” with data derived from Reports and for controlling whose permissions are used to perform the searches), performance (of speed of dashboard interface), and efficiency (of storage and compute resources).
First: Adding a Report to a dashboard and/or converting a dashboard panel to a Report.
Splunk makes it very easy to add a Report (or even an unsaved search) to a dashboard as a dashboard panel or to convert an existing dashboard panel to a Report. You don’t need to get in to the dashboard XML at all. And the results (in the dashboard XML) are the same and quite straightforward.
- Add saved reports to a dashboard (good for when you’re in the dashboard wanting to add the Report)
- If you’re already viewing a Report, you can also easily add it to a dashboard with the “Add to Dashboard” button in upper right. In the subsequent screen, be sure to select “Report” in the “Panel Powered By” field.
- Convert a dashboard panel inline search to a report
The resultant XML from each of the above is something like the following. Note: The “ref” value is the name of the saved Report.
<search ref="List of Unique Users -7d"></search>
Second: Run-as-Owner AND Dashboard Filters
While converting Reports to a dashboard is a good first step for understanding – multiple dashboard panels in a dashboard each running fully separate queries (Reports) each time someone opens the dashboard is not only undesirable from a performance or “compute efficiency” perspective, it simply is not possible (as of this writing) if you want both a) results to be derived from “Run as Owner” reports and b) to use dashboard filters.
The real “trick” here, is to leverage what Splunk calls “Base searches” along with their counterpart “post-process searches”. Those are somewhat complex-sounding terms, but they’re actually a very simple “pair”. A base search is a search that is given an “id” so that it can be referenced elsewhere in the dashboard. A search elsewhere in the dashboard the references the base search can take the results and further process (post-process) them.
A quick example to demonstrate:
Here’s a base search – these can go anywhere and any search can be labeled as a base search with “id”, but for dashboard-wide (or “Global”) base searches, it’s recommended base searches go inside the top element in the hierarchy, the “<dashboard>” or “<form>” element.
<form>
<search id="scheduledBaseSearch_ref" ref="eText Dashboard Base Search -18m@m - Scheduled"></search>
[...]
</form>
Here’s a dashboard panel with a post-process search that references the above base search:
[...]
<panel>
<table> <title>Number of unique student logins per day</title> <search base="scheduledBaseSearch_ref"> <query>| search personID=$personID$ | timechart span=1d dc(personID) AS "Student Logins"</query> </search> </table>
</panel>
[...]
As of this writing, base searches (both identifying them and referencing them) can’t be implemented from the dashboard “UI” edit interface – it must be done from the “Source” (XML) edit interface.
There are a few things important about a base search:
- It runs once, and those results can be tapped in panels (and data inputs) throughout the dashboard. I.e., if you have many panels tapping (roughly) the same source data, you can significantly decrease the dashboard’s query load.
- Allows you to bring in a larger data set from either scheduled or unscheduled search (scheduled searches are even better for performance and compute-efficiency) and then use tokens to filter those results in post-process searches.
So… The guidance in Step 2 is to take your Reports in your dashboard and convert them to base searches. Then take your other dashboard panels and convert them in to post-process searches.
especially if the first line of each query is very similar (which is typical for a dashboard). Further, if you want to use dashboard inputs so that your tables or visualizations can be filtered by things like “user” or some other attribute of your data, you will need to convert your Reports to “base searches” and use the tokens (from dashboard inputs) in “post-process” searches. (Currently, Splunk does not support passing tokens from dashboards to Reports – though this is a feature in development. For obvious reasons, passing tokens to Scheduled Reports – reports that run prior to when a data input is specified – isn’t helpful/feasible.)
<!-- "Global" searches go in "dashboard" or "form" elements and will not directly display in dashboard. -->
<!-- For base search with scheduled Report with "ref" method. Run-as-Owner works for user with no access to index. **** PREFERRED **** -->
<search id="scheduledBaseSearch_ref" ref="eText Dashboard Base Search -18m@m - Scheduled"></search>
<!-- For base search with scheduled Report using savedsearch command: This works, but Run-as-Owner is not honored. Consequently, users without access to underlying index data will see "No results." At this time, this method appears to be deficit compared to PREFERRED method. **** Actively Discouraged **** -->
<search id="scheduledBaseSearch_savedsearch">
<query> | savedsearch "eText Dashboard Base Search -18m@m - Scheduled"</query>
</search>
<!-- For base search with scheduled Report using loadjob command: Run-as-Owner (RaO) works for user with no access to index. *** Useful as alternative to PREFERRED method only when Report name is not unique and other attributes such as app and owner are required. ***
<search id="scheduledBaseSearch_loadjob">
<query> | loadjob savedsearch="su-rthomas@illinois.edu:illinois-urbana-etext-citl-APP:eText Dashboard Base Search -18m@m - Scheduled"</query>
</search>
-->
<!-- For base search with unscheduled Report with "ref". Run-as-Owner (RaO) works for user with no access to index. NOTE: Scheduled reports are preferred over unscheduled reports. **** PREFERRED ****
<search id="unscheduledBaseSearch_ref" ref="eText Dashboard Base Search -18m@m"></search> -->
<!-- For base search with unscheduled Report with savedsearch command: Works, but user with no index access gets "No results." I.e., it works, but RaO is not honored making it deficit in comparison to preferred method. *** Actively DISCOURAGED ***
<search id="unscheduledBaseSearch_savedsearch">
<query> | savedsearch "eText Dashboard Base Search -18m@m"
</query>
</search>
-->
<!-- For base search with unscheduled Report with tokens with savedsearch command: Works, but user with no index access gets "No results." *** Useful as alternative to PREFERRED method only when you want to pass tokens to an unscheduled saved search *AND* the user has access to underlying index. *** This is how Splunk documents executing a saved search with tokens - but when using "savedsearch" command from a dashboard, the Run as Owner configuration of Report appears not to be honored. Bug or "by design"? Enhancement request submitted.
<search>
<query>| savedsearch "eText Dashboard Base Search -18m@m" personID="$personID$"</query>
</search>
-->
<!-- Use a scheduled report as a base search. This doesn't need to be in a row/panel. --> <search id="scheduledBaseSearch"> <query> | loadjob savedsearch="eText Dashboard Base Search - sectionName personID" </query> </search>
<!-- Use an unscheduled report as a base search. Note that this one has to be inside row/panel. --><row> <panel> <search id="unscheduledBaseSearch" ref="eText Dashboard Base Search - sectionName personID"> </search> </panel></row>
<!-- Here's how to reference the base search in a post-process search panel.→<panel>
<table> <title>Number of unique student logins per day</title> <search base="unscheduledBaseSearch"> <query>| timechart span=1d dc(personID) AS "Student Logins"</query> </search> </table>
</panel>