Hey @ddrillic !
The use of metrics are suited for particular types of data. So think of it more as logs AND metrics. not OR.
https://docs.splunk.com/Documentation/Splunk/7.2.1/Metrics/GetStarted
Just another powerful option in your Splunk toolbox
As a Splunk admin/user, you do not have to replace anything . SPL, tstats, summary indexing & dashboarding is still awesome.
However, If you find yourself curating data for users using timecharts/dashboards, the combination of metric data type and the metric workspace, is a giant leap forward in the life of Splunk users and admins. - https://splunkbase.splunk.com/app/4192/
Features like the logs-to-metrics, mcatalog , and the workspace, make working with the time series metric data much easier and give the user a great experience from day 1.
Once you get into more advanced consumption of the metric data and move to the "open in search" button, you still have all the power of SPL.
Even alerting is just a point a click away. No need for them to learn any of the SPL required to get value out of metrics.
Prime examples to begin exploring are time-series performance metrics that come out of tools like snmp pollers, metric agents like Splunk UF apps, collectd, telegraf, prometheus, etc.
All this data can be Splunked as events and represented in timechart form, but the price for entry is SPL knowledge and dashboarding know how.....So these are the places to start looking at integrations, so you can make this data more accessible and enjoyable to use for the basic user in an Splunk shop.
This does not mean, however, you could not get tremendous value out of both raw event data as well as metric representation.
Thats where |mcollect is interesting.
Many times you may like to have very granular operational event data around, but then summarize and roll off the granular data for a metric summary.
An example might be Firewall session logs, or the output of a scripted input, where the event data may be useful for granular troubleshooting and session analysis, but may be equally as impactful to others as a timechart of avg session metrics as a "check engine light" (metric) rather than "a diagnostic report"(events). Marry the two together and you graduate from static dashboarding and into drilldowns that get to root cause, not just draw pretty graphs.
So I guess what I would say is, begin to explore the metrics data type when you are working with timeseries metrics data, for easy human consumption and self-serve curations in the metrics workspace. (its all just the Splunk Indexed Extractions logic you already know!)
Logs will still always be there to provide the drilldown and analysis to go with the metrics, or to do advanced calculations and data wizardry that the workspace/metric store doesn't handle, but it's when you bring the two data types together when you start to get tremendous insight into the two data types.
Hey @ddrillic !
The use of metrics are suited for particular types of data. So think of it more as logs AND metrics. not OR.
https://docs.splunk.com/Documentation/Splunk/7.2.1/Metrics/GetStarted
Just another powerful option in your Splunk toolbox
As a Splunk admin/user, you do not have to replace anything . SPL, tstats, summary indexing & dashboarding is still awesome.
However, If you find yourself curating data for users using timecharts/dashboards, the combination of metric data type and the metric workspace, is a giant leap forward in the life of Splunk users and admins. - https://splunkbase.splunk.com/app/4192/
Features like the logs-to-metrics, mcatalog , and the workspace, make working with the time series metric data much easier and give the user a great experience from day 1.
Once you get into more advanced consumption of the metric data and move to the "open in search" button, you still have all the power of SPL.
Even alerting is just a point a click away. No need for them to learn any of the SPL required to get value out of metrics.
Prime examples to begin exploring are time-series performance metrics that come out of tools like snmp pollers, metric agents like Splunk UF apps, collectd, telegraf, prometheus, etc.
All this data can be Splunked as events and represented in timechart form, but the price for entry is SPL knowledge and dashboarding know how.....So these are the places to start looking at integrations, so you can make this data more accessible and enjoyable to use for the basic user in an Splunk shop.
This does not mean, however, you could not get tremendous value out of both raw event data as well as metric representation.
Thats where |mcollect is interesting.
Many times you may like to have very granular operational event data around, but then summarize and roll off the granular data for a metric summary.
An example might be Firewall session logs, or the output of a scripted input, where the event data may be useful for granular troubleshooting and session analysis, but may be equally as impactful to others as a timechart of avg session metrics as a "check engine light" (metric) rather than "a diagnostic report"(events). Marry the two together and you graduate from static dashboarding and into drilldowns that get to root cause, not just draw pretty graphs.
So I guess what I would say is, begin to explore the metrics data type when you are working with timeseries metrics data, for easy human consumption and self-serve curations in the metrics workspace. (its all just the Splunk Indexed Extractions logic you already know!)
Logs will still always be there to provide the drilldown and analysis to go with the metrics, or to do advanced calculations and data wizardry that the workspace/metric store doesn't handle, but it's when you bring the two data types together when you start to get tremendous insight into the two data types.
