About rmarcum

rmarcum · ‎02-18-2018

Splunk Version ............................................6.5.4Splunk Build ............................................adb84211dd7c

rmarcum · ‎02-18-2018

Oh, and the XML snippet when putting the URL below panel filters on a dashboard panel for a table: </input> <html> <body> <a href="http://www.google.com" target="_blank">Google</a> </body> </html> <table> <title> ....

rmarcum · ‎02-18-2018

Works for me per the original question, as noted on this HTML tutorial site: https://www.w3schools.com/tags/tryit.asp?filename=tryhtml_link_target

rmarcum · ‎08-10-2017

If this is from the Splunk ServiceNow App, the _time is most likely coming in as LOCAL, and sys_created_on as GMT. On your dashboard you most likely want your time chart to also be LOCAL time. Accordingly, I would recommend: | rename COMMENT AS "equate _time TO sys_created_on_Local which can be converted FROM sys_created_on_GMT " | eval _time=strptime((sys_created_on_GMT." UTC"),"%Y-%m-%d %T %Z") | timechart count ... etc.

rmarcum · ‎06-28-2017

I have successfully used my two suggestions above (i.e., "table" or put the code in a macro that contains the "fields -" command). Additionally, a real hack I sometimes use is a "focused" macro--e.g., FieldsMinus4 defined as: fields - $field1$, $field2$, $field3$, $field4$ Which I implement as: | makeresults | eval aField1=123 | eval aField2=456 | eval aField3=789 | `FieldsMinus4(aField1,a,b,c)` This takes advantage of the fields command working whether or not the field(s) exist that are passed as arguments. Thus I populate the 4 arguments using a, b, c, to make sure all 4 are there. This works for me for the many cases where there are less than 5 fields I need to remove. Regards.

rmarcum · ‎06-14-2017

BTW, another workaround I have for key code I do not want to change is to put it in a macro which seems to be immune to this issue. Again, I suspect "source".

rmarcum · ‎06-14-2017

I have been seeing this issue since we rolled out v6.5.x many weeks ago. I first encountered it when going in and out of the new Source edit feature, so I assume it has to do with recompilation of XML. I believe I see the same thing when I go into Source via "Views". I also see it in titles where I use a dash--e.g. "Title - More Title". Our admin has been unable to address the issue or provide a workaround. Basically, I have found no workaround other than not using "fields -", or using "table ...". This is the first time I have finally seen anyone mention such a HUGE issue on Splunk Answers...which has surprised me a bit. I use MSIE.

rmarcum · ‎06-14-2017

I have been seeing this issue since we rolled out v6.5.x many weeks ago. I first encountered it when going in and out of the new Source edit feature, so I assume it has to do with recompilation of XML. I believe I see the same thing when I go into Source via "Views". I also see it in titles where I use a dash--e.g. "Title - More Title". Our admin has been unable to address the issue or provide a workaround. Basically, I have found no workaround other than not using "fields -", or using "table ...". This is the first time I have finally seen anyone mention such a HUGE issue on Splunk Answers...which has surprised me a bit. I use MSIE.

rmarcum · ‎06-01-2017

Also, I should mention that things CAN change in the 300 second period and be MISSED by Splunk--e.g., changes in assignment groups. I am investigating the statistical significance of this. If it is an issue, since the Splunk SNOW index is such a small footprint, and incidents a VERY small part of that, I may go to 60 second hits on the SN API for snow:incident sourcetype and further test the impact on Splunk. Admin suggests "none".

rmarcum · ‎06-01-2017

