图7：ELK on Mesos
上图7是ELK on Mesos结构图，也是团队的无奈之选。因为Mesos还暂时不支持multi-role framework功能，所以选择了这种折中的方式来做。在一个Marathon里，根据业务线设置好Quota后，用业务线重新发一个新的Marathon接入进去。对于多租户来讲，可以利用Kubernetes做后续的资源管控和资源申请。
部署ES以后，有一个关于服务发现的问题，可以去注册一个callback，Marathon会返回信息，解析出master/slave进程所在的机器和端口，配合修改Haproxy做一层转发，相当于把后端整个TCP的连接都做一个通路。ES跟Spark不完全相同，Spark传输本身流量就比较大，而ES启动时需要主动联系Master地址，再通过Master获取相应集群，后面再做P2P，流量比较低，也不是一个长链接。
监控与运维
这部分包括了Streaming监控指标与报警、容器监控指标与报警两方面。
Streaming监控指标与报警
Streaming监控含拓扑监控和业务监控两部分。
1.Streaming拓扑监控
2.业务监控
（1）Kafka Topic Lag
（2）处理延迟mean90/upper90
（3）Spark scheduler delay/process delay
（4）Search Count/Message Count
（5）Reject/Exception
（6）JVM
拓扑监控包括数据源和整个拓扑流程，需要用户自己去整理和构建，更新的时候就能够知道这个东西依赖谁、是否依赖线上服务，如果中途停的话会造成机器故障。业务监控的话，第一个就是Topic Lag，Topic Lag每一个波动都是不一样的，用这种方式监控会频繁报警，90%的中位数都是落在80—100毫秒范围内，就可以监控到整个范围。
容器监控指标与报警
容器监控上关注以下三方面：
1.Google cAdvisor足够有效
mount rootfs可能导致容器删除失败 #771
–docker_only
–docker_env_metadata_whitelist
2.Statsd + Watcher
基于Graphite的千万级指标监控平台
3.Nagios
容器这一块比较简单，利用Docker并配合Mesos，再把Marathon的ID抓取出来就可以了。我们这边在实践的过程发现一个问题，因为Statsd Watcher容易出现问题，你直接用Docker的时候它会报一些错误出来，这个问题就是Statsd Watcher把路径给挂了的原因。目前我们平台就曾遇到过一次，社区里面也有人曝，不过复现率比较低。用的时候如果发现这个问题把Statsd Watcher直接停掉就好。指标的话，每台机器上放一个statsd再发一个后台的Worker，报警平台也是这个。
其实针对Docker监控的话，还是存在着一些问题：
1.基础监控压力
（1）数据膨胀
（2）垃圾指标增多
（3）大量的通配符导致数据库压力较高
2.单个任务的容器生命周期
(1）发布
(2)扩容
(3)异常退出
首先主要是监控系统压力比较大。原来监控虚拟机时都是针对每一个虚拟机的，只要虚拟机不删的话是长期汇报，指标名固定，但在容器中这个东西一直在变，它在这套体系下用指标并在本地之外建一个目录存文件，所以在这种存储机制下去存容器的指标不合适。主要问题是数据膨胀比较厉害，可能一个容器会起名，起名多次之后，在Graphite那边对应了有十多个指标，像这种都是预生成的监控文件。比如说定义每一秒钟一个数据点，要保存一年，这个时候它就会根据每年有多少秒生成一个RRD文件放那儿。这部分指标如果按照现有标准的话，可能容器的生命周期仅有几天时间，不适用这种机制。测试相同的指标量，公司存储的方式相对来说比Graphite好一点。因为Graphite是基于文件系统来做的，第一个优化指标名，目录要转存到数据库里做一些索引加速和查询，但是因为容器这边相对通配符比较多，不能直接得知具体对应的ID，只能通配符查询做聚合。因为长期的通配符在字符串的索引上还是易于使用的，所以现在算是折中的做法，把一些常用的查询结果、目录放到里边。
另一个是容器的生命周期。可以做一些审计或者变更的版本，在Mesos层面基于Marathon去监控，发现这些状态后打上标记：当前是哪一个容器或者哪一个TASK出了问题，对应扩容和记录下来。还有Docker自己的问题，这样后面做整个记录时会有一份相对比较完整的TASK-ID。
作者简介：徐磊，去哪儿网平台事业部运维开发工程师。