Splunk® Enterprise

Search Manual

Search using time bins and spans

stats, chart, timechart

bins

dbinspect

makecontinuous

sichart

index=_internal metrics | bin date_hour bins=24 | stats count(_raw) by date_hour

I get 15 bins, all 2 hour increments such as 10-11 and 11-12 and 14-15, some hours skipped

Is the number of bins it based on when (time) the events occur? Yes

If bins is specified, the software takes the field time range (24 date_hour) and divides by the number of bins (24) = 1.

Then determines if the span is 1 hour, will all of the events fit into 24 bins with 1 hour in length

determines the least power of 10 to use for the span, 1, 10, 100, 1000 (or .1, .01, .001)

index=_internal metrics | bin date_hour bins=12 | stats count(_raw) by date_hour

I get 3 bins, 10 hour increments such as 0-10-10-20, 20-30.

24 data_hour / 12 bins = 2 is the calculated span

1 (10 to the power of 0) is less than 2, so can't use that span.

```       10 (10 to the 1 power of 1) is 10, which is greater than 2, so 10 is the span used.
```

Don't specify a span, the assumed calculated span is a power of 10

So I add the span argument

index=_internal metrics | bin date_hour span=2 bins=12 | stats count(_raw) by date_hour

Regardless of whether I specify bins=12 or bins=24, I get 8 results with ranges like 10-12 and 14-16

When it gives ranges like 14-16 and 16-18 I'm assuming that is "14 up to but not including 16" and that the next bin which starts at 16 is "16 up to but not including 18". Is that correct?

If specify span and bins, bins is ignored. Spans takes precedence

Span – end is not inclusive

For example, if the given values serial is [0, 1, 2, … 59] and 'bins' is specified as 5, then the calculated span granularity will be 100. The whole serial [0..59] will fall into a 1 bin: [0-100] (1 is less than the given value 5)

Why is the calculated span granularity 100? Why not 60?

60/5 = 12

12 is greater than 10 and less that 100 so the calculated span used is 100. The 60 values are less than 100, so there is a need for only 1 bin

For the sample example, if 'bins' is specified as 6, then the calculated span granularity will be 10. The whole serial [0..59] will fall into 6 bins: [0-10], [10-20], ...[50-60] ( 6 is equal to the given value 6)

Is the granularity 10 because 6 (bins) divides evenly into 60 (values)?

60/6 = 10

10 is a power of 10 (10 to the 1st power), so the calculated span of 10 is used. The 60 values, using a span of 10, will fit into 6 bins

Time and timezone discussion

When data is indexed (ingested) the timestamp can come from several places:

1. Timestamp is in UTC

2. Events have human readable timestamp, such as 10:55 EST, or a timestamp offset from GMT such as -0700 UTC

3. Events have a local time such as 10:55AM (no timezone), which are interpreted to be the same timezone as the Splunk server where the data is indexed.

All of these are converted to UTC and stored in the _time field.

When a user specifies a time, the time is converted into UTC. For example if you search from 12:00 to 14:00 PDT, that is equivalent to 19:00 to 21:00 UTC (7 hours ahead of PDT). When daylight savings time is over, the difference between UTC and PST is 8 hours.

When the time bins cross multiple days (or months), the bins are aligned to the local day boundary.

The events will be the same for the range since the events are processed in UTC. But some events in might appear in one bin in a timezone, and in another bin in a different timezone.

Another example is the time range for the search.

When you specify a time range, either through the time range picker or explicitly in the search with the "earliest" and "latest" time (modifiers), the events are processed based on which time range is used.

If the search specifies "Last 24 hours", then the search processes the events using UTC time. The same set of events are returned for a user in SF and a user in Tokyo.

If the search specifies "Since midnight today", the search processes events based on the midnight of the timezone, not UTC time. A different set of events are returned for a user in SF and a user in Tokyo, because the time that midnight occurs is different in each timezone.

If the search uses a snap-to time, such as @d or @mon, the search processes events based on the "day" or "month" of the timezone, not UTC time. A different set of events are returned for a user in SF and a user in Tokyo, because the time that midnight occurs is different in each timezone.

Local time set to splunk server

<span-length>

Syntax: <int>[<timescale>]

Description: A span of each bin, based on time. If the timescale is provided, this is used as a time range. If not, this is an absolute bin length.

bins – if not _time, can use on numeric fields, and span is a simple number (not time unit)

minspan

Syntax: minspan=<span-length>

Description: Specifies the smallest span granularity to use when automatically inferring span from the data time range.

Can set a bins, and inconjuction with midspan, satisfies both

underlying data is periodic – sensor ever 30 secs

Start time of the first bin doesn't necessarily align with the time range – 12 hours not the same as 1/2 day.

Unit is less than a day

everything is aligned to GMT (UTC)

bins – aligned to UTC by default – can use aligntime

search boundaries are aligned to local time

Use @day or

if less than a day, use aligntime option

Time zones and time bins

You can use the `bin`, `chart`, and `timechart` commands to organize your search results into time bins.

Time bins are calculated based on <bin-options> settings, such as `bins` and `span`. For more about how time bins are calculated, see Search using time bins and spans.

When the time bins cross multiple days or months the bins are aligned to the local day boundary.

The events returned are the same for the time range since the events are processed using UNIX time. But some events in might appear in one bin in a timezone, and in another bin in a different timezone.

Another example is the time range for the search.

When you specify a time range, either through the time range picker or explicitly in the search with the "earliest" and "latest" time (modifiers), the events are processed based on which time range is used.

If the search specifies "Last 24 hours", then the search processes the events using UTC time. The same set of events are returned for a user in SF and a user in Tokyo.

If the search specifies "Since midnight today", the search processes events based on the midnight of the timezone, not UTC time. A different set of events are returned for a user in SF and a user in Tokyo, because the time that midnight occurs is different in each timezone.

If the search uses a snap-to time, such as @d or @mon, the search processes events based on the "day" or "month" of the timezone, not UTC time. A different set of events are returned for a user in SF and a user in Tokyo, because the time that midnight occurs is different in each timezone.