Splunk Search

Custom Variables \ eVars in Splunk – Segment all data on a user event.

DanielFordWA
Contributor

I use iis server logs, each user has a unique ID (cs_username) as authentication is required on the site.

Does Splunk have the ability to query the data as you would in GA Custom Variables or eVars in Omniture?

As I understand it the following query will return data from all logs when the fields match "cs_username" and "cs_uri_stem=/SearchResults/" and give me a unique count of the users visiting the "SearchResults/" page.

sourcetype="iis-2" | extract auto=true | search cs_username="*" AND cs_uri_stem="*/SearchResults/*" | stats dc(cs_username) by cs_uri_stem | eval cs_uri_stem=urldecode(cs_uri_stem)

What I want to get to is showing all the cs_uri_stem values when a user has visited the "SearchResults/" page in a given time period.

I could then segment the data and see all pages for all users that have visited the "SearchResults/" page in a given time period.

Is this possible?

0 Karma

DanielFordWA
Contributor
sourcetype="iis-2" | extract auto=true | search [ search cs_username="*123*" AND cs_uri_stem="*/SearchResults*" | fields cs_username ] | stats count(DocAction) by cs_username DocType date_mday

The above works when the date range of one day is selected. I can see who used search and what Documents were viewed and the actions taken against them.

In the below I am trying to understand the users that used search and how many documents were viewed in the same session for a larger time period, week , month, year etc.

I do not have a session ID, I use transaction cs_username maxspan=30m.

With this in mind will the "count" below give me the total number of sessions for a user and the documents viewed for all sessions, not just sessions with search "/SearchResults" as I am using the cs_username instead of a session ID?

Do I need to create session ID? If so how could I do this before or after indexing?

sourcetype="iis-2" | extract auto=true | search [ search cs_username="*123*" AND cs_uri_stem="*/SearchResults*" | transaction cs_username maxspan=30m | fields cs_username ] | transaction cs_username maxspan=30m | stats count count(DocAction) by cs_username DocType date_mday
0 Karma

DanielFordWA
Contributor

Hi, I am still having issues with getting the above to work, I have even managed to crash Splunk a few times 🙂 Any advice would be much appreciated.

0 Karma

DanielFordWA
Contributor

Thanks for the reply. When you put it like that it seems a lot simpler.

I am looking at between 3500-400 users in daily time frame for this type of user.

I guess I could get a list of users that use search, put this list in a lookup and query the rest of the data.

I would look at using the search user group to see what content they consume and actions they perform in a day, with this in mind instead of getting all pages for every users I could ask it to search against a specific field or cs_uri_stem.

Is there an easier way than using a lookup as I would have to alter this for each day.

0 Karma

norbert_hamel
Communicator

So actually you need 2 searches: 1st searching all user names who have visited the SearchResults page, for example in the last 24 hours. And 2nd searching all page for the found user names over a certain time range (which might be again 24 hours or any other time range).
Do I understand your requirements correctly? How many user names do you expect for the 1st search? You could use a subsearch for that, but this might cause performance issues when for high number of users.

Get Updates on the Splunk Community!

Enterprise Security Content Update (ESCU) | New Releases

In December, the Splunk Threat Research Team had 1 release of new security content via the Enterprise Security ...

Why am I not seeing the finding in Splunk Enterprise Security Analyst Queue?

(This is the first of a series of 2 blogs). Splunk Enterprise Security is a fantastic tool that offers robust ...

Index This | What are the 12 Days of Splunk-mas?

December 2024 Edition Hayyy Splunk Education Enthusiasts and the Eternally Curious!  We’re back with another ...