大家下午好,我是来自elastic的社区技术布道师刘征。Elastic Stack不只是日志,还能给你的还有更多精彩的解决方案。Elasticsearch是自带搜索和分析查询功能,也是巨大的存储服务,并且可以无限扩展,它可以衍生出许多解决方案,解决方案的周边模块是自由组合搭配的。
如Logstash是数据摄入模块,是服务器端的数据处理管道。Beats是主机上的文件摄入代理程序,Kibana能让用户使用图形和图表的方式对Elasticsearch中存储的数据进行可视化展示,它定位为是数据操控的的IDE,能发挥数据的所有潜能,还是整个Elastic Stack的控制台。
1、云原生应用的主要特征,它在系统可运维方面的挑战
云原生应用有三个显著的特点:应用架构方面,从单体应用向微服务过渡,应用架构逐渐过渡为松耦合系统,应用版本的迭代更快、周期更短;基础设施方面,拥抱容器化基础设施、应用自身变得更快更轻,Kubernetes目前已经成为了事实标准;从应用生命周期来看,DevOps流水线持续部署,让服务变更低成本,呈现高频率和全自动变更流程。
微服务应用和传统单体应用相比,在重大的运维事件方面,微服务应用的特点主要呈现为如下几点:从运维部署的复杂度来看,微服务需要借助自动化配置管理工具和Docker完成,具有更高的复杂度;扩展性方面,微服务应用速度更快,可以按需扩展,有更高的资源利用率;回滚/故障隔离更快、更方便;最后一点,服务的变更周期短,船小好调头。
2、可观测性是新生事物还是老生常谈,它的真实本质
在微服务架构下,可观测性显得非常重要。云原生应用意味着,应用部署到生产系统,可能才只是刚刚开始。
监控告诉我们系统的哪些部分是工作的。而可观测性告诉我们:哪个部分是为何不工作的。我们希望通过Elastic Stack技术栈实现可观测性。监控是最基础的时间,上面两部分告警Alerting和概况Overview是运维人员使用的工作内容,而可观测性需要不同的信号量在各个层次的支持,向下还包含了那些更复杂部分,排错Debugging信息、剖析Profiling信息、服务依赖分析dependency信息。只有使用了用了更全面的信号量后,才能说拥有了可观测性。
3、分层构建云原生应用系统的可观测性,四步法破解难题
可观测性有三根支柱:日志、指标和应用追踪。分层级构建可观测性的方法,不仅适用于云原生应用的可观测性建设,也适用于其他应用,四步法的顺序是:健康检查、指标、日志、应用追踪。
Level 0 健康检查
首先来看Level 0级的健康检查,Elastic Stack提供了服务运行状态检查的红绿灯系统,从三方面检查健康度:是否在运行中?能处理它的工作么?能处理更多工作量么?实施健康检查有三种模式:1)广播:将状态信息封包,发送到网络上,更新自己和邻居的状态;2)注册表:服务的ip/域名的端口信息,写入/更新到etcd或Zk,实时更新服务清单;3)暴露:利用服务默认的服务端口,编写应用特有的健康服务,等待外部工具的轮询。
在通常情况下,现在的开箱即用工具是不一定能实现所有希望检查的参数的。如果没有任何一个现成可用的工具,能检查所期望的应用自身健康度指标,那么就需要在应用里面做开发,这开发比较简单,给应用添加一个健康检查的接入点,然后通过返回代码表示应用的基本概况,比如自身是否健康,和依赖服务Cassandra数据库连接有无问题,有没有连接依赖的服务。这不是现成工具能帮你做到的,不必须在开发中,把它当做一个feature去开发。
前面我们讲了三种实现模式,你需要有一种工具和架构帮你去实施,现在Elastic HeatBeat就是这样的工具,HeatBeat的探针可以在内网部署,如果是内部的一些service,可以在内部的监控服务器上部署HeatBeat,也可以用容器的方式去部署它。同时它也可以部署在外网,外网可能有很多的意义,由于你的服务可能是一个对外To C的服务。
当部署完毕后,可以在ELK的Kibana里边浏览服务状态,探针会把服务状态信息传送到Elasticsearch里面。Elasticsearch里的Heatbeat功能内置了所有必要的监控监控面板,甚至还内置了一些机器学习的作业。可以从不同service的健康度指标监控,可以进入到机器学习的分析作业里面。
Level 1 指标
当有了第一步Level 0的可观测性之后,我们就可以进入到第二步,Level 1指标的监控了。指标是在许多个连续的时间周期里度量的KPI数值。
我们有三类指标需要去采集,包括系统指标、应用指标和业务指标。通常情况下,很多开源的监控工具都可以把系统和应用级别的指标采集到一个比较好的程度,但还是会很缺应用级指标,如果没有很好的应用指标,前两点做的再多都只是徒劳,因为解答不了到底业务好不好。
实施采集指标系统的话,通常也有一个参考实施架构,这个架构的最左侧是要监控的对象,对监控采集点的采集有两种方式,一是推送,主动把我的应用指标用agent方式推送到后端存储中,,其二是用抓取的方式,如Prometheus的模式,它采集的是在端点的暴露服务抓取点。采集的数据需要存储在类似于Elasticsearch的集中数据存储系统中。右侧再配以监控告警的机制。中间的部分需要提供一些集中存储的核心功能,例如聚合分析功能、运算功能,统计分析功能等等,可承载PB级的线性增长数据,这些都是非常核心的技术点。
如果仔细去想,会发现指标采集有很多要点,比如通过Beats和Logstash实现元数据的无痛丰富的工作,Elastic在架构上有它的各种优势。如果指标能够做到较完整的程度了,它才能在Level1上是OK的。还要思考破局指标监控可能的窘境的。
Level 2 日志
日志是指那些长时间累积的事件记录,我更钟爱的也是日志。每一条日志记录都能说明在某个时间点上发生过什么,这个事情如果是你关心的,你需要实施字段解析,然后把它进行存储分析和告警。
日志通常有两类,请求日志和排错日志。请求日志前端用的比较多。后端多是排错日志。管理大数据量日志有三个前提条件,第一做可集中化,不做集中化管理的后果是,当系统宕机排错时,可能老板就会站在你身后看着你用远程登录的方式手工查看日志,因为没有集中的收集去看这些日志,可以想象这是一件多么悲催的事。第二,可全文检索(Searchable),基于关键字去检索和分析排序。第三,可关联(Correlated)性。
Level 3 追踪
接下来是APM。APM解答了很多非常重要的问题,比如在应用日志正常的情况下,也同时出现了服务访问超慢的问题,APM可以通过全调用链分析,在代码级别告诉我们,慢操作到底是调用了什么代码,SQL语句查询了哪个service的数据库。APM低成本的在框架和代码级别深入的洞察调用链,可以实现应用全链路追踪系统的架构。
在来回顾一下,当你理解了三个基准点,在按照四个步骤按顺序做下来,健康检查、指标、日志、APM,基本上你就得到了一个比较完整的可观测性架构,而且ELK开源套件是可以很方便轻易的帮你实现以上架构。
4、构建可观测性的难点和挑战,准备的越充分,就能走的越远
回顾一下,指标、健康检查、日志、APM追踪和事件大致是怎样的情况?可观测性在帮我们了解这个世界,左侧告诉你的是:你知道你知道的事情,右侧告诉你的是一些:你不知道自己不知道的事情;健康检查、指标、日志分析等每个动作的角度都不一样,左侧更趋向于监控和可靠性,右侧更注重排错和探索,你如果出了bug,应用宕机了,可能更多的工作是处于右侧的那些点上。
综上所述,工具的可用性是实施可观测性的关键。最后,提示大家注意几点,第一,我们非常推荐用低成本的方式,比如Elastic Stack的APM去做追踪框架层面的应用追踪埋点,埋点会让应用监控人员眼前一亮,经常让开发和运维都得到一些非常惊喜的发现。
第二,数据要易于浏览查询和分析,在后台我们更倾向于具有数据分析归纳和聚合能力的存储,在不同的索引和日志之间更方便的关联查询和跳转。
第三,所有的监控数据应该是一个可靠的全面的数据集合,我们希望它存储在一个长期的,历史性的,大规模的存储中,并且可以合理成本的线性成长,满足所有团队的集中式访问。
谢谢大家!
活动推荐:
2019年12月7日,Elastic 中国开发者大会 2019(Elastic Dev Day China 2019)将在北京新世界酒店举办,了解大会详情和报名,请扫描下方二维码!
点击图片直接跳转大会日程
CNBPS 2019云原生技术实践峰会,汇集云原生产业趋势和技术干货,获取大会演讲PPT,请点击下方“阅读原文”,戳戳戳!