MapperParsingException is logged at DEBUG?

While doing some bulk indexing we see MapperParsingException in the logs. But these are logged at DEBUG level. Is that on purpose? Shouldn't these be ERROR? (From our application's perspective a mapping failure is indeed an ERROR.) Is there any way to change the level for these exceptions?

es 2.3.3

Can you please post those exceptions that you see in the logs? Do you get back an error in the response? If you are using bulk you should be checking all the items in the response, as the response code is always 200.

Let's see what exceptions they are and then define whether you should be worried or not :wink:

Here is a different exception logged at DEBUG. This was just before a message of "[s-elasticsearch-data-8] stopping ..." where the data node stopped (itself?)

[connect-kennametal-kmnewalbany-mtconnectdataitems-201607][[connect-kennametal-kmnewalbany-mtconnectdataitems-201607][0]] IllegalIndexShardStateException[CurrentState[STARTED] shard is not a primary]
	at org.elasticsearch.index.shard.IndexShard.prepareIndexOnPrimary(
	at org.elasticsearch.action.index.TransportIndexAction.prepareIndexOperationOnPrimary(
	at org.elasticsearch.action.index.TransportIndexAction.executeIndexRequestOnPrimary(
	at org.elasticsearch.action.bulk.TransportShardBulkAction.shardIndexOperation(
	at org.elasticsearch.action.bulk.TransportShardBulkAction.shardOperationOnPrimary(
	at org.elasticsearch.action.bulk.TransportShardBulkAction.shardOperationOnPrimary(
	at org.elasticsearch.transport.RequestHandlerRegistry.processMessageReceived(
	at org.elasticsearch.transport.TransportService$4.doRun(
	at java.util.concurrent.ThreadPoolExecutor.runWorker(
	at java.util.concurrent.ThreadPoolExecutor$

And we do check all the bulk request return status in the client. These logs/exceptions are all from the actual elasticsearch nodes themselves.