I would also like to understand how I could find the event that was anomalous and not just the time bucket?
The way Elastic anomaly detection works is to create summary statistics per time bucket and detect anomalies in those summary statistics. This is what makes it scalable. It is not designed to tell you that one specific event (document) was the cause.
One thing you can do is to specify influencer fields in your analysis config. These may help to narrow down which event(s) caused the anomaly to be detected.
The workflow we envisage is that once we report an anomaly for a particular time bucket somebody who understands the input data will drill down into it using the time bucket and influencer field values as filters to see the raw document(s) that were responsible.
And it is a user that behaves differently compared to other users at the same location, not changing his own behaviour (that's why I would use "Population" with user as population field
Agreed, user should be the population field, which is
over_field_name in the detector config.
should I split each detector by location or already select my datafeed accordingly and create one job per location?
That depends on the data volume. You could specify location as the
partition_field_name. Depending on the data volume this might work well, or it might make the job's memory requirement so high that it is better to have one job per location.
So I was wondering if X-Pack models the relation between various features to find anomalies or only looks at each single detector?
Basically it's looking at each individual detector. The anomaly explorer view in the UI will help you see when there are multiple anomalies in the same time bucket.
One other option to consider that will take into account many features together would be to use Elastic data frame analytics to do one outlier detection job for each location, listing all your various features/fields as included fields. There's an end-to-end example with screenshots that might give you a better idea of whether this would be more suitable for your use case than our anomaly detection functionality.