2018-06-19 16:57:10 -04:00
|
|
|
[role="xpack"]
|
2017-05-05 13:40:17 -04:00
|
|
|
[[ml-time-functions]]
|
2020-07-20 20:04:59 -04:00
|
|
|
= Time functions
|
2017-05-05 13:40:17 -04:00
|
|
|
|
|
|
|
The time functions detect events that happen at unusual times, either of the day
|
|
|
|
or of the week. These functions can be used to find unusual patterns of behavior,
|
|
|
|
typically associated with suspicious user activity.
|
|
|
|
|
2019-01-07 17:32:36 -05:00
|
|
|
The {ml-features} include the following time functions:
|
2017-05-09 11:23:08 -04:00
|
|
|
|
|
|
|
* <<ml-time-of-day,`time_of_day`>>
|
|
|
|
* <<ml-time-of-week,`time_of_week`>>
|
|
|
|
|
2017-05-05 13:40:17 -04:00
|
|
|
|
|
|
|
[NOTE]
|
|
|
|
====
|
2019-07-26 14:07:01 -04:00
|
|
|
* NOTE: You cannot create forecasts for {anomaly-jobs} that contain time
|
|
|
|
functions.
|
|
|
|
* The `time_of_day` function is not aware of the difference between days, for
|
|
|
|
instance work days and weekends. When modeling different days, use the
|
|
|
|
`time_of_week` function. In general, the `time_of_week` function is more suited
|
|
|
|
to modeling the behavior of people rather than machines, as people vary their
|
|
|
|
behavior according to the day of the week.
|
|
|
|
* Shorter bucket spans (for example, 10 minutes) are recommended when performing
|
|
|
|
a `time_of_day` or `time_of_week` analysis. The time of the events being modeled
|
|
|
|
are not affected by the bucket span, but a shorter bucket span enables quicker
|
|
|
|
alerting on unusual events.
|
|
|
|
* Unusual events are flagged based on the previous pattern of the data, not on
|
|
|
|
what we might think of as unusual based on human experience. So, if events
|
2019-12-05 03:57:01 -05:00
|
|
|
typically occur between 3 a.m. and 5 a.m., an event occurring at 3 p.m. is
|
2019-07-26 14:07:01 -04:00
|
|
|
flagged as unusual.
|
|
|
|
* When Daylight Saving Time starts or stops, regular events can be flagged as
|
|
|
|
anomalous. This situation occurs because the actual time of the event (as
|
|
|
|
measured against a UTC baseline) has changed. This situation is treated as a
|
|
|
|
step change in behavior and the new times will be learned quickly.
|
2017-05-05 13:40:17 -04:00
|
|
|
====
|
2017-05-05 14:57:20 -04:00
|
|
|
|
2020-07-23 12:42:33 -04:00
|
|
|
[discrete]
|
2017-05-09 11:23:08 -04:00
|
|
|
[[ml-time-of-day]]
|
2020-07-20 20:04:59 -04:00
|
|
|
== Time_of_day
|
2017-05-09 11:23:08 -04:00
|
|
|
|
|
|
|
The `time_of_day` function detects when events occur that are outside normal
|
|
|
|
usage patterns. For example, it detects unusual activity in the middle of the
|
|
|
|
night.
|
|
|
|
|
|
|
|
The function expects daily behavior to be similar. If you expect the behavior of
|
|
|
|
your data to differ on Saturdays compared to Wednesdays, the `time_of_week`
|
|
|
|
function is more appropriate.
|
|
|
|
|
|
|
|
This function supports the following properties:
|
|
|
|
|
|
|
|
* `by_field_name` (optional)
|
|
|
|
* `over_field_name` (optional)
|
|
|
|
* `partition_field_name` (optional)
|
2017-05-05 14:57:20 -04:00
|
|
|
|
2019-12-27 16:30:26 -05:00
|
|
|
For more information about those properties, see the
|
|
|
|
{ref}/ml-put-job.html#ml-put-job-request-body[create {anomaly-jobs} API].
|
2017-05-09 11:23:08 -04:00
|
|
|
|
2017-05-19 13:48:15 -04:00
|
|
|
.Example 1: Analyzing events with the time_of_day function
|
2017-05-05 14:57:20 -04:00
|
|
|
[source,js]
|
|
|
|
--------------------------------------------------
|
2017-05-09 11:23:08 -04:00
|
|
|
{
|
|
|
|
"function" : "time_of_day",
|
|
|
|
"by_field_name" : "process"
|
|
|
|
}
|
2017-05-05 14:57:20 -04:00
|
|
|
--------------------------------------------------
|
2018-06-19 16:57:10 -04:00
|
|
|
// NOTCONSOLE
|
2017-05-05 14:57:20 -04:00
|
|
|
|
2019-07-26 14:07:01 -04:00
|
|
|
If you use this `time_of_day` function in a detector in your {anomaly-job}, it
|
2017-05-19 13:48:15 -04:00
|
|
|
models when events occur throughout a day for each process. It detects when an
|
|
|
|
event occurs for a process that is at an unusual time in the day compared to
|
|
|
|
its past behavior.
|
2017-05-05 14:57:20 -04:00
|
|
|
|
2020-07-23 12:42:33 -04:00
|
|
|
[discrete]
|
2017-05-09 11:23:08 -04:00
|
|
|
[[ml-time-of-week]]
|
2020-07-20 20:04:59 -04:00
|
|
|
== Time_of_week
|
2017-05-09 11:23:08 -04:00
|
|
|
|
|
|
|
The `time_of_week` function detects when events occur that are outside normal
|
|
|
|
usage patterns. For example, it detects login events on the weekend.
|
|
|
|
|
|
|
|
This function supports the following properties:
|
|
|
|
|
|
|
|
* `by_field_name` (optional)
|
|
|
|
* `over_field_name` (optional)
|
|
|
|
* `partition_field_name` (optional)
|
|
|
|
|
2019-12-27 16:30:26 -05:00
|
|
|
For more information about those properties, see the
|
|
|
|
{ref}/ml-put-job.html#ml-put-job-request-body[create {anomaly-jobs} API].
|
2017-05-09 11:23:08 -04:00
|
|
|
|
2017-05-19 13:48:15 -04:00
|
|
|
.Example 2: Analyzing events with the time_of_week function
|
2017-05-09 11:23:08 -04:00
|
|
|
[source,js]
|
|
|
|
--------------------------------------------------
|
|
|
|
{
|
|
|
|
"function" : "time_of_week",
|
|
|
|
"by_field_name" : "eventcode",
|
|
|
|
"over_field_name" : "workstation"
|
|
|
|
}
|
|
|
|
--------------------------------------------------
|
2018-06-19 16:57:10 -04:00
|
|
|
// NOTCONSOLE
|
2017-05-19 13:48:15 -04:00
|
|
|
|
2019-07-26 14:07:01 -04:00
|
|
|
If you use this `time_of_week` function in a detector in your {anomaly-job}, it
|
2017-05-19 13:48:15 -04:00
|
|
|
models when events occur throughout the week for each `eventcode`. It detects
|
|
|
|
when a workstation event occurs at an unusual time during the week for that
|
|
|
|
`eventcode` compared to other workstations. It detects events for a
|
|
|
|
particular workstation that are outside the normal usage pattern.
|