前言
我一直负责公司的 nginx 日志收集，现在每天的 pv 数在10亿级别，存储大概1T（*2 默认的 elasticsearch 5分片2副本）不到，因为开始的时候 nginx 日志也是逐渐收集的，因为是第一次做问题也比较多，想着等着我们的 ELK 平台成熟了再接应用的日志。
当前的问题
如果说现在开发看日志痛点的话其实就是那种线上实例多的应用，如果只有一两个其实开发登录到服务器上看日志也还好。但是有的应用线上有30多个实例，如果有问题只能找我们运维用 ansible 这种工具批量查下也比较低效，不过那种情况也比较少。
日志如果收集的话，我初步估算了一下如果都收集的话，每天大概要5T，可能还要多，主要是线上日志打的种类多，量也大，我们有的应用一个实例一天能打20G的日志，还有的应用一报错一天200多G的错误日志，感觉收集的话这都是问题。
初期的思考
开始的时候问过从别的公司新入职的同事，有的说可以只收集应用间调用的日志，因为一般出问题都是应用间调用的问题，如果从应用间调用查不出问题来，那么在登录到机器上看日志，其实从成本效益来分析这么做还可以但是既然应用需要打日志就说明日志是有价值的，需要查看的，还有就是 elasticsearch 的全文搜索真的很好用，开发查日志的体验可以得到很高的提升。不过量真的很大，感觉这个成本会很高，而且目前没有开发和我们运维反馈过看日志是痛点，所以迟迟没有做。
还有一个很重要的原因就是应用日志格式的问题，我比较倾向于 Pinterest 在一次分享中提到的日志格式要求：
对每个编程语言，定制输出日志的函数库
统一格式为JSON• 强制输出丰富的上下文信息
id: string // mandatory; globally unique to identify a log record. It can be a structure with timestamp.
timestamp: date // mandatory; when the log records are created.
service: string // uniquely identify a service which generates the log record.
project: string // or organization so that we can teams can be associated with
host: string // name of the host creating the log
env: string // deployment env
stage: string // deployment stage
version: string // git commit number
tags: { } // labels consisting of key value pair assuming both key and values are strings for expansion by clients. This can include locale or organization and so on.
payload_encoding: string // can be either string, JSON, base64 encoded binary format and so on. string by default
payload : // mandatory上面的日志规范，我的想法就是 timestamp 不如 time ios8601 的格式可读性高。但是规范这种东西，大家都没开始做之前好推，一旦都系统都运行了好久，你让他们改，这个难度做过的人都知道。（我记得名人名言类似是这个意思：我们喜欢改善，不喜欢改变）
转折点
上次看 架构真经 ，再看到那个先利其器关于日志收集的时候，有种眼前一亮的感觉，有几句话我觉得说的挺好的：
必须牢记日志是有代价的，这不仅包括保持额外数据的成本，往往也包括事物处理响应时间的代价。必须要注意日志的成本，无论记录多少日志还是保存多少数据，都要做出符合成本效益的决策。
还有一点和日志关系不大但是是这一章的最后忠告，我觉得很有共鸣：
引进每项技术都需要另外的一种技能来支持，尽管工作中使用合适的工具很重要，但是不要过度强调专业化，以至于没有合适的技能深度来支持。
看过这个之后我觉得针对量大的问题应用日志可以逐渐的收集，来看看我们一共需要付出多大的成本。只要做好成本效益分析，逐渐把日志收集起来，我觉得事情应该没有想象中的那么难。
还有就是在看过 企业IT架构转型之道：阿里巴巴中台战略思想与架构实战 这本书的第七章之后，了解到应用日志可以只收集一部分，也能发现问题，而且这样还能减少服务器的 io 压力。
新的思路
就是针对应用日志不全收集的方案，之前看过 thoughtwork 的技术雷达上写过，现在微服务盛行的大环境下，应用日志收集是一个很大的挑战，如果只收集一部分有时候可能丢掉了重要的信息，log level per request 可以考虑，但是我觉得这种方案，我从谷歌上都搜索不到太多资料，而且驾驭难度感觉比较大，业界应该也没有太成熟的解决方案。只收集一部分日志（具体可以看阿里中台那本书的7.5节），我的初步想法是如果我们只收集 UID 取余 10 真等于 9 的日志（也可以用别的算法，具体情况具体分析吧），这样我们日志量就可以减少90%。
还有一个就是权责的问题，因为好多时候开发加日志都是因为线上有问题他们找不出来，所以需要更详细的日志，但是这样下去线上日志就是有增无减，因为他们只负责解决问题，线上服务器的 io 压力， 日志保存的成本等等都在我们运维这边，我觉得这就是权责的不对等，如果能有种方式让开发不仅承担日志增加的利，也能让他们承担日志增加的弊，我觉得情况应该能有很大改善。关于这个问题，其实可以看看这篇网易云刘超老师的文章传统行业转型微服务的挖坑与填坑，如果能发展到第三阶段“谁开发，谁运维”，那就皆大欢喜了O(∩_∩)O~。