作者回复: log是文本日志。metrics一般是数据点，也称时间序列（time series），格式如(value, timestamp)，比方说CPU的使用率，某个API的单位时间调用次数，都是可以数字化的，并且可以定时记录起来，就形成了一串的时间序列数据，这些时间序列可以存起来，而且可以在像grafana这样的工具中进行分析展示。metrics可以认为是一种特殊的日志，使用特殊的方式存储。当前log一般存elasticsearch分布式搜索引擎，metrics一般存时间序列数据库（例如opentsdb, influxDB等）。log一般是用在调试和Trouble Shooting等场景，metrics一般用在系统和应用性能监控场景，或者是业务数据分析等场景。log数据可以进一步分析产生出metrics来。

作者回复: 不错很强👍

作者回复: 日志监控一定要有，用ELK收集应用日志，方便排查错误和性能问题，其它监控可暂缓

作者回复: 不能脱离场景，单纯讲某个监控产品的好坏。zabbix是老牌的监控产品，目前还是业界运维监控的一个主流产品，这个产品主要偏运维层的监控，但对大规模应用层和业务层的监控的能力比较欠缺，所以一般需要和ELK/Prometheus/CAT等监控产品配合互补，才能构成完整的监控体系。

作者回复: 考虑维护成本，能共享尽量共享。但是共享也有问题，一个是量大性能会有问题，另外团队之间需求不同可能会打架，所以视情况各个团队也可以搞两套以上，但是尽量避免每个团队都搞一套就太浪费了。

作者回复: 我在网上简单搜了一下，貌似pinpoint/skywalking的架构都没有直接支持kafka这样的mq做中转。zipkin应该是支持的，但是zipkin的报表能力不行。如果这是你们企业的强需求，建议研究下pinpoint的通讯协议，然后做一下定制扩展，支持mq中转，我想这个工作量不会很大。

作者回复: 当然可以扛住，只是集群容量规模问题。HBase/ELK这些大数据产品就是为应对海量数据而生，集群容量可大可大，大公司一天几T甚至几十T数据都很正常。

作者回复: 日志监控一般要有，然后是metrics和告警逐步完善，到一定规模上调用链

作者回复: 监控数据处理中延迟和吞吐(throughput)是一对矛盾，要快速低延迟就会牺牲吞吐量，要高吞吐就要适当做batch导致高延迟，没有完美解决办法，需要权衡，一般在可接受延迟下尽量提高吞吐量(单位时间内发送的数据量)，而不是追求单条监控数据的低延迟。