基于机器学习的智能运维 - 知乎专栏
{"debug":false,"apiRoot":"","paySDK":"/api/js","wechatConfigAPI":"/api/wechat/jssdkconfig","name":"production","instance":"column","tokens":{"X-XSRF-TOKEN":null,"X-UDID":null,"Authorization":"oauth c3cef7c66aa9e6a1e3160e20"}}
{"database":{"Post":{"":{"title":"基于机器学习的智能运维","author":"hack-stoic","content":"\n
听了裴丹教授关于《基于机器学习的智能运维》演讲之后的写下的一个笔记。今天来看， 还是有不少启发， 分享给大家， 对细节有兴趣的童鞋可以去看演讲实录。 在本文末尾附了相关链接。 \n\n
基于机器学习的智能运维\n
讲师： 裴丹\n概述\n
值得工业界运维工程师关注的顶级学术会议智能运维历程\n
基于专家库规则 －&
深度学习\n智能运维如何做好\n
机器学习本身有很多成熟的算法和系统，及其大量的优秀的开源工具。 如果成功的将机器学习应用到运维之中，还需要三个方面的支持： 数据， 标注的数据， 应用。 \n数据：互联网应用本身具有海量的日志。需要做优化存储。 数据不够还需要自主生成。 \n标注的数据:
日常运维工作会产生标注的数据。 比如出了一次事件后，运维工程师会记录下过程， 这个过程会反馈到系统之中， 反过来提升运维水平。 \n应用:
运维工程师师智能运维系统的用户。 用户使用过程发现的问题可以对智能系统的优化起正向反馈作用。 \nkpi异常检测系统的实现\n
运维人员判断kpi曲线的异常并标注出来， 系统对标注的特征数据进行学习 。（典型的监督式学习）\n\n
需要高效的标注工具来节省运维人员的时间： 如可以拖拽，放大\n挑战和解决方案整体设计多维度搜索日志分析框架\n
从多维度数据找出问题，然后优化。 利用到机器学习中的学习决策树的模型。 \n
每天日志来了之后，输入到机器学习决策树的模型里面，分析出每天高响应时间的条件，跨天进行分析，之后再去做一些准实验，最后得出一些结果。\n其它应用异常检测之后的故障定位\n故障止损建议\n故障根因分析\n数据中心交换机故障预测\n海量Syslog日志压缩成少量有意义的事件\n基于机器学习的系统优化（如TCP运行参数）\n总结机器学习的目标是： 自动化那些知其然，不知所以然的运维技能， 成为运维人员高效可靠的助手\n 更好的应用机器学习：特征选取的时候，早期可以用一些全部数据+容忍度高的算法，如随机森林，还有特征工程、自动选取（深度学习）；不同机器学习算法适用不同的问题；多和学术界讨论。 \n 从现有的ticket系统提取有价值的数据： ticketing系统作为智能运维的一部分来设计\n 智能运维到智能运营\n资源列表\n
[欢迎关注微信公众号“云时代的运维开发”，获得最新的文章推送］","updated":"T15:56:40.000Z","canComment":false,"commentPermission":"anyone","commentCount":0,"collapsedCount":0,"likeCount":1,"state":"published","isLiked":false,"slug":"","lastestTipjarors":[],"isTitleImageFullScreen":false,"rating":"none","titleImage":"/v2-b820fe0a5211cffca3403_r.jpg","links":{"comments":"/api/posts//comments"},"reviewers":[],"topics":[{"url":"/topic/","id":"","name":"机器学习"},{"url":"/topic/","id":"","name":"DevOps"},{"url":"/topic/","id":"","name":"算法"}],"adminClosedComment":false,"titleImageSize":{"width":1090,"height":518},"href":"/api/posts/","excerptTitle":"","column":{"slug":"clouddevops","name":"云时代的运维开发"},"tipjarState":"activated","tipjarTagLine":"鼓励分享","sourceUrl":"","pageCommentsCount":0,"tipjarorCount":0,"annotationAction":[],"snapshotUrl":"","publishedTime":"T23:56:40+08:00","url":"/p/","lastestLikers":[{"bio":null,"isFollowing":false,"hash":"094ea77208d0efe6b7d18e","uid":32,"isOrg":false,"slug":"wang-xing-29-58","isFollowed":false,"description":"","name":"王兴","profileUrl":"/people/wang-xing-29-58","avatar":{"id":"da8e974dc","template":"/{id}_{size}.jpg"},"isOrgWhiteList":false}],"summary":"听了裴丹教授关于《基于机器学习的智能运维》演讲之后的写下的一个笔记。今天来看， 还是有不少启发， 分享给大家， 对细节有兴趣的童鞋可以去看演讲实录。 在本文末尾附了相关链接。 \n\n 基于机器学习的智能运维 \n 讲师： 裴丹\n概述\n 值得工业界运维工程师…","reviewingCommentsCount":0,"meta":{"previous":{"isTitleImageFullScreen":false,"rating":"none","titleImage":"","links":{"comments":"/api/posts//comments"},"topics":[{"url":"/topic/","id":"","name":"DevOps"},{"url":"/topic/","id":"","name":"区块链(Blockchain)"},{"url":"/topic/","id":"","name":"互联网技术"}],"adminClosedComment":false,"href":"/api/posts/","excerptTitle":"","author":{"bio":"程序员， 爱生活， 爱编程","isFollowing":false,"hash":"e283cf8f119fea367ed7","uid":211100,"isOrg":false,"slug":"hack-stoic","isFollowed":false,"description":"关注devops, ELKstack，Kubernetes爱好者。 微信公众号：云时代的运维开发","name":"hack stoic","profileUrl":"/people/hack-stoic","avatar":{"id":"da8e974dc","template":"/{id}_{size}.jpg"},"isOrgWhiteList":false},"column":{"slug":"clouddevops","name":"云时代的运维开发"},"content":"DevOps容器与云计算区块链监控与日志其它\n
[欢迎关注微信公众号“云时代的运维开发”，获得最新的文章推送］","state":"published","sourceUrl":"","pageCommentsCount":0,"canComment":false,"snapshotUrl":"","slug":,"publishedTime":"T08:00:35+08:00","url":"/p/","title":"CloudIt.Ren 技术周刊（第2期）","summary":"DevOps
容器与云计算区块链","reviewingCommentsCount":0,"meta":{"previous":null,"next":null},"commentPermission":"anyone","commentsCount":0,"likesCount":0},"next":{"isTitleImageFullScreen":false,"rating":"none","titleImage":"","links":{"comments":"/api/posts//comments"},"topics":[{"url":"/topic/","id":"","name":"Kubernetes"},{"url":"/topic/","id":"","name":"容器"}],"adminClosedComment":false,"href":"/api/posts/","excerptTitle":"","author":{"bio":"程序员， 爱生活， 爱编程","isFollowing":false,"hash":"e283cf8f119fea367ed7","uid":211100,"isOrg":false,"slug":"hack-stoic","isFollowed":false,"description":"关注devops, ELKstack，Kubernetes爱好者。 微信公众号：云时代的运维开发","name":"hack stoic","profileUrl":"/people/hack-stoic","avatar":{"id":"da8e974dc","template":"/{id}_{size}.jpg"},"isOrgWhiteList":false},"column":{"slug":"clouddevops","name":"云时代的运维开发"},"content":"\n
本文目录：\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
字数：3500 ， 预计阅读时间：10min
\n\n\n\n\n
本文主要适合于那些有一定 k8s基础的人， 通过本文你将学到：\n\n\n\nk8s各组件的交互原理\nk8s的集群规划\nk8s系统配置， 各组件主要启动参数含义\nk8s部署过程可能出现的问题及解决方案\nansible基本知识\n背景\n\n\n
kubernetes是google开源的容器编排框架， 也是最流行的容器编排框架之一， 以下简称k8s。 \n
部署一个k8s集群，特别是一个高可用的k8s集群，往往需要费非常多的时间和精力。 \n
当前关于k8s部署的文章绝大部分是单master的部署，满足不了高可用的需求。 我们使用多master的部署方案来保证k8s控制节点的高可靠。\n
当前文章大多介绍的比较简单，只是罗列了安装步骤，对集群规划， 组件交互原理， 遇到的问题， 优化的手段等介绍的较少。
本文会通过介绍使用二进制部署k8s集群的步骤，各组件的启动参数，含义，可能遇到的问题， 以及简单介绍系统各组件的交互原理，来帮助大家理解和解决实际问题。\n
后面会有一系列的文章来介绍k8s概念原理，和生产实践。 那些日子开过的路段，踩过的坑， 都会毫无保留的分享。 \n
这是kubernetes实践系列的第一篇： 一键部署kubernetes 1.6高可用集群\n\n\n\n集群详情\n\n\n
实际生产实践中， 按照系统设计的流程，我们一般会先确定系统的逻辑架构图， 系统组件的调用关系图， 根据架构图确定需要多少机器资源， 需要开通什么样的防火墙策略。另外在部署之前需要考虑集群的规划， 比如需要什么样的网段， 每台主机需要管理多少容器， 只要支撑多少应用。 这些都是需要考虑的。 但是很多讲k8s部署的文章，又都很少涉及这块的内容。 下面听我一一道来。\n\n\n\n\n架构图\n\n\n
放一张官方的高可用逻辑部署图。 我们会按照这个部署图来构建整个k8s集群。 \n
另外放一张k8s各组件之间交互调用的原理图, 有助于大家理解每个组件的启动参数和防火墙策略的设定。 软件版本\n组件或系统\n版本\n备注\n Kubernetes
1.6版本支持单集群5000节点， 15万容器（官方数据）\nDocker
需要系统内核版本3.10以上支持\nEtcd
Etcd3的性能优于etcd2，k8s1.6版本使用etcd3做为状态存储组件。\nFlanneld
backend为vxlan网络， 需要系统内核版本3.7以上 支持\nCentOS
建议系统内核3.10及以上\n机器配置\n\n\n
下面的配置是POC环境的机器配置情况。 实际生产部署可以选择更好的机器，目前没有最优的建议， 可以根据成本预算和使用应用承载量而定。 \n\n\n\n组件\n机器配置\n备注\n ETCD
建议4核CPU,
4G内存及以上配置,
可以和k8s master组件共用机器混合部署，如果机器资源充足，建议分开部署\nK8S Master
建议4核CPU,
4G内存及以上配置， 3台
同上建议\nLoadBalance
建议4核CPU,
4G内存及以上配置， 2台
主备， 注意这个不要和master，node组件混合部署， 影响稳定性和可用性\nNode
4G内存， 1台以上
配置需求与运行的容器数量和应用类型相关\n防火墙策略\n\n\n
如果k8s不是在一个扁平的大二层网络里， 如果跨了多个网段， 且网段之间有防火墙隔离， 那么还需要考虑防火墙问题(以下不考虑加密传输的情况下，且使用默认启用的端口, 如果你修改了默认的端口，那么相应的修改防火墙即可)\n\n\n\nsource\ndestination\nport\n kubelet / kube-proxy
api server
8080\ncontroller-manager
/ scheduler
api server
8080\napi server
2379\ndockerd
docker registry
5000\nflanneld
2379\nflanneld
8285\n集群规划\n\n\n
网络和端口规划， 以下针对的是单个k8s集群的情况\n\n\n\n变量\n注解\n配置\n备注\n FLANNEL_NET
flannel的网段
192.168.0.0/16
注意不要和现有的网段规划冲突，另外此处掩码为16， 意味着支持2^(26-16),约1024个node节点\nFLANNEL_SUBNETLEN
flannel的子网掩码
掩码26，意味着单个主机可以最多分配2^(32-26) －2 ， 约62个容器\nSERVICE_CLUSTER_IP_RANGE
的 ip 网段
10.10.1.0/22
假设每个应用占用1个service ip， 则可以支持约2^(32-22) －2 ，约1022个应用部署\nNODE_PORT_RANGE
node port的端口范围
service的node port 可以使用主机上2767个端口\n部署详情\n\n\n
整个部署中，所有k8s的组件都用了编译好的二进制包进行安装，启动参数都写在单独的配置文件里。 进程使用systemd管理, 且加入开机自启动， 同时增加一个crontab任务，定时启动进程，确保进程在挂掉时能够及时拉起。 Ansible用来做任务编排。接下来会对ansible做一个简单的介绍，每个组件具体用到的启动参数和注意事项也会简要说明。 \n\n\n\n\nansible介绍\n\n\n
整个k8s集群的部署是用ansible进行任务编排的。 这里简单介绍下ansible， 更加详细的ansible介绍可以参考ansible文档。 \n
架构图\n\n
基本概念\n\n\n\n\n
ansible core：ansible自身核心模块\n
host inventory：主机库，定义可管控的主机列表\n
connection plugins：连接插件，一般默认基于ssh协议连接\n
modules：core modules(自带模块)、custom modules(自定义模块)\n
playbooks：剧本，按照所设定编排的顺序执行完成安排任务\n
files/：此角色中用到的所有文件均放置于此目录中；\n
templates/：Jinja2模板文件存放位置；\n
tasks/：任务列表文件；可以有多个，但至少有一个叫做main.yml的文件；\n
handlers/：处理器列表文件；可以有多个，但至少有一个叫做main.yml的文件；\n
vars/：变量字典文件；可以有多个，但至少有一个叫做main.yml的文件；\n
meta/：此角色的特殊设定及依赖关系；\n\n\n\n\n\n
常用命令\n\n\n\n\n
ansible-playbook -i
hosts site.yml
--list-hosts
列出要被执行任务的远程主机， 不执行任务\n
ansible-playbook -i
hosts site.yml
--list-tasks 列出要执行的任务， 不执行任务\n
ansible-playbook -i
hosts site.yml
--syntax-check 进行语法检查，不执行任务\n
ansible-playbook -i
hosts site.yml
执行任务\n\n\n\n\n\n
任务优化\n\n\n\n\n
增加失败重试\n
增加失败检查，比如etcd部署失败， 则任务退出，不再进行接下去的部署\n
执行操作前会先对旧的配置进行备份，方便出错时回滚配置\n\n\n\n\n部署流程\n\netcd 集群搭建 \nloadbalance主备搭建\nk8s master cluster 搭建\nk8s node 部署\n给node机器打label\ndns 插件部署\ndashboard插件部署\n部署ingress controller插件\n部署efk插件 \n\n
ps： 因为公司有一套完整的es集群, docker registry私有仓库和监控系统， 所以在部署中没有再额外构建这些环境。 不过以后会根据需要在部署过程中加入这些组件的构建。 \n\n\n\nETCD 集群\n\n\n
默认搭建一个有3个节点的ETCD集群\n\n\n启动参数\n参数说明\n ETCD_NAME
节点名称\nETCD_DATA_DIRS
指定节点的数据存储目录，这些数据包括节点ID，集群ID，集群初始化配置，Snapshot文件等\nETCD_LISTEN_PEER_URLS
监听URL，用于与其他节点通讯\nETCD_INITIAL_ADVERTISE_PEER_URLS
告知集群其他节点url.\nETCD_INITIAL_CLUSTER
集群中所有节点\nETCD_INITIAL_CLUSTER_STATE
初始化集群状态\nETCD_INITIAL_CLUSTER_TOKEN
集群的ID\nETCD_ADVERTISE_CLIENT_URLS
告知客户端url, 也就是服务的url\n\n
Tips建议和提示\n\n\n\n\n
ETCD_NAME=master01\n
ETCD_INITIAL_CLUSTER=\"master01=\"\n
这里ETCD_NAME和ETCD_INITIAL_CLUSTER对应的name要一致，否则可能会启动失败。 \n\n\n\n\nMaster节点\n\n\n
部署考虑了master组件的高可用, 由三个节点构成一个集群。 \n
apiserver是无状态的，前端提供负载均衡，暴露vip\n
controller manager 和 scheduler 是有状态的，需要进行leader elect， 同一时间只能有一个实例对集群信息进行读写。\n\n\n组件名称\n启动参数\n参数说明\n api server
--etcd-servers
以逗号分隔的etcd服务url列表, etcd服务以格式表示\napi server
--insecure-bind-address
绑定不安全的ip地址， 默认且localhost， 设置为0.0.0.0就可以侦听所有网络接口\napi server
--insecure-port
提供非安全认证的监控端口， 默认为8080\napi server
--kubelet-port
kubelet侦听的端口\napi server
--service-node-port-range
Service的node port 能使用的主机端口范围， 默认为30000 ～ 32767， 包括3\napi server
--allow-privileged
允许pod允许具有系统特权的容器， 默认值为false\napi server
--service-cluster-ip-range
service的cluster ip
(虚拟ip)池， 这个不能和集群所在物理网络重合\ncontroller manager / scheduler
api server的url地址\ncontroller manager / scheduler
--leader-elect
设置为true时，表示进行leader选举， 一般用于master的高可用部署， 默认值是false\ncontroller manager / scheduler
--leader-elect-lease-duration
leader选举过程中非leader等待选举的时间间隔， 默认是15秒\ncontroller manager / scheduler
--leader-elect-renew-deadline
leader选举过程中在定制leading角色之前再次renew的时间间隔，应小于等于eader-elect-lease-duration， 默认为10秒\ncontroller manager / scheduler
--leader-elect-retry-period
leader选举过程中，获取leader角色和renew之间的等待时间， 默认为2秒\n\n
Tips建议和提示\n\n\n\n\n
controller manager和scheduler的启动参数一致， 将 --leader-elect 设置为true，其它elect参数保持默认即可。 \n\n\n\n\nNode节点\n组件名称\n启动参数\n参数说明\n kubelet
绑定主机的地址， 默认为0.0.0.0， 表示使用主机上的所有网络接口\nkubelet
进程侦听的端口\nkubelet
--api-servers
api server地址列表， 以ip:port 格式表示，以逗号分隔\nkubelet
-allow-privileged
是否允许以特权模式启动容器， 默认是false\nkubelet
\n --cluster_dns
集群内dns服务的ip地址\nkubelet
--cluster_domain
集群内dns服务所用域名\nkubelet
--pod_infra_container_image
用于pod内网络命名空间共享的基础的pause镜像, 默认值为gcr.io/google_containers/pause-amd64:3.0\nkube-proxy
\n--master
api server的url地址\nflannel
-etcd-endpoints
以逗号分隔的etcd服务url列表, etcd服务以格式表示\nflannel
-etcd-prefix
etcd的前缀， 默认是//network\ndocker
--insecure-registry
设置私有仓库url地址\ndocker
绑定的bridge网卡地址\ndocker
启用ip伪装技术，一般用于NAT ， 默认为false\ndocker
网络包的大小， 默认为 1450\n\n
Tips建议和提示\n\n\n\n\n
pause镜像默认是从上拉取的， 但是由于gfw的缘故， 国内无法正常下载。 可以通过--pod_infra_container_image指定私有仓库或者可以访问的仓库镜像地址，让k8s到这些仓库去下载，而不是从\n
如果集群中有的node节点位于非dmz区域， 有的node节点位于dmz网络区域, 那么dmz区的docker启动的时候一定要设置--ip-masq 为true， 同时flanneld启动的时候要指定-public-ip 为nat转换后的ip，否则无法和非dmz区的docker容器正常通信，具体原理涉及flannel和vxlan网络原理，限于篇幅，不在这里赘述\n\n\n\n\n相关插件\n\n\n
使用的相关插件有nginx ingress controller， kubernetes dashboard， kubedns， fluentd ，都是使用k8s的方式进行编排， 启动并加载。 \n\n\n插件名称\n说明\n kubedns
启动1个replication controller， 副本数为1， pod里包含了三个container， 分别为kube-dns, kube-dnsmasq,
exechalhz，此外还会启动一个service，注意在kube-dns容器的启动参数中指定--kube-master-url\nnginx ingress controller
启动2个replication controller ，分别为default-http-backend 和 nginx ingress controller， 启动一个service。 注意在ginx ingress controller容器的启动过程设置环境变量 KUBERNETES_MASTER, 指定api server的url 及端口\nkubernetes dashboard
启动一个 replication controller, 一个service, 一个ingress， 注意在kubernetes-dashboard容器的启动参数中指定--apiserver-host\nfluentd
启动一个daemonset， 一个configmap，通过挂载configmap的方式可 以修改fluent.conf\n\n
Tips建议和提示\n\n\n\n\n
根据插件互相之间的依赖关系， 可以确定插件的加载顺序是 kubedns -&
nginx ingress controller
kubernetes dashboard / fluentd/...\n
外部下载镜像会遇到墙的问题。可以通过灵雀云的镜像中心来构建或者拉取被墙的镜像， 限于篇幅， 具体实现方法在这里不赘述。 \n\n\n\n\n优化和改进\n\n\n
由于时间匆忙，本人水平又有限， 也有一些需要改进和完善地方。 如：\n\n\n\n增加prometheus＋grafana插件\n增加私有的docker registry或harbor插件\n增加安全相关配置, 如TLS 认证通信 (所有组件，如 etcd、kubernetes master 和 node) ，RBAC 授权 等\ndocker的后端存储修改为overlayfs或者devicemapper的direct-lvm模式,以提高性能\nansible playbook 增加回滚步骤， 可以进行一键回滚\n针对负载均衡vip和vrid是否占用的自动检测， 防止网络冲突，导致 loadbalance无法正常启用\netcd前面暴露vip， flannel， api-server连接时使用vip进行连接\nansible每个task都进行检查，以校验是否成功\n调整kubelet的日志级别， 防止日志量过大， 撑爆磁盘\n除docker， kubelet之外，其它组件全部用k8s static pod的方式实现\n提供web界面，提供部署，动态修改参数等功能\n总结\n\n\n
kubernetes集群的整个部署过程是比较复杂的， 涉及的知识栈也比较多， 特别是在出现问题的时候，需要查阅大量的资料，包括源码。 另外值得一提的是， ansible 是一个非常棒的自动化工具。 我们使用ansible来编排自动化部署的任务，提高部署效率。 原来3天，甚至1个星期的部署工作，现在用半个小时的时间就可以部署一套功能相对完备的，高可靠的k8s集群。 限于篇幅有限， 有些细节可能叙述得不是很清楚。 如有谬误的地方， 也恳请指出。 \n
附上我的个人微信号和个人公众号， 欢迎关注和交流。\n
个人公众号：\n
云时代的运维开发\n\n\n\n\n
个人微信号：\n
paranoiakevin\n\n\n\n后续\n\n\n
众所周知， open-falcon是一个优秀的开源监控系统， 它的功能， 性能， 可扩展性能力都很强， 但是由于模块众多， 部署和管理这些模块变得比较复杂。 我们进行了尝试性的探索 ，利用k8s来管理open-falcon，并成功在生产中运行起来，。 \n
open-falcon的容器化过程中，遇到了不少问题， 实际部署又涉及了ingress以及有状态应用的问题，更多的细节，请期待kubernetes实践系列的第二篇文章：当open-falcon遇上k8s","state":"published","sourceUrl":"","pageCommentsCount":0,"canComment":false,"snapshotUrl":"","slug":,"publishedTime":"T23:49:44+08:00","url":"/p/","title":"一键部署kubernetes 1.6高可用集群","summary":"本文目录： \n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n 字数：3500 ， 预计阅读时间：10min \n\n\n\n\n 本文主要适合于那些…","reviewingCommentsCount":0,"meta":{"previous":null,"next":null},"commentPermission":"anyone","commentsCount":0,"likesCount":0}},"annotationDetail":null,"commentsCount":0,"likesCount":1,"FULLINFO":true}},"User":{"hack-stoic":{"isFollowed":false,"name":"hack stoic","headline":"关注devops, ELKstack，Kubernetes爱好者。 微信公众号：云时代的运维开发","avatarUrl":"/da8e974dc_s.jpg","isFollowing":false,"type":"people","slug":"hack-stoic","bio":"程序员， 爱生活， 爱编程","hash":"e283cf8f119fea367ed7","uid":211100,"isOrg":false,"description":"关注devops, ELKstack，Kubernetes爱好者。 微信公众号：云时代的运维开发","profileUrl":"/people/hack-stoic","avatar":{"id":"da8e974dc","template":"/{id}_{size}.jpg"},"isOrgWhiteList":false,"badge":{"identity":null,"bestAnswerer":null}}},"Comment":{},"favlists":{}},"me":{},"global":{},"columns":{"clouddevops":{"following":false,"canManage":false,"href":"/api/columns/clouddevops","name":"云时代的运维开发","creator":{"slug":"hack-stoic"},"url":"/clouddevops","slug":"clouddevops","avatar":{"id":"4b70deef7","template":"/{id}_{size}.jpg"}}},"columnPosts":{},"postComments":{},"postReviewComments":{"comments":[],"newComments":[],"hasMore":true},"favlistsByUser":{},"favlistRelations":{},"promotions":{},"switches":{"couldAddVideo":false},"draft":{"titleImage":"","titleImageSize":{},"isTitleImageFullScreen":false,"canTitleImageFullScreen":false,"title":"","titleImageUploading":false,"error":"","content":"","draftLoading":false,"globalLoading":false,"pendingVideo":{"resource":null,"error":null}},"drafts":{"draftsList":[]},"config":{"userNotBindPhoneTipString":{}},"recommendPosts":{"articleRecommendations":[],"columnRecommendations":[]},"env":{"isAppView":false,"appViewConfig":{"content_padding_top":128,"content_padding_bottom":56,"content_padding_left":16,"content_padding_right":16,"title_font_size":22,"body_font_size":16,"is_dark_theme":false,"can_auto_load_image":true,"app_info":"OS=iOS"},"isApp":false},"sys":{}}标签：至少1个，最多5个
机器学习技术在监控工具中的应用已经成为 IT 运维与 DevOps 团队的一大热点话题。尽管相关的使用案例很多，对 IT 团队而已真正的「杀手级应用」是机器学习如何提高实时事件管理能力，从而帮助较大规模的企业提高服务质量。对此，关键在于在用户发现问题之前提早探测异常，进而减少生产事故与中断的负面影响。
那么，在IT运维管理的环境下，机器学习到底是什么？
网上有不少关于机器学习的宏观定义：对于某给定的任务T，在合理的性能度量方案P的前提下，某计算机程序可以自主学习任务T的经验E；随着提供合适、优质、大量的经验E，该程序对于任务T的性能逐步提高。更通俗的来讲，即：随着任务的不断执行，经验的积累会带来计算机性能的提升。
如果在IT运维管理的前提下，也许这样的定义更加准确：机器学习是分析数据，反复地向数据学习，进而在不参考明确模型的情况下，找出隐藏观点的一类方法。
在 IT 运维管理的语境中，机器学习的首要替代方案是为 IT 运维管理建立行为模型，了解这一点非常重要。行为模型方法要求了解基础架构的所有组件，才能理解出现中断或服务质量下降的可能原因。更确切地说，你要试着判断哪些事件和告警模式与你希望监控的条件相匹配。
事实上，大多数 IT 运维管理工具都属于这一类别。不论是过时的遗留事件管理器，还是使用「聚合及查询」方法进行 IT 运维的现代工具。总之，你都要对这些工具进行一定的配置，让它们留意你预先就知道需要搜寻的东西。
而另一方面，机器学习则使用数据本身来寻找值得留意的特征，这些特征可能在事先完全无法预知。例如，非监督式机器学习，可用于分析事件流或日志消息，从而找出异常的消息集群。之后，这些异常可以与某项运维结果相联系，从而捕获潜在中断的原因与症状。
然而，监督式机器学习可用于记录用户针对给定告警及告警集群的活动，并相应地做出算法上的调整。本质上，机器学习利用数据不断地创建并更新行为模型，而不是使用静态的行为模型寻找特定的结果。
在 IT 数字化转型的今天，随之而来的规模复杂度、变更速度以及软件抽象化等挑战成为了机器学习应用于 IT 运维管理的理由。
如果基础架构处于不断变化的状态，根本无法建立起固定的行为模型。如果你想了解来自应用与基础架构的大量数据的意义，使用基于规则的方法无疑是死路一条。在新的软件时代，你必须利用机器学习进行实时的数据分析，这是保证服务质量的必备条件。无可否认，IT 领域正变得越发混杂、虚拟化以及流动化，只有使用机器学习技术，才能坦然应对这些变化。
现代 IT 环境下，不断变化的基础架构会产生大量的事件数据需要处理。在 OneAlert，机器学习主要用于「消除噪音」。例如，面对每秒钟成千上万的告警事件，如何在消除噪音的同时保留有价值的信息事件？
目前 OneAlert 产品对告警事件的压缩率已经高达80%。基于时间片的告警信息压缩已经趋于成熟，基于告警属性相似度的聚类模型能够将告警压缩率达到 95%。而基于机器学习的人工智能压缩更是能够将告警压缩到 99%（我们敬请期待！）
是北京科技有限公司旗下产品，是国内首个 SaaS 模式的，集成国内外主流监控/支撑系统，实现一个平台上集中处理所有 IT 事件，提升 IT 可靠性。想了解更多信息，请访问 OneAlert 官网 ，欢迎体验 。
0 收藏&&|&&1
你可能感兴趣的文章
3 收藏，539
分享到微博？
技术专栏，帮你记录编程中的点滴，提升你对技术的理解收藏感兴趣的文章，丰富自己的知识库
明天提醒我
我要该，理由是：
扫扫下载 App