# Would like to separate out SG logs from ES logs. **URL:** \ **Category:** Search Guard\ **Created:** [April 17, 2018, 4:09pm UTC](https://forum.search-guard.com/t/would-like-to-separate-out-sg-logs-from-es-logs/877 "2018-04-17T16:09:56Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![CHS](https://avatars.discourse-cdn.com/v4/letter/c/5f8ce5/32.png) [@CHS](https://forum.search-guard.com/u/CHS)\ **Post date:** [April 17, 2018, 4:09pm UTC](https://forum.search-guard.com/t/would-like-to-separate-out-sg-logs-from-es-logs/877/1 "2018-04-17T16:09:56Z")
I guess this is more of a log4j2 question than anything else, but we have a requirement to let another team have access to our elasticsearch logs (And by this, I mean the log file generated by the elasticsearch process controlled by log4j2.properties, not the documents that are inside the elasticsearch cluster itself). The only problem is that the logs for the searchguard process are combined with the regular elasticsearch process logs. Is there a way to separate the two so that we can put the searchguard logs into a different file than the one elasticsearch is using for its own logs? I did experiment with the auditlog, but that still doesn’t capture the actual searchguard process logs. It works great for audit events though! I’m guessing this would require some changes to log4j2.properties, but understanding that file is completely foreign to me. Thanks! - Search Guard and Elasticsearch version SG 5.6.7, ES 5.6.7 - Installed and used enterprise modules, if any Auditlog ---
**Author:** ![CHS](https://avatars.discourse-cdn.com/v4/letter/c/5f8ce5/32.png) [@CHS](https://forum.search-guard.com/u/CHS)\ **Post date:** [April 19, 2018, 3:14pm UTC](https://forum.search-guard.com/t/would-like-to-separate-out-sg-logs-from-es-logs/877/2 "2018-04-19T15:14:39Z")
Anyone? If this isn’t possible, that’s fine, I’d just like to know. > **···** > > On Tuesday, April 17, 2018 at 11:09:56 AM UTC-5, ch s wrote: > > > I guess this is more of a log4j2 question than anything else, but we have a requirement to let another team have access to our elasticsearch logs (And by this, I mean the log file generated by the elasticsearch process controlled by log4j2.properties, not the documents that are inside the elasticsearch cluster itself). The only problem is that the logs for the searchguard process are combined with the regular elasticsearch process logs. Is there a way to separate the two so that we can put the searchguard logs into a different file than the one elasticsearch is using for its own logs? > > > > > > I did experiment with the auditlog, but that still doesn’t capture the actual searchguard process logs. It works great for audit events though! > > > > > > I’m guessing this would require some changes to log4j2.properties, but understanding that file is completely foreign to me. > > > > > > Thanks! > > > > > > > > > - Search Guard and Elasticsearch version > > > SG 5.6.7, ES 5.6.7 > > > > > > - Installed and used enterprise modules, if any > > > Auditlog > > > > > > ---
**Author:** ![searchguard\_google\_group](https://sea1.discourse-cdn.com/flex019/user_avatar/forum.search-guard.com/searchguard_google_group/32/462_2.png) [@searchguard\_google\_group](https://forum.search-guard.com/u/searchguard_google_group)\ **Post date:** [April 19, 2018, 3:45pm UTC](https://forum.search-guard.com/t/would-like-to-separate-out-sg-logs-from-es-logs/877/3 "2018-04-19T15:45:12Z")
of course you can do this. but as you said this is more log4j than SG related. All loggers for searchguard start with com.floragunn or sg\_action\_trace (for auditlogs you can configure the loggername yourself) So just route them into another file than the rest of the logs. > **···** > > > Am 19.04.2018 um 17:14 schrieb ch s \: > > > > Anyone? If this isn't possible, that's fine, I'd just like to know. > > > > On Tuesday, April 17, 2018 at 11:09:56 AM UTC-5, ch s wrote: > > I guess this is more of a log4j2 question than anything else, but we have a requirement to let another team have access to our elasticsearch logs (And by this, I mean the log file generated by the elasticsearch process controlled by log4j2.properties, not the documents that are inside the elasticsearch cluster itself). The only problem is that the logs for the searchguard process are combined with the regular elasticsearch process logs. Is there a way to separate the two so that we can put the searchguard logs into a different file than the one elasticsearch is using for its own logs? > > > > I did experiment with the auditlog, but that still doesn't capture the actual searchguard process logs. It works great for audit events though! > > > > I'm guessing this would require some changes to log4j2.properties, but understanding that file is completely foreign to me. > > > > Thanks! > > > > \* Search Guard and Elasticsearch version > > SG 5.6.7, ES 5.6.7 > > > > \* Installed and used enterprise modules, if any > > Auditlog > > > > -- > > You received this message because you are subscribed to the Google Groups "Search Guard Community Forum" group. > > To unsubscribe from this group and stop receiving emails from it, send an email to search-guard+unsubscribe@googlegroups.com. > > To post to this group, send email to search-guard@googlegroups.com. > > To view this discussion on the web visit [https://groups.google.com/d/msgid/search-guard/341eaa26-3c07-4255-8f08-bfd60f78793c%40googlegroups.com\](https://groups.google.com/d/msgid/search-guard/341eaa26-3c07-4255-8f08-bfd60f78793c%40googlegroups.com%5C). > > For more options, visit [https://groups.google.com/d/optout\](https://groups.google.com/d/optout%5C). ---
**Author:** ![CHS](https://avatars.discourse-cdn.com/v4/letter/c/5f8ce5/32.png) [@CHS](https://forum.search-guard.com/u/CHS)\ **Post date:** [April 19, 2018, 3:48pm UTC](https://forum.search-guard.com/t/would-like-to-separate-out-sg-logs-from-es-logs/877/4 "2018-04-19T15:48:25Z")
You don’t have any examples of integrating this with the existing elasticsearch log4j2 file? > **···** > > On April 19, 2018 10:45:12 AM CDT, SG [info@search-guard.com](mailto:info@search-guard.com) wrote: > > > ```auto > > of course you can do this. but as you said this is more log4j than SG related. > > All loggers for searchguard start with com.floragunn or sg_action_trace (for auditlogs you can configure the loggername yourself) > > So just route them into another file than the rest of the logs. > > > > > Am 19.04.2018 um 17:14 schrieb ch s : > > > > > > Anyone? If this isn't possible, that's fine, I'd just like to know. > > > > > > On Tuesday, April 17, 2018 at 11:09:56 AM UTC-5, ch s wrote: > > > I guess this is more of a log4j2 question than anything else, but we have a requirement to let another team have access to our elasticsearch logs (And by this, I mean the log file generated by the elasticsearch process controlled by log4j2.properties, not the documents that are inside the elasticsearch cluster itself). The only problem is that the logs for the searchguard process are combined with the regular elasticsearch process logs. Is there a way to separate the two so that we can put the searchguard logs into a different file than the one elasticsearch is using for its own logs? > > > > > > I did experiment with the auditlog, but that still doesn't capture the actual searchguard process logs. It works great for audit events though! > > > > > > I'm guessing this would require some changes to log4j2.properties, but understanding that file is completely foreign to me. > > > > > > Thanks! > > > > > > > > > * Search Guard and Elasticsearch version > > > SG 5.6.7, ES 5.6.7 > > > > > > * Installed and used enterprise modules, if any > > > Auditlog > > > > > > > > > > > > -- > > > You received this message because you are subscribed to the Google Groups "Search Guard Community Forum" group. > > > To unsubscribe from this group and stop receiving emails from it, send an email to search-guard+unsubscribe@googlegroups.com. > > > To post to this group, send email to search-guard@googlegroups.com. > > > To view this discussion on the web visit [https://groups.google.com/d/msgid/search-guard/341eaa26-3c07-4255-8f08-bfd60f78793c%40googlegroups.com.](https://groups.google.com/d/msgid/search-guard/341eaa26-3c07-4255-8f08-bfd60f78793c%40googlegroups.com.) > > > For more options, visit [https://groups.google.com/d/optout.](https://groups.google.com/d/optout.) > > > > ``` ---
**Author:** ![jkressin](https://sea1.discourse-cdn.com/flex019/user_avatar/forum.search-guard.com/jkressin/32/9_2.png) [@jkressin](https://forum.search-guard.com/u/jkressin)\ **Post date:** [April 19, 2018, 8:34pm UTC](https://forum.search-guard.com/t/would-like-to-separate-out-sg-logs-from-es-logs/877/5 "2018-04-19T20:34:58Z")
For an example you can refer to the Search Guard docs: > **[TLS troubleshooting](https://docs.search-guard.com/latest/troubleshooting-tls)** > > Step-by-step instructions to troubleshoot Search Guard TLS and certificates issues So basically you create a new logger and a new appender in your log4j2.properties file.The appender specifies the file name and location amongst other settings, and is connected to the actual logger via an appenderRef. For example, have a look at how the deprecation logger is defined. Just follow this pattern, and replace the “deprecation” with, for example, “searchguard”. The base packe for all SG relates classes is “com.floragunn”. logger.deprecation.name = org.elasticsearch.deprecation logger.deprecation.level = warn logger.deprecation.appenderRef.deprecation\_rolling.ref = deprecation\_rolling logger.deprecation.additivity = false appender.deprecation\_rolling.type = RollingFile appender.deprecation\_rolling.name = deprecation\_rolling appender.deprecation\_rolling.fileName = ${sys:es.logs.base\_path}${sys:file.separator}${sys:es.logs.cluster\_name}\_deprecation.log appender.deprecation\_rolling.layout.type = PatternLayout appender.deprecation\_rolling.layout.pattern = [%d{ISO8601}][%-5p][%-25c{1.}] %marker%.-10000m%n appender.deprecation\_rolling.filePattern = ${sys:es.logs.base\_path}${sys:file.separator}${sys:es.logs.cluster\_name}\_deprecation-%i.log.gz appender.deprecation\_rolling.policies.type = Policies appender.deprecation\_rolling.policies.size.type = SizeBasedTriggeringPolicy appender.deprecation\_rolling.policies.size.size = 1GB appender.deprecation\_rolling.strategy.type = DefaultRolloverStrategy appender.deprecation\_rolling.strategy.max = 4 `` > **···** > > On Thursday, April 19, 2018 at 8:48:32 AM UTC-7, ch s wrote: > > > You don’t have any examples of integrating this with the existing elasticsearch log4j2 file? > > > > On April 19, 2018 10:45:12 AM CDT, SG [info@search-guard.com](mailto:info@search-guard.com) wrote: > > > > > ```auto > > > of course you can do this. but as you said this is more log4j than SG related. > > > All loggers for searchguard start with com.floragunn or sg_action_trace (for auditlogs you can configure the loggername yourself) > > > So just route them into another file than the rest of the logs. > > > > > > > Am 19.04.2018 um 17:14 schrieb ch s : > > > > > > > > Anyone? If this isn't possible, that's fine, I'd just like to know. > > > > > > > > On Tuesday, April 17, 2018 at 11:09:56 AM UTC-5, ch s wrote: > > > > I guess this is more of a log4j2 question than anything else, but we have a requirement to let another team have access to our elasticsearch logs (And by this, I mean the log file generated by the elasticsearch process controlled by log4j2.properties, not the documents that are inside the elasticsearch cluster itself). The only problem is that the logs for the searchguard process are combined with the regular elasticsearch process logs. Is there a way to separate the two so that we can put the searchguard logs into a different file than the one elasticsearch is using for its own logs? > > > > > > > > I did experiment with the auditlog, but that still doesn't capture the actual searchguard process logs. It works great for audit events though! > > > > > > > > I'm guessing this would require some changes to log4j2.properties, but understanding that file is completely foreign to me. > > > > > > > > Thanks! > > > > > > > > > > > > * Search Guard and Elasticsearch version > > > > SG 5.6.7, ES 5.6.7 > > > > > > > > * Installed and used enterprise modules, if any > > > > Auditlog > > > > > > > > > > > > > > > > -- > > > > You received this message because you are subscribed to the Google Groups "Search Guard Community Forum" group. > > > > To unsubscribe from this group and stop receiving emails from it, send an email to search-guard+unsubscribe@googlegroups.com. > > > > To post to this group, send email to search-guard@googlegroups.com. > > > > To view this discussion on the web visit [https://groups.google.com/d/msgid/search-guard/341eaa26-3c07-4255-8f08-bfd60f78793c%40googlegroups.com.](https://groups.google.com/d/msgid/search-guard/341eaa26-3c07-4255-8f08-bfd60f78793c%40googlegroups.com.) > > > > For more options, visit [https://groups.google.com/d/optout.](https://groups.google.com/d/optout.) > > > > > > ``` ---
**Author:** ![CHS](https://avatars.discourse-cdn.com/v4/letter/c/5f8ce5/32.png) [@CHS](https://forum.search-guard.com/u/CHS)\ **Post date:** [April 19, 2018, 9:58pm UTC](https://forum.search-guard.com/t/would-like-to-separate-out-sg-logs-from-es-logs/877/6 "2018-04-19T21:58:59Z")
Thanks for the tips. Looks like I’ve got it mostly working. Logs are now going to a separate logfile, but some logs are still being captured in the ES log file. For example (lines trimmed): [2018-04-19T21:42:20,491][WARN][c.f.d.a.l.b.LDAPAuthorizationBackend] Unable to connect to ldapserver due to[trimmed] [2018-04-19T21:42:20,492][ERROR][c.f.s.a.BackendRegistry] Problems retrieving roles for User [name=admin, roles=] [trimmed] [2018-04-19T21:51:19,555][WARN][c.f.s.h.SearchGuardHttpServerTransport] [hostname] Someone (/[127.0.0.1:50448](http://127.0.0.1:50448)) speaks http plaintext [trimmed] Here’s what I’ve got added to the log4j2.properties: [logger.searchguard.name](http://logger.searchguard.name) = com.floragunn logger.searchguard.level = warn logger.searchguard.appenderRef.deprecation\_rolling.ref = searchguard\_rolling logger.searchguard.additivity = false appender.searchguard\_rolling.type = RollingFile [appender.searchguard\_rolling.name](http://appender.searchguard_rolling.name) = searchguard\_rolling appender.searchguard\_rolling.fileName = ${sys:es.logs.base\_path}${sys:file.separator}${sys:es.logs.cluster\_name}\_searchguard.log appender.searchguard\_rolling.layout.type = PatternLayout appender.searchguard\_rolling.layout.pattern = [%d{ISO8601}][%-5p][%-25c{1.}] %marker%.-10000m%n appender.searchguard\_rolling.filePattern = ${sys:es.logs.base\_path}${sys:file.separator}${sys:es.logs.cluster\_name}\_searchguard-%i.log.gz appender.searchguard\_rolling.policies.type = Policies appender.searchguard\_rolling.policies.size.type = SizeBasedTriggeringPolicy appender.searchguard\_rolling.policies.size.size = 1GB appender.searchguard\_rolling.strategy.type = DefaultRolloverStrategy appender.searchguard\_rolling.strategy.max = 4 > **···** > > On Thu, Apr 19, 2018 at 3:34 PM, Jochen Kressin [jkressin@floragunn.com](mailto:jkressin@floragunn.com) wrote: > > > For an example you can refer to the Search Guard docs: > > > [https://docs.search-guard.com/latest/troubleshooting-tls](https://docs.search-guard.com/latest/troubleshooting-tls) > > > So basically you create a new logger and a new appender in your log4j2.properties file.The appender specifies the file name and location amongst other settings, and is connected to the actual logger via an appenderRef. For example, have a look at how the deprecation logger is defined. Just follow this pattern, and replace the “deprecation” with, for example, “searchguard”. The base packe for all SG relates classes is “com.floragunn”. > > > > > > [logger.deprecation.name](http://logger.deprecation.name) = org.elasticsearch.deprecation > > > logger.deprecation.level = warn > > > logger.deprecation.appenderRef.deprecation\_rolling.ref = deprecation\_rolling > > > logger.deprecation.additivity = false > > > > > > appender.deprecation\_rolling.type = RollingFile > > > [appender.deprecation\_rolling.name](http://appender.deprecation_rolling.name) = deprecation\_rolling > > > appender.deprecation\_rolling.fileName = ${sys:es.logs.base\_path}${sys:file.separator}${sys:es.logs.cluster\_name}\_deprecation.log > > > appender.deprecation\_rolling.layout.type = PatternLayout > > > appender.deprecation\_rolling.layout.pattern = [%d{ISO8601}][%-5p][%-25c{1.}] %marker%.-10000m%n > > > appender.deprecation\_rolling.filePattern = ${sys:es.logs.base\_path}${sys:file.separator}${sys:es.logs.cluster\_name}\_deprecation-%i.log.gz > > > appender.deprecation\_rolling.policies.type = Policies > > > appender.deprecation\_rolling.policies.size.type = SizeBasedTriggeringPolicy > > > appender.deprecation\_rolling.policies.size.size = 1GB > > > appender.deprecation\_rolling.strategy.type = DefaultRolloverStrategy > > > appender.deprecation\_rolling.strategy.max = 4 > > > > > > > > > `` > > > On Thursday, April 19, 2018 at 8:48:32 AM UTC-7, ch s wrote: > > > > > You don’t have any examples of integrating this with the existing elasticsearch log4j2 file? > > > > > > On April 19, 2018 10:45:12 AM CDT, SG [info@search-guard.com](mailto:info@search-guard.com) wrote: > > > > > > > ```auto > > > > of course you can do this. but as you said this is more log4j than SG related. > > > > All loggers for searchguard start with com.floragunn or sg_action_trace (for auditlogs you can configure the loggername yourself) > > > > So just route them into another file than the rest of the logs. > > > > > > > > > Am 19.04.2018 um 17:14 schrieb ch s : > > > > > > > > > > Anyone? If this isn't possible, that's fine, I'd just like to know. > > > > > > > > > > On Tuesday, April 17, 2018 at 11:09:56 AM UTC-5, ch s wrote: > > > > > I guess this is more of a log4j2 question than anything else, but we have a requirement to let another team have access to our elasticsearch logs (And by this, I mean the log file generated by the elasticsearch process controlled by log4j2.properties, not the documents that are inside the elasticsearch cluster itself). The only problem is that the logs for the searchguard process are combined with the regular elasticsearch process logs. Is there a way to separate the two so that we can put the searchguard logs into a different file than the one elasticsearch is using for its own logs? > > > > > > > > > > I did experiment with the auditlog, but that still doesn't capture the actual searchguard process logs. It works great for audit events though! > > > > > > > > > > I'm guessing this would require some changes to log4j2.properties, but understanding that file is completely foreign to me. > > > > > > > > > > Thanks! > > > > > > > > > > > > > > > * Search Guard and Elasticsearch version > > > > > SG 5.6.7, ES 5.6.7 > > > > > > > > > > * Installed and used enterprise modules, if any > > > > > Auditlog > > > > > > > > > > > > > > > > > > > > -- > > > > > You received this message because you are subscribed to the Google Groups "Search Guard Community Forum" group. > > > > > To unsubscribe from this group and stop receiving emails from it, send an email to search-guard+unsubscribe@googlegroups.com. > > > > > To post to this group, send email to search-guard@googlegroups.com. > > > > > To view this discussion on the web visit [https://groups.google.com/d/msgid/search-guard/341eaa26-3c07-4255-8f08-bfd60f78793c%40googlegroups.com.](https://groups.google.com/d/msgid/search-guard/341eaa26-3c07-4255-8f08-bfd60f78793c%40googlegroups.com.) > > > > > For more options, visit [https://groups.google.com/d/optout.](https://groups.google.com/d/optout.) > > > > > > > > ``` > > > – > > > > You received this message because you are subscribed to a topic in the Google Groups “Search Guard Community Forum” group. > > > > To unsubscribe from this topic, visit [https://groups.google.com/d/topic/search-guard/sJ9J3cci1Qw/unsubscribe](https://groups.google.com/d/topic/search-guard/sJ9J3cci1Qw/unsubscribe). > > > > To unsubscribe from this group and all its topics, send an email to [search-guard+unsubscribe@googlegroups.com](mailto:search-guard+unsubscribe@googlegroups.com). > > > > To post to this group, send email to [search-guard@googlegroups.com](mailto:search-guard@googlegroups.com). > > > > To view this discussion on the web visit [https://groups.google.com/d/msgid/search-guard/54e4bf58-d749-4d91-98d2-e90644af962b%40googlegroups.com](https://groups.google.com/d/msgid/search-guard/54e4bf58-d749-4d91-98d2-e90644af962b%40googlegroups.com?utm_medium=email&utm_source=footer). > > > > For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). ---
**Author:** ![searchguard\_google\_group](https://sea1.discourse-cdn.com/flex019/user_avatar/forum.search-guard.com/searchguard_google_group/32/462_2.png) [@searchguard\_google\_group](https://forum.search-guard.com/u/searchguard_google_group)\ **Post date:** [April 22, 2018, 11:57am UTC](https://forum.search-guard.com/t/would-like-to-separate-out-sg-logs-from-es-logs/877/7 "2018-04-22T11:57:10Z")
i guess you need to set logger.searchguard.level = ALL here > **···** > > > Am 19.04.2018 um 23:58 schrieb CHS \: > > > > Thanks for the tips. Looks like I've got it mostly working. Logs are now going to a separate logfile, but some logs are still being captured in the ES log file. > > > > For example (lines trimmed): > > [2018-04-19T21:42:20,491][WARN][c.f.d.a.l.b.LDAPAuthorizationBackend] Unable to connect to ldapserver due to[trimmed] > > [2018-04-19T21:42:20,492][ERROR][c.f.s.a.BackendRegistry] Problems retrieving roles for User [name=admin, roles=] [trimmed] > > [2018-04-19T21:51:19,555][WARN][c.f.s.h.SearchGuardHttpServerTransport] [hostname] Someone (/127.0.0.1:50448) speaks http plaintext [trimmed] > > > > Here's what I've got added to the log4j2.properties: > > > > logger.searchguard.name = com.floragunn > > logger.searchguard.level = warn > > logger.searchguard.appenderRef.deprecation\_rolling.ref = searchguard\_rolling > > logger.searchguard.additivity = false > > > > appender.searchguard\_rolling.type = RollingFile > > appender.searchguard\_rolling.name = searchguard\_rolling > > appender.searchguard\_rolling.fileName = ${sys:es.logs.base\_path}${sys:file.separator}${sys:es.logs.cluster\_name}\_searchguard.log > > appender.searchguard\_rolling.layout.type = PatternLayout > > appender.searchguard\_rolling.layout.pattern = [%d{ISO8601}][%-5p][%-25c{1.}] %marker%.-10000m%n > > appender.searchguard\_rolling.filePattern = ${sys:es.logs.base\_path}${sys:file.separator}${sys:es.logs.cluster\_name}\_searchguard-%i.log.gz > > appender.searchguard\_rolling.policies.type = Policies > > appender.searchguard\_rolling.policies.size.type = SizeBasedTriggeringPolicy > > appender.searchguard\_rolling.policies.size.size = 1GB > > appender.searchguard\_rolling.strategy.type = DefaultRolloverStrategy > > appender.searchguard\_rolling.strategy.max = 4 > > > > On Thu, Apr 19, 2018 at 3:34 PM, Jochen Kressin \ wrote: > > For an example you can refer to the Search Guard docs: > > > > [TLS help | Security for Elasticsearch | Search Guard](https://docs.search-guard.com/latest/troubleshooting-tls) > > > > So basically you create a new logger and a new appender in your log4j2.properties file.The appender specifies the file name and location amongst other settings, and is connected to the actual logger via an appenderRef. For example, have a look at how the deprecation logger is defined. Just follow this pattern, and replace the "deprecation" with, for example, "searchguard". The base packe for all SG relates classes is "com.floragunn". > > > > logger.deprecation.name = org.elasticsearch.deprecation > > logger.deprecation.level = warn > > logger.deprecation.appenderRef.deprecation\_rolling.ref = deprecation\_rolling > > logger.deprecation.additivity = false > > > > appender.deprecation\_rolling.type = RollingFile > > appender.deprecation\_rolling.name = deprecation\_rolling > > appender.deprecation\_rolling.fileName = ${sys:es.logs.base\_path}${sys:file.separator}${sys:es.logs.cluster\_name}\_deprecation.log > > appender.deprecation\_rolling.layout.type = PatternLayout > > appender.deprecation\_rolling.layout.pattern = [%d{ISO8601}][%-5p][%-25c{1.}] %marker%.-10000m%n > > appender.deprecation\_rolling.filePattern = ${sys:es.logs.base\_path}${sys:file.separator}${sys:es.logs.cluster\_name}\_deprecation-%i.log.gz > > appender.deprecation\_rolling.policies.type = Policies > > appender.deprecation\_rolling.policies.size.type = SizeBasedTriggeringPolicy > > appender.deprecation\_rolling.policies.size.size = 1GB > > appender.deprecation\_rolling.strategy.type = DefaultRolloverStrategy > > appender.deprecation\_rolling.strategy.max = 4 > > > > On Thursday, April 19, 2018 at 8:48:32 AM UTC-7, ch s wrote: > > You don't have any examples of integrating this with the existing elasticsearch log4j2 file? > > > > On April 19, 2018 10:45:12 AM CDT, SG \ wrote: > > of course you can do this. but as you said this is more log4j than SG related. > > All loggers for searchguard start with com.floragunn or sg\_action\_trace (for auditlogs you can configure the loggername yourself) > > So just route them into another file than the rest of the logs. > > > > Am 19.04.2018 um 17:14 schrieb ch s \: > > > > Anyone? If this isn't possible, that's fine, I'd just like to know. > > > > On Tuesday, April 17, 2018 at 11:09:56 AM UTC-5, ch s wrote: > > I guess this is more of a log4j2 question than anything else, but we have a requirement to let another team have access to our elasticsearch logs (And by this, I mean the log file generated by the elasticsearch process controlled by log4j2.properties, not the documents that are inside the elasticsearch cluster itself). The only problem is that the logs for the searchguard process are combined with the regular elasticsearch process logs. Is there a way to separate the two so that we can put the searchguard logs into a different file than the one elasticsearch is using for its own logs? > > > > I did experiment with the auditlog, but that still doesn't capture the actual searchguard process logs. It works great for audit events though! > > > > I'm guessing this would require some changes to log4j2.properties, but understanding that file is completely foreign to me. > > > > Thanks! > > > > \* Search Guard and Elasticsearch version > > SG 5.6.7, ES 5.6.7 > > > > \* Installed and used enterprise modules, if any > > Auditlog > > > > -- > > You received this message because you are subscribed to the Google Groups "Search Guard Community Forum" group. > > To unsubscribe from this group and stop receiving emails from it, send an email to search-guard+unsubscribe@googlegroups.com. > > To post to this group, send email to search-guard@googlegroups.com. > > To view this discussion on the web visit [https://groups.google.com/d/msgid/search-guard/341eaa26-3c07-4255-8f08-bfd60f78793c%40googlegroups.com\](https://groups.google.com/d/msgid/search-guard/341eaa26-3c07-4255-8f08-bfd60f78793c%40googlegroups.com%5C). > > For more options, visit [https://groups.google.com/d/optout\](https://groups.google.com/d/optout%5C). > > > > -- > > You received this message because you are subscribed to a topic in the Google Groups "Search Guard Community Forum" group. > > To unsubscribe from this topic, visit [https://groups.google.com/d/topic/search-guard/sJ9J3cci1Qw/unsubscribe\](https://groups.google.com/d/topic/search-guard/sJ9J3cci1Qw/unsubscribe%5C). > > To unsubscribe from this group and all its topics, send an email to search-guard+unsubscribe@googlegroups.com. > > To post to this group, send email to search-guard@googlegroups.com. > > To view this discussion on the web visit [https://groups.google.com/d/msgid/search-guard/54e4bf58-d749-4d91-98d2-e90644af962b%40googlegroups.com\](https://groups.google.com/d/msgid/search-guard/54e4bf58-d749-4d91-98d2-e90644af962b%40googlegroups.com%5C). > > For more options, visit [https://groups.google.com/d/optout\](https://groups.google.com/d/optout%5C). > > > > -- > > You received this message because you are subscribed to the Google Groups "Search Guard Community Forum" group. > > To unsubscribe from this group and stop receiving emails from it, send an email to search-guard+unsubscribe@googlegroups.com. > > To post to this group, send email to search-guard@googlegroups.com. > > To view this discussion on the web visit [https://groups.google.com/d/msgid/search-guard/CALY-9dJR01e79dJgHeUdV1MJekg\_bUY5XK%2BDq%2BFeRSbTLOcySQ%40mail.gmail.com\](https://groups.google.com/d/msgid/search-guard/CALY-9dJR01e79dJgHeUdV1MJekg_bUY5XK%2BDq%2BFeRSbTLOcySQ%40mail.gmail.com%5C). > > For more options, visit [https://groups.google.com/d/optout\](https://groups.google.com/d/optout%5C).