生态体系落地过程中的选型和踩坑

。

业务监控和调用链监控更多的取决于业务开发部门的选型，如skywalking等。

容器环境下，指标监控非Prometheus莫属，通过Service Discovery机制中的Kubernetes plugin获得scrape路径，之后的链路就比较通畅了。

使用Prometheus过程中一个绕不开的问题是持久化存储，WAL中保存的数据不宜过多，否则内存和加载速度都会产生很大问题，官方支持的remote read/write列表中，我们考查了InfluxDB和TiDB这两个，实践中两者占用的内存都非常大，建议在集群外的物理机中进行部署，如果使用InfluxDB，如果集群中Pod创建频繁(例如使用了cronjob)可能会触发key数量限制。

日志

日志分为两种：std系列日志和文件日志，它们的区别主要在于收集方式不同，一般来说，收集上来的日志都会并进入ELK体系，后面的处理就都差不多了。

std系列日志因其属于Linux模型，可以统一从Docker数据目录中予以收集，一种部署方式是使用DaemonSet部署Fluentd并挂载hostPath。

文件形态的日志略显复杂，NFS/CephFS等分布式存储肯定不适合存放日志，我们通过emptyDir形式实现目录共享，然后新增filebeat sidecar对共享目录中的日志文件进行收集，入ELK体系。

如何与持续交付对接

这里我们关注持续交付部署部分的方案，Kubernetes的部署本质上就是不同类型的资源对象以yaml格式应用，在自研与使用开源方案之间，我们选用了Helm作为部署阶段中，持续交付与Kubernetes的沟通桥梁。通过Helm我们可以把部署配置变成一个JSON对象，辅以标准化的部署模版，实现部署的标准化，同时自带了资源状态监测，应用管理等功能。

作为一个toB性质的服务，我们不应该只关注服务本身的可用性和性能，更应该从最终用户体验维度进行自查改进。例如Kubernetes官方的Benchmark工具中提到Pod平均启动时间，但是对项目来说更加关注的是Pod平均ready时间，而探针的结果是受到项目依赖，数据库等因素的影响的。对于特定项目，很多数值是稳定的，我们可以在报警系统中进行一些统计学方面的处理。

（编辑：信阳站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!