Case: of the Missing logs
I was debugging a curious case of my Elasticsearch instance on my vagrant dev box going to RED state every night at 00:00:00. Consistently as far back as I can remember.
Right the obvious thing to do is look at the logs right? Except for this set of rotated logs there are no lines between 23:40hrs to 00:00:05. Not in the current un-rotated log or the previous set.
At First Pass:
- Elasticsearch rotates its own log. Could it be this process causing the missing Elasticsearch log lines?
- Marvel Creates new daily indices at 00:00:00. Could it be this causing the missing Elasticsearch log lines?
What was the real was causing the missing logs
Well By default Elasticsearch uses log4j. However, instead of the standard log4j.property file you get with log4j Elasticsearch is using a translated format to YAML format excluding all of the log4j pre-fix giveaways. Another closer look at the configuration lead to the curious investigation of the type of rolling appender ; DailyRollingFile. This lead to this revelation :
DailyRollingFileAppender extends FileAppender so that the underlying file is rolled over at a user chosen frequency. DailyRollingFileAppender has been observed to exhibit synchronization issues and data loss. The log4j extras companion includes alternatives which should be considered for new deployments and which are discussed in the documentation for org.apache.log4j.rolling.RollingFileAppender.
Source : Apache’s DailyRollingFileAppender Documentation
Missing Elastic logs Root Cause:
The sync issue with the DailyRollingFileAppender must be the cause to the missing Elasticsearch log lines around midnight.
Missing Elastic logs fix:
Use a log4j alternatives to DailyRollingFileAppender. In this case a RollingFileAppender, changing my rolling strategy to roll my logs when they reach a certain file size. Replace DailyRollingFileAppender with RollingFileAppender and removing the datePattern which was for the DailyRollingFileAppender.
Example:
[code language=”bash”]
file:
type: rollingFile
file: ${path.logs}/${cluster.name}.log
maxFileSize: 10000000
maxBackupIndex: 10
layout:
type: pattern
conversionPattern: "[%d{ISO8601}][%-5p][%-25c] %m%n"
[/code]
Note: YAML is particular about tabs!
Happy Ending
Marvel turns out to be the cause of the my Elasticsearch cluster going into RED state at mid-night on new .Marvel*** Index creation. Which makes sense as there will be a few milliseconds-seconds when this new index will have been created with shards, replicas etc missing.
Leave a Reply