前面几个章节我们重点介绍在CICD阶段，我们可以依赖哪些开源的产品去帮助我们加快CICD的落地，当然，CICD也仅仅是DevOps整个环节中重要的一环，如果只是认为CICD就是DevOps的话，我个人觉得理解上可能那么点欠缺。 那讲完了CICD的内容，我们这章就来探讨下我们应用上线后会有哪些DevOps的流程贯穿到运维中去。
正如前面所讲，我们以前的运维方式都是等问题来了我们才会去解决，然而敏捷的研发交付模式对于问题来了再去解决，可能在一定程度上会使用户满意度不够友好，同时也会导致交易量的下降。所以我们可以用哪些比较成熟的开源工具去解决这些问题？按照之前对于问题分类级别的划分，如下面内容。
首先，我们先看一下日志层面。 日志是最能展现我们应用是否健康运行的重要指标之一。按照日常我们对日志的分类，从Info到Erro不同级别。其中Error日志是我们在生产中最关注的一块，往往看到Error，我们总会瑟瑟发抖。所以我们就可以思考我们怎么去相对实时地预警出相关的Error日志到服务的Owner。
既然要对日志预警，那其中肯定就会包含两块内容，第一，收集日志的问题；第二，对收集到的日志做分析的问题。两种缺一不可。 目前行业内也有很多主流的方案，如下是我在生产中所使用过的一些方案。
我们可以把日志的搜集分为两类，第一类为agent的被动上报；第二类为客户端的主动上报。 我们先看下agent的被动上报机制。 此机制其实就是在你的服务器中安装一款软件，将你日志的输出路径提供给这款软件，这款软件定期地进行扫描，从而最终将日志上报给服务端。比如Elastc技术栈中的filebeat/logstash就是一个代表。 另外一种机制就是客户端的主动上报机制。 其实就是在你的应用中集成一个SDK，在应用输出日志的时候进行拦截捕获，通过异步的方式分批报送给服务端。比如美团的Cat。
说完了日志搜集，我们再讨论下日志分析。 日志分析方式其实也分为两种，第一种是报送时候即分析；第二种是报送到服务端后，在服务端进行分析。 我们先看第一种方式。 第一种方式的实现方式其实也有很多，比如在应用中集成一款SDK，SDK实时对日志进行分析，当然这样也会造成一定的性能问题，比如美团的Cat产品里面就有此种方式实现的影子；所以又催生了另外一种方式，就是SDK先上报到某一处，在这个地方实施地按照既定的指标进行日志分析，最终再进行离线数据落地操作，这种方式其实就是流数据处理的方式，比如如今主流的kafka-stream,Flink等，另外Kibana也可以设置一定的预警规则进行预警，属于其实也属于先搜集后预警的方式。
后面的实战篇我们也会对这些产品做一定的实践。
说完了日志搜集以及分析，我们再稍微说下日志的存储和搜索。 我们知道生产规模的日志日积月累肯定是庞大的，那么我们如何能够去对这些做存储并能相对做快速地搜索呢？ 按照我的使用经验，第一种就是对日志文件进行拆分合并存储到分布式的文件系统，比如HDFS，同时通过HIVE库进行一定搜索查询；另外一种就是依赖ES，通过ES的集群将日志进行存储，同时通过倒排索引的文档索引方式，提升日志查询的速度。
当然，其实业界还有很多的产品。比如在日志搜集过程中为了应对海量传输的问题，我们会使用Kafka等消息队列，比如我们也会通过Flume做日志的管道传输等等。所以每个企业只需要按照自身的技术能力以及对未来的一些规划找到合适自己的产品即可。
以上的日志还是主要针对于应用的业务日志搜集、分析、存储。 那对于中间件和服务器的一些指标我们又如何来搜集分析预警呢？
首先我们先看一下服务器的指标收集。 用过linux的同学应该知道，我们平时会通过top来查看CPU使用情况，或者我们通过/proc/cpuinfo来查看CPU整体情况，比如我们通过/proc/meminfo等查看内存情况等，所以既然我们能够通过这些指令去查看linux的一些指标去查看，那肯定也会有一些开源的产品帮助我们去分析。
另外再看一下中间件。 中间件有很多，比如分布式缓存、消息队列、mysql、JVM、tomcat等，这些中间件的运行情况其实是影响我们应用运转的方方面面。目前社区对于每款中间件也有它们自己的监控方案。比如就拿消息队列来说，对于topic的数量、分区的数量、消息的数量、消息堆积、消费的速度等，每一款消息队列产品都有它们的监控方式。所以，很多时候对于这些中间件来说，我们并不需要去重复造监控的轮子，完全可以去研究社区中的衍生产品来达到我们的目标。
目前社区中也有很多开源的产品对这些指标进行监控支撑。比如Zabbix对主机组进行监控，比如Nagios对网络进行监控，比如基于Prometheus的各项service可以对中间件以及Node进行监控，再比如k8s技术栈下，通过cAdvisor、Heapster的组件获取POD消耗的memory、CPU和网络等信息等。
那除了这些，我们可能还要思考对服务的监控。 服务的监控的按照每个应用形态的分类也各有不同。比如基于主机部署的Dubbo应用，条件有限的可以基于其提供的Dashbord进行初步的服务指标查看，比如基于springboot的应用可以监控health端点的健康状况，如果应用是部署到K8S的POD中，我们也可以通过liveness和readness的probe实施探针进行健康检测，有条件的也可以基于应用层去定制更丰富的健康检测方案，比如携程的conerston提供了应用中充分的健康指标查看与分析。
其实还有很多产品，这里就不再做介绍了，等后期的实践中我们再继续探讨。
至此，我想涉及的一些技术部分的初步入门内容就结束了。接下来的两篇我们可能去探讨DevOps的其他一些理念，比如GitOps、AI相关的畅想、配置库、IT基础架构以及DevOps如何在企业中落地的一些个人看法。
—————–EOF——————