日志的持久化方式的选择以及选择什么工具进行日志的分析和展现？

整体上涉及容器平台应用日志管理规范
1、应用日志和中间件日志的日志路径均进行规范化配置
2、容器启动挂载卷，应用日志和中间件日志均规范化输出至日志挂载卷
3、挂载卷：1）存储分散管理，容器挂载SLAVE节点的磁盘卷，由于容器重启后漂移，节点管理困难；2）存储集中管理，各SLAVE节点挂载分布式存储提供存储集中管理，容器挂载集中管理的卷，应用日志和中间件日志可集中化管理，方便查询和采集等处理
4、日志采集：可以采用ELK Stack的filebeat进行文件采集（不建议使用logstash采集），或者使用fluentd进行文件采集；改造日志库（如logback，增加KAFKA appender）将日志直接对接输出至kafka。
5、消息队列：一般采用kafka
6、数据存储：ES，ES需进行安全控制
7、数据展现：Kibana功能强大，但是存在权限控制、数据脱敏等功能不全问题，建议进行二次开发，或自研Portal实现数据展现、数据分析、安全管控等功能。
8、实时处理：基于spark进行日志实时处理，并对接监控告警平台，实现监控+日志的立体化监控

上面的问题先考虑一下数据量，感觉不考虑数据量就是在耍流氓。
持久化简单，将日志吐到一个挂载点即可，当然也可以通过修改代码直接使用sysLog方式来做
但是涉及到分析和展现那问题就比较多了。
分析需要确保数据完整，如果数据不完整那分析也就无意义。

1. 架构如何设计
2. 采集端如何保证数据不会丢失、发送及时、消耗资源低。
3. 数据入库是否迅速
4. 是否有强大的语句指令去分析数据
5. 至于到了展现阶段基本上就看各个公司的实际的情况了。
   针对上面问题常用的也就下面几个：
   ELK
   日志易
   splunk

如果说自己的日志量比较小，自己手底下人员动手能力强，那就选ELK，或者EFK搞就行了。没必要花钱去购买splunk/日志易。

但是数据量上来之后，建议购买成熟厂家的产品，因为那时候的维护就让你头疼（还不算硬件资源

如果自己对自己的ELK系统可靠性很有信心，或者应用的日志重要级别并不高，建议容器日志直接通过stdout输出到ELK。如果上述两点不能满足，需要考虑用PVC承载应用日志。最麻烦的是既要写入PVC，还要将PVC的日志抓取发往ELK。这种场景会有很多坑，可以考虑在应用容器旁边旁挂日志收集容器的方式。

日志分析平台采用ELK Stack搭建，ELK Stack是Elastic的三个开源产品Elasticsearch，Logstash和Kibana的集合。Logstash负责数据收集、传输、预处理。Elasticsearch负责数据存储、分析。Kibana负责数据展现。这三者的有机结合为银行运维日志管理与日志分析提供了完整的解决方案。