The answer to both of your questions is "yes". Actually, a good idea to get a quick count. Thus, coming out of the first pipe will still often be multiple events for each ticket (i.e., many events = one ticket). Thus, I guess you could also add "active=false" before the first pipe to find only the events for tickets closed by ServiceDesk, and there should only be one event per ticket for these. Then, from our previous discussions, you could use your filter to removed those tickets which have been closed that were opened during the previous period. A test to prove this is: index=snow sourcetype=snow:incident assignment_group_name="<your_choice" active="false" | stats count by assignment_group_name, active, number | sort - count There should be no counts greater than 1. If there are, run this to see why. index=snow sourcetype=snow:incident assignment_group_name="your_choice" active="false" number="ticket_number_with_count_greater_than_1" | table _time number assignment_group_name active * In my case I have to watch for automated processes that happen and update the work notes more than 300 seconds after the ticket is closed. Knowing this, we can filter out any such events, or if VERY confident we know why, just dedup OR go directly to stats trick. This is based on the Splunk App for SN polling the ServiceNow API frequently (default is every 300 seconds looking for changes in sys_updated_on.

rmarcum · ‎06-01-2017

Actually, I do not use transaction, but instead leverage the stats output. Meaning, I believe your focus should NOT just be finding the last CLOSED ticket event, but rather an approach of finding the complete Ticket Life Cycle, including tickets which are still OPEN--i.e., before deciding on your reporting output. It is kind of amazing once you see it. You can see this looking into the ServiceNow GUI for an incident ticket, but requires a lot of reading the many threads just to understand what happened for one ticket. Here you will see them all at once! Of course, you will want to go to SN to verify your results at some point using some sampling schedule. Soooo, now deeper into my secret sauce (-: .... and, Please, anyone jump in to make this even better.... Before the 'stats trick', which I assumed you used "BY 'Ticket Number' or sys_id" to now have only one event per ticket, insert a concatenated string starting with _time: | eval trackingSTR=_time."__".assignment_group_name."__".<any_other_fields _desired_for_timeline_tracking> This will keep the timeline in order in the resulting tracking array field after stats. A double underscore is used as a unique value to allow for single underscores within field values that can interfere with later rex operations, when needed. Now, you can use 'match' (which works with multivalue fields) with this new field to keep only tickets 'touched' by ServiceDesk at any time within the ticket life cycle....key words for this analysis that no prior reporting has ever done...Ticket Life Cycle. We need to stop thinking LAST assignment group, which is always the "state value" in the ServiceNow database and always reported in the past, resulting in an incomplete view of the process...love the Splunk App!! If you add 'duration' (business or calendar) to the tracking string, you can also determine how long each assignment group has the ticket. You will be amazed at how many times these tickets are "passed around"...including "to" service desk from another assignment group who was the initial assignee...which it appears you are considering. And, when you see this time line array, I doubt you will want to only report on "Last Assignment Group". Finally, with mvindex (0 & -1) you can easily find the first and last assignment groups. And, the others "involved" can be reported too. BTW, remember that FCR is calculated on First Assignment Group, not Last. BTW2, I use calendar time durations since the help desk is 24/7...and it is easier to calculate. ((-:

rmarcum · ‎05-30-2017

| stats count(eval(OpenPrePeriod=1)) AS "Tickets Opened From Previous Period" count(eval(OpenPrePeriod=0)) AS "Tickets Opened This Period"

rmarcum · ‎05-30-2017

Some ideas to leverage: | rename COMMENT AS "### add FLAG for tickets opened before the start of metric time period ###" | eval OpenPrePeriod=if(opened_at_GMT<StartOfTimePeriod_GMT,1,0) Then at the appropriate time in the query for a particular dashboard panel (some panels should include preperiod, and some should not) you would leverage the "flag" with: OpenPrePeriod=1 or OpenPrePeriod=0 Use the timepicker to get StartOfTimePeriod_GMT which is the start of the time range selected from _time (i.e., _time = sys_updated_on_LOCAL set during indexing on most SN App installations) Do the above after doing the | stats values(*) AS * at which time the opened_at field will not be multi-value because it never changes. The sys_created_on is a good field also.

rmarcum · ‎05-27-2017

I stand corrected. I do follow most of the top 10 in the Splunk Leader Board, and I am sure I cannot accurately recall which key jewel I have obtained from which "expert". And, I am sure my work with Splunk over the past 10+ years includes many tips from each and every one. https://answers.splunk.com/users/index.html?all=1&sort=karma

rmarcum · ‎05-27-2017

Might I suggest: do not use dedup, but rather one of woodcock's favorites: stats values(*) AS * (prepending field values of key interest with _time), will keep any multivalue field in the correct order with time, i.e., the epoch number. we can then use mvindex to obtain any value(s) of interest from the "mv array" that we desire...the last item in the array will be the closed ticket (or, if the ticket is still open at the end of the selected period that event will be the last record in the array...keep an eye on the "active" true/false field); the first item in the array will be the opened ticket (beware that some of these arrays will start with NULL until the assignment_group_name gets assigned (thus we must "walk" down the array until we reach the first non NULL value) remember that _time can probably be used as a timechart scale for tickets opened, but a closed_at timechart scale must be used for closed tickets with this foundation table in place, some cleaver additional coding will give you total control for reporting the changes in assignement groups (more often than most realize), contact_types (crazy, right?), asignees, etc. Plus, we can now calculate the time periods a ticket "dwells" within an assignement group or assignee. finally, FCR calculations become "cake" Might I now thank woodcock for his MANY posts that over time have given me the key pieces for this concept that makes the SN Splunk App untouchable by any tools reporting ServiceNow metrics...even some of the new stuff SN has added for Offprem cloud installations cannot touch this Splunk solution. The key in my mind is the 300 second snapshots in the Splunk solution. (NOT something to "dedup" away, but rather to leverage in an array generated via woodcock's stats trick). .giving us a GB a month footprint Vs 45GB a day with warehouse solutions trying to report on ServiceNow. Regards.

rmarcum · ‎05-25-2017

Remember, at least based on my SN Splunk App experience: 1. opened_at may be GMT, and the rest of the dashboard (if that is the work product) is using _time which is probably LOCAL 2. indexing provides _time event timestamping via sys_updated_on probably giving _time as LOCAL 3. thus, we are collecting data for a time picker range of _time (update date snapshots) 4. considering all of this, I like to include a GMT offset for this "_time" solution provided above as follows; which should work for any time zone, and allows for daylight savings time (BTW, I have a habit of renaming SN fields immediately with an "_GMT" so I know which ones Splunk is indexing as GMT Vs LOCAL...which would be a function of your Admin's setup): | rename COMMENT AS "the first part is the date conversion to epoch, but using sys_created_on" | rename COMMENT AS "the second part calculates GMT offset using the fact that we index based on sys_updated_on so that field and _time gives us GMT offset (daylight or standard time)...being in California, I subtract the offset from the first part" | eval _time=(strptime(sys_created_on_GMT,"%Y-%m-%d %H:%M:%S"))-((strptime(sys_updated_on_GMT,"%Y-%m-%d %H:%M:%S"))-(_time))

rmarcum · ‎11-27-2016

Could you clarify "since macro arguments cannot contain other macros". I assume this is not meaning nested macros, which work well and I use in many solutions. Also, this question site contains many such explanations for this. Regards.

rmarcum · ‎10-28-2016

My approach has been to put all of the filters in a panel at the top of the dashboard with no chart, table, etc. code in it (see below), then have a filter on the dashboard that does a Hide/Show on the panel. Unless there is at least one filter in the panel, Splunk will discard the panel. So, start with this, add some filters, then discard this filter. <panel> <title>XXXX User Input Filters</title> <input type="multiselect" token="YYYY" searchWhenChanged="true"> <label>Select XXXX </label> <choice value="*">All </choice> <choice value="A">First</choice> <choice value="B">Second</choice> <choice value="C">Third</choice> <default>A,C </default> <valuePrefix>MyField="</valuePrefix> <valueSuffix>"</valueSuffix> <delimiter> OR </delimiter> </input> </panel>

rmarcum · ‎07-24-2016

Here is the answer, finally!! Only "earliest" and "latest" should be used without the token name prefix....sigh. And, this user shows success with the single quote, not the $. https://answers.splunk.com/answers/391250/why-does-timepicker-have-oldlag-context-data-durin.html

rmarcum · ‎07-15-2016

I do not think you will get a trigger with "Number of Results > 1". Consider using a "Custom" trigger of "search some_field=some_value

rmarcum · ‎07-11-2016

Hi JovanMilosevic, did this indeed work for you? We are looking for your secret. (-: Please check question: https://answers.splunk.com/answers/425146/simple-xml-dashboard-eval-strptime-using-old-value.html Best Regards

rmarcum · ‎07-09-2016

OK, tried that--i.e., blank line = no spaces in the line. Then, pasted in XML with "change" tags having 4 spaces indents and "eval" tags having 6 spaces indents. No change in results. Added blank line after for kicks since I do not know the objective here, with no change in results. Any hints as to your focus here? BTW, I do observe the same date duplication for start/end at times as seen by mortenb123 Also, let me share a few more items/observations: (4) The new token(s) from the "dashboard eval" is/are being used in HTML text on subsequent panels, and in panel titles, to show human readable time and epoch time (display of the latter date format is never a problem). This is a user feature I can obviously discard, but disappointing something this simple cannot be achieved. (5) When the dashboard is first opened, the "dashboard eval" token shows "Invalid date". Setting the same default date on the timepicker causes the "dashboard eval" tokens to refresh and display the correct values. (6) Changing the timepicker to another date is ignored by the "dashboard eval" token display, but not the epoch display. FYI, another action that causes the human readable time to show correctly on the dashboard panels is to toggle "Edit Panels" ON. When the time shows correctly, click "Done". (7) Regading the #2 issue I mentioned above, I am simply adjusting for PDT Vs GMT in my eval. This seems to fix it, if we just look at the date and not time, but it makes no sense to me and is hardwired for the current daylight time as follows: ...eval...token="start_time"....strftime(relative_time(‘time01.earliest’,"-7h@h"),"%B %d, %Y %I:%M:%S %p %z")

rmarcum · ‎07-09-2016

Got truncated, so, it looks like the XML angle brackets are not allowed in this text?...continuing (3) Please note the following answer, which indicates success by JovanMilosevic, where we are led to understand that the "dashboard eval" should be within the timepicker "... input..." using the "...change..." delimiter: https://answers.splunk.com/answers/334498/how-to-use-eval-on-a-token-from-a-time-picker-and.html This issue smacks of a bug, but hopefully instead is something simple we are overlooking. Indeed, this "dashboard eval" for a time picker is suppose to work exactly as being used by mortenb123. I have been staring at this and testing for hours, but no new results. I am using Splunk v6.3.4 build cae2458f4aef. Regards. rmarcum

rmarcum · ‎07-09-2016

I am having this same issue, with a slightly different "relative_time", which I doubt is relevant. IMHO, we need a closer look at this question and the documentation. (1) It "feels" like the sequencing of the timepicker during a dashboard opening, or filter setting change, is not aligned with the dashboard level eval at this location in the XML. Something is not triggering it. FYI, I have the same issues as mortenb123. I have tried many combinations of autoRun, submitButton, and searchWhenChanged, but I get this same issue. (2) Also, it seems like the epoch time that goes to this "dashboard eval" token is 86400 seconds off of the epoch time contained in the "field1.*est" tokens being passed--e.g., pass the original value straight through this eval path to see this happening. Maybe this has something to do with the documentation cautioning us regarding the following for "dashboard evals", which, actually, I do not understand the point, i.e.: relative_time(X,Y): Uses client time zone. strftime(X,Y): Uses client time zone. strptime(X,Y): Uses client time zone. (3) Please note the following answer, which indicates success by JovanMilosevic, where we are led to understand that the "dashboard eval" should be within the timepicker "

rmarcum · ‎12-28-2015

When setting up the App using the Configuration GUI for "Splunk for Active Directory Support", v2.1.2, I find that the backslash escaping a comma within CN text works perfectly in the Bind DN string for authentication. A little off the focus of the question, but related to syntax solutions in general Splunk and this App.

Posts	28
Solutions	0
Karma Given	0
Karma Received	2
Member Since	‎09-17-2014

Online Status	Offline
Date Last Visited	‎06-05-2020 02:03 AM

Re: External link in default.xml - open in new tab...

Re: External link in default.xml - open in new tab...

Re: External link in default.xml - open in new tab...

Re: count how many records was opened by open date...

Re: Splunk Bug "fields command"

Re: Splunk Bug "fields command"

Re: Splunk Bug "fields command"

Re: Splunk Bug "fields command"

Re: How to show open incidents by month

Re: How to show open incidents by month

Re: How to show open incidents by month

Re: How to show open incidents by month

Re: How to show open incidents by month

Re: How to show open incidents by month

Re: How to show open incidents by month

Re: How to show open incidents by month

Re: How to pass a macro'ed value (string or number...

Re: How to hide all form input filters in a dashbo...

Re: simple xml dashboard eval strptime using old v...

Re: My search returns results, but why are alerts ...

Re: How to use eval on a token from a time picker ...

Re: simple xml dashboard eval strptime using old v...

Re: simple xml dashboard eval strptime using old v...

Re: simple xml dashboard eval strptime using old v...

Re: How to properly escape a DN (with commas) for ...