# Can I hide or print shorter version of elasticsearch errors and warnings in the log file? **URL:** \ **Category:** Elasticsearch\ **Created:** [April 2, 2019, 7:51am UTC](https://discuss.elastic.co/t/can-i-hide-or-print-shorter-version-of-elasticsearch-errors-and-warnings-in-the-log-file/174932 "2019-04-02T07:51:13Z")\ **Posts on this page:** 3\ **Page:** 1
**Author:** ![yishain11](https://avatars.discourse-cdn.com/v4/letter/y/df705f/32.png) [@yishain11](https://discuss.elastic.co/u/yishain11)\ **Post date:** [April 2, 2019, 7:51am UTC](https://discuss.elastic.co/t/can-i-hide-or-print-shorter-version-of-elasticsearch-errors-and-warnings-in-the-log-file/174932/1 "2019-04-02T07:51:13Z")
Is there's a way to hide specific error messages in elasticsearch's log? or at least to show a shorter version? I have a cycle of delete by query requests, even is there is no indices currently, so I see the "no such index" warning alot in my log, and this warning fills my logs (and memory). this is the full warning: ``` [2019-03-06T14:26:11,675][WARN][o.e.i.r.TransportDeleteByQueryAction] [fvZI_Vz] giving up on search because it failed with a non-retryable exception org.elasticsearch.index.IndexNotFoundException: no such index at org.elasticsearch.cluster.metadata.IndexNameExpressionResolver$WildcardExpressionResolver.indexNotFoundException(IndexNameExpressionResolver.java:678) ~[elasticsearch-6.2.1.jar:6.2.1] at org.elasticsearch.cluster.metadata.IndexNameExpressionResolver$WildcardExpressionResolver.innerResolve(IndexNameExpressionResolver.java:630) ~[elasticsearch-6.2.1.jar:6.2.1] at org.elasticsearch.cluster.metadata.IndexNameExpressionResolver$WildcardExpressionResolver.resolve(IndexNameExpressionResolver.java:586) ~[elasticsearch-6.2.1.jar:6.2.1] at org.elasticsearch.cluster.metadata.IndexNameExpressionResolver.concreteIndices(IndexNameExpressionResolver.java:164) ~[elasticsearch-6.2.1.jar:6.2.1] at org.elasticsearch.cluster.metadata.IndexNameExpressionResolver.concreteIndices(IndexNameExpressionResolver.java:139) ~[elasticsearch-6.2.1.jar:6.2.1] at org.elasticsearch.action.search.TransportSearchAction.executeSearch(TransportSearchAction.java:294) ~[elasticsearch-6.2.1.jar:6.2.1] at org.elasticsearch.action.search.TransportSearchAction.lambda$doExecute$4(TransportSearchAction.java:193) ~[elasticsearch-6.2.1.jar:6.2.1] at org.elasticsearch.action.ActionListener$1.onResponse(ActionListener.java:60) ~[elasticsearch-6.2.1.jar:6.2.1] at org.elasticsearch.index.query.Rewriteable.rewriteAndFetch(Rewriteable.java:113) ~[elasticsearch-6.2.1.jar:6.2.1] at org.elasticsearch.index.query.Rewriteable.rewriteAndFetch(Rewriteable.java:86) ~[elasticsearch-6.2.1.jar:6.2.1] at org.elasticsearch.action.search.TransportSearchAction.doExecute(TransportSearchAction.java:215) ~[elasticsearch-6.2.1.jar:6.2.1] at org.elasticsearch.client.support.AbstractClient.execute(AbstractClient.java:405) ~[elasticsearch-6.2.1.jar:6.2.1] at org.elasticsearch.client.support.AbstractClient.search(AbstractClient.java:532) ~[elasticsearch-6.2.1.jar:6.2.1] at org.elasticsearch.index.reindex.ClientScrollableHitSource.lambda$doStart$0(ClientScrollableHitSource.java:79) ~[elasticsearch-6.2.1.jar:6.2.1] at org.elasticsearch.index.reindex.ClientScrollableHitSource$1RetryHelper.doRun(ClientScrollableHitSource.java:144) ~[elasticsearch-6.2.1.jar:6.2.1] at org.elasticsearch.action.support.TransportAction$RequestFilterChain.proceed(TransportAction.java:167) ~[elasticsearch-6.2.1.jar:6.2.1] at org.elasticsearch.action.support.TransportAction.execute(TransportAction.java:139) ~[elasticsearch-6.2.1.jar:6.2.1] at org.elasticsearch.action.support.TransportAction.execute(TransportAction.java:81) ~[elasticsearch-6.2.1.jar:6.2.1] at org.elasticsearch.client.node.NodeClient.executeLocally(NodeClient.java:83) ~[elasticsearch-6.2.1.jar:6.2.1] at org.elasticsearch.index.reindex.AbstractBaseReindexRestHandler.lambda$doPrepareRequest$0(AbstractBaseReindexRestHandler.java:63) ~[?:?] at org.elasticsearch.rest.BaseRestHandler.handleRequest(BaseRestHandler.java:97) [elasticsearch-6.2.1.jar:6.2.1] at org.elasticsearch.rest.RestController.dispatchRequest(RestController.java:240) [elasticsearch-6.2.1.jar:6.2.1] at org.elasticsearch.rest.RestController.tryAllHandlers(RestController.java:336) [elasticsearch-6.2.1.jar:6.2.1] at org.elasticsearch.rest.RestController.dispatchRequest(RestController.java:174) [elasticsearch-6.2.1.jar:6.2.1] at org.elasticsearch.http.netty4.Netty4HttpServerTransport.dispatchRequest(Netty4HttpServerTransport.java:500) [transport-netty4-6.2.1.jar:6.2.1] at org.elasticsearch.http.netty4.Netty4HttpRequestHandler.channelRead0(Netty4HttpRequestHandler.java:80) [transport-netty4-6.2.1.jar:6.2.1] ``` ... for even more lines. as you can see, its pretty long. Since I'm not phased by this warning, and don't, in fact, need to see it at all, is there a way to configure elasticsearch to hide this message? Or at least to show the error/warning itself and not the entire java stack errors? ---
**Author:** ![DavidTurner](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/davidturner/32/22453_2.png) [@DavidTurner](https://discuss.elastic.co/u/DavidTurner)\ **Post date:** [April 2, 2019, 10:43am UTC](https://discuss.elastic.co/t/can-i-hide-or-print-shorter-version-of-elasticsearch-errors-and-warnings-in-the-log-file/174932/2 "2019-04-02T10:43:38Z")
> [@yishain11](#): > > is there a way to configure elasticsearch to hide this message? The best way is: stop trying to delete documents from indices that don't exist 😉 It's easy enough to [check if they exist first](https://www.elastic.co/guide/en/elasticsearch/reference/6.7/indices-exists.html). Stack traces are absolutely vital when trying to diagnose a problem. I don't think there's a way to hide them. ---
**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\ **Post date:** [April 30, 2019, 10:43am UTC](https://discuss.elastic.co/t/can-i-hide-or-print-shorter-version-of-elasticsearch-errors-and-warnings-in-the-log-file/174932/3 "2019-04-30T10:43:40Z")
This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.