运维必看：日志标准化必须面对的 4 类问题( 二 ) _日志标准化

比较理想的解析方式是预解析和后解析相结合，目前市场上只有少量产品支持这种特性。这种特性结合了两者的优点，缺点又相对能接受，可以达到一个比较好的平衡。但这种方式为什么市场上用的少呢？据我分析，主要的原因是这种模式过于复杂。
首先是操作复杂，这种模式要求使用者掌握一些相关技能；其次是技术复杂，目前应用较广的大数据平台技术，对关联查询的支持不是特别理想，比如Elasticsearch目前对关联查询就非常繁琐。但是这种预解析和后解析相结合的方式在应用上优势明显，是日志解析未来的发展趋势。
其他问题可以通过特殊手段来解决，比如：可以把繁琐的操作封装在产品中，隐藏在操作的后台；如果用关系数据库，倒是容易解决后处理的问题，但是多数关系数据库的处理能力和目前的大数据平台还是有较大差距，可以在日志数量不大的时候使用。

文章插图

2.2 自定义解析的灵活性通过前面的分析得知，日志标准化解析在这类产品中的地位举足轻重。如何把日志解析的能力提供出来，就显得尤为重要，目前自定义解析的方式主要有几种方式：

通过编码实现。直接在代码中处理，编译发布，这种方式对厂家来说最灵活，但对使用者来说最麻烦，因为几乎没有办法进行调整；
通过配置文件实现。比如logstash中配置input，filter，output等，这种方式解决了用户不能直接调整的问题，非常方便。但这种情况只能登录后台查看配置文件，如果安装的比较多，调整修改起来会稍显繁琐；
通过工具生成。比如之前版本的symantec的ssim平台，通过他们提供的工具实现进行配置，继而导出他们产品能识别的安装包，最后安装到平台中。这种方式本质上是前面两种解析方式的结合，比较灵活。唯一的缺点，是解析查看的时候需要借助工具，如果有修改或者添加的操作，需要重新部署一遍；
通过脚本实现。脚本实现其实可以归于编码实现的一个特例，只是大多数脚本不用编译，可以直接运行。这种解析方式的优点是比较灵活，缺点是对使用者要求较高，同样调整修改起来较为麻烦；
通过界面配置的方式实现。就是在平台上直接进行配置，比如splunk、secilog等，这种方式的优点是比较灵活，从界面上配置非常方便。