# X-Pack Audit Trail logs cannot further specified

**URL:** <https://discuss.elastic.co/t/x-pack-audit-trail-logs-cannot-further-specified/108351>\
**Category:** Elasticsearch\
**Created:** [November 20, 2017, 9:23am UTC](https://discuss.elastic.co/t/x-pack-audit-trail-logs-cannot-further-specified/108351 "2017-11-20T09:23:05Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![fluency03](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/fluency03/32/21977_2.png) [@fluency03](https://discuss.elastic.co/u/fluency03)\
**Post date:** [November 20, 2017, 9:23am UTC](https://discuss.elastic.co/t/x-pack-audit-trail-logs-cannot-further-specified/108351/1 "2017-11-20T09:23:05Z")

</div>

**Describe the feature** :

When we enable X-Pack's Audit Trail as following:

```auto
xpack.security.audit:
  enabled: true
  outputs: [index, logfile]

```

What we would like to monitor are mainly two things;

- the login actions
- the actions performed by the _real actual_ users, instead of also having `kibana`, `logstash` and other NPA users.

However, in the audit logs, there are full of these logs from `principle` - `kibana` and other NPA users. Because of there are too many of such logs ( `Kibana` is basically doing this every several seconds for healthcheck), it takes lots of disk space, and more importantly, we cannot have a clear picture about what the real human users have done. You can see how many logs are generated every minutes:

 ![audit1](https://user-images.githubusercontent.com/7440735/32897795-d037e7fc-cae6-11e7-8711-8a0a9561cb26.PNG)

For example, in the following case, I only what the logs with principle of an actual user name, like the one in the bottom of this image. But there are many logs with principles like `kibaba`, `_xpack_security`, etc.

 ![audit2](https://user-images.githubusercontent.com/7440735/32897842-eb03b138-cae6-11e7-90be-6528176e7508.PNG)

This lack-of-feature is also described here by Guy Shilo: [http://www.idata.co.il/2017/03/securing-elasticsearch-cluster-part-3-auditing/](http://www.idata.co.il/2017/03/securing-elasticsearch-cluster-part-3-auditing/). He provided a temporary solution which is to configure the `log4j.properties` file of x-pack, by adding regex filtering. But this is only a temporary solution, and regex expression we have to define really depending on log style of elastic. This makes our development process not flexible.

**Elasticsearch version** : 5.6.2

---

<div class="post-metadata">

**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\
**Post date:** [December 18, 2017, 9:23am UTC](https://discuss.elastic.co/t/x-pack-audit-trail-logs-cannot-further-specified/108351/2 "2017-12-18T09:23:24Z")

</div>

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.