

The problem is that web server logs do not always contain session information. All KPI’s and metrics should be counted per session, not per page view. If a user goes to a website and views 100 pages, this should be monitored as one session, as this is one interaction between the user and your company. However, it is of limited value when it comes to measuring things from the user’s perspective. Measuring these alone can be beneficial when ranking page popularity or problematic pages. Each page viewed by a visitor would generate an entry in the web server log file. Sourcetype=x OR sourcetype=y | stats range(_time) as duration, count by sessionIDĪnother example where this is useful would be for website web server logs. Sourcetype=x OR sourcetype=y | transaction sessionID An example query could be something like this: However, Splunk can help join these dots to quickly perform a root cause analysis, and report metrics and KPIs on the service or process being monitored.Ĭommon Splunk search commands for combining events are transaction or stats. In this complex transaction, it can be tricky to quickly find the source of the problem. If something goes wrong in any of these systems, the payment might not go through. This real world event triggers a flurry of events in a large number of systems with the card provider, the bank, and the retailer before the transaction is fully settled.

Imagine a customer tapping their bank card on a payment terminal to purchase something in a shop. This concept is extremely useful if you want to link multiple events across data sources, that all relate to the same real world event. Splunk can also combine multiple events to visualize transactions, business processes and sessions. Splunk is a powerful tool that can analyze and visualize raw data, in all its forms.
