请选择 进入手机版 | 继续访问电脑版

ITIL,DevOps,ITSS,ITSM,IT运维管理-ITIL先锋论坛

 找回密码
 立即注册

扫描二维码登录本站

QQ登录

只需一步,快速开始

查看: 745|回复: 0

大话Devops之监控神器

[复制链接]
发表于 2020-7-30 16:09:06 | 显示全部楼层 |阅读模式
本帖最后由 陈小宝 于 2020-7-30 16:33 编辑
7 H) ?4 j  v& U# X7 }
  F# R7 E6 X/ W1 G- ?在过往的运维经历中,很多研发甚至是运维自己都把运维放在了一个资源(服务器、网络)提供者的定位上。
# Y0 Z+ X9 q% b7 z7 d6 p
常常就造成了运维人的惯性思维——我是一块砖,哪有需要往哪搬。% g( k/ L9 d  ?) O  w4 @

# }/ K/ S$ _; a; |, C- L  U* e* ?

: h) L: ^$ X$ D) I- b% C/ n0 A5 Z. z6 {( L
思考一个问题:在云计算、大数据、微服务的新时代场景下,我们如何提升运维的价值?

3 t0 W8 G& G6 q>> 3点提升运维价值 <<
* U( ?% _, |' X( y我认为可从以下3点,提升运维工作价值:: O1 K) M* S' P. e, E
1.服务质量
' ?. Q1 d% Y0 Q) N- ?3 V
系统无中断地执行其功能的能力,我们称之为高可用性(High Availability,HA)。% \4 F! [* p6 u/ R2 Q1 \
度量系统运行情况的指标最常用的是:MTBF(Mean Time Between Failure,即平均无故障工作时间)、MTTR(Mean Time To Repair,即平均修复时间)、MTTF(Mean Time To Failure,即平均失效时间)。% o3 W! w+ z* U% L. _, F% j$ H7 v; t3 V
& l2 k  T! r. B" D! y

2 H" B- F3 a8 }' ^9 o- L' S7 C
MTBF:新产品在规定的工作环境下,从开始工作到出现第一个故障的时间平均值。MTBF 越长表示可靠性越高,正确工作能力越强 。MTTR:可修复产品的平均修复时间,即从出现故障到修复中间的这段时间。MTTR 越短表示易恢复性越好。MTTF:系统平均能够正常运行多长时间,才发生一次故障。系统的可靠性越高,平均无故障时间越长。

, e% @# a: y' S' U) Z而度量高可用性的方式是根据:系统损害、无法使用的时间,以及由无法运作恢复到可运作状况的时间,与系统总运作时间的比较。0 p  M+ J" z: P8 t1 y& o
. m' f" \% M8 L2 [% z3 @- }) M3 O8 p% `

# o, P4 ?, H. X; H! R2 }$ o计算公式为:A = MTBF / (MTBF + MTTR)
  s" S$ B2 U( m3 ~3 [. z+ y7 ?8 {8 L0 d/ _* k* Z5 d( }
可用性的年故障时间:99.9999%    32秒
$ y6 W% N$ ?4 |. `1 o6 {99.999%      5分15秒
0 |7 W# V) \2 e; F% F5 `99.99%    52分34秒% ?8 M1 {7 O% ?4 r
99.9%      8小时46分# M; W3 {: |/ S: L+ T. ]
99%       3天15小时36分! b, ]8 X/ h- d
7 b( d/ v- \, b* V  l
为了提高 MTTR,要做到出现故障后尽快发现故障,尽快定位故障原因,尽快修复,尽量不造成新的故障。, i$ o3 x  w& [8 m( B/ N/ h

2 d0 c) M) u0 l" d, E

2 l. f$ n6 i8 Y9 x5 C- W
做好监控能帮我尽快发现故障,所以我们需要一套完善的监控系统。
2.成本控制

& w+ M( e  [- p" v# {% c% s总体来说,就是如何利用我们手头的资源尽量的最大化我们的工作服务。
/ S# e5 o  s! d9 g9 G
我们需要检测最高系统访问量下的成本消耗,所以我们要有一套完善的监控机制,确保资源不够时候能快速扩容,过了高峰期之后,我们又能快速缩容。
3.自动化和标准化

4 T# K( A5 T/ x  B/ \, q, @! J这个也是现在DevOps比较主流的概念了,底层基于cmdb。上次业务系统做好标准化,尽量花很少的成本去做更多的事情。5 S  ~# n; M0 U- W3 y, J# j
打通了运维和开发的一个格局,快速的实现产品的迭代发布和更新周期。当然归根结底是我们要把业务系统关联性和监控性打通。# k% v4 w: J0 ?/ X3 r5 M
下面是我在前东家的时候,我们对基础平台的构建,当然后面也简单讲到我们对监控系统的二次开发:
) o; Z8 n$ K! V1 F' S
1.jpg
6 X  M6 e5 N( X, L/ ?# ~. i
监控解决了什么问题# X. q2 i9 l. {% X
对于我们运维来说,可能百分之七十的时间,都在跟监控系统打交道,那么一个好的运维监控系统能带给我们什么呢?, b- U& j1 l1 n* x8 K
1.硬件层面的监控

6 R: z$ S4 K* t- [如果服务器出现硬件问题可以提前知晓,提前安排好解决方案,避免突然出现问题造成损失;
4 f' s/ o% J# J, ~1 }( a3 S. d0 t
2.软件层面的监控
3 a  T) D$ }% }8 p: w
如果系统资源与服务出现问题,可以及时知晓并解决,同时可以根据周期内监控数据,做好调优;7 _0 m6 Q6 e- s/ v
3.微服务层面的监控
( j" X( t/ I$ n
在软件工程发展至今,好像不提自己公司有微服务都觉得落伍了。
4.云平台层面的监控

! n* H8 H7 M2 Z7 B, s, ?如果我们底层是以openstack、k8s为基础提供pass平台,那么我们监控也是致命的环节。2 u2 Z" c* o( l7 g8 H/ Q, [
在出现故障之前替换掉某个主机,或者节点,避免出现更大故障也是需要的(比如做openstack,我们发现ceph硬盘有坏的,要及时更换,同步分片)
6 G. h. t! I5 o8 b, h% [# f: T6 k4 k

0 v9 M  _6 I* E运维软件简单介绍& H; _' q) c9 b. \% M+ a7 s" }% U
* t2 O$ [. F1 [1 Z6 |# S
从11年毕业至今,做过CDN行业的运维,在电商行业众划算、试客联盟做过运维经理,在某国内大型FM平台做过Devops工程师,到现在如今在某500强企业任职openstack 工程师。( O* H% x- g6 C* f( T
技术都是由共通性的,只要把某一部分学会了完成我们的目标即可(记住一点,没有好与坏之说,只是你在特定场景下满足了你的生产需求),当然后面我会阐述为啥我们用prometheus。
5 T3 Y5 l2 ?$ G2 t( W
2 T- N& G0 ~$ G+ D( F

/ p6 K% ^3 |, m6 {
1.网络监控:Smokeping
  j8 G& N5 Z& |) o) v5 N- N0 [
Smokeping 是一款用于网络性能监测的监控软件,通过它可以知晓自己公司IDC的网络状况:如延时,丢包率,是否BGP多线等。通过rrdtool制图方式,图形化地展示网络的时延情况,进而能够清楚的判断出网络的即时通信情况。6 |9 D) M6 c5 n
最早选择这款软件的时候,是在我们对BGP机房选型和网络测试。机房给两台主机,然后我就基于这款软件的IP端去做网络检测,效果挺不错:
5 T7 C9 B$ w8 t! N
2.jpg

0 [) p  s# @) G. ^' b4 G+ |
2.邮件告警监控:nagios

8 `6 @) v. a2 e: b' `! R& L7 ?6 LNagios是一款开源的企业级监控系统,能够实现对系统CPU、磁盘、网络等方面参数的基本系统监控,以及 SMTP,POP3,HTTP,NNTP等各种基本的服务类型。另外通过安装插件和编写监控脚本,用户可以实现应用监控,并针对大量的监控主机和多个对象 部署层次化监控架构。
4 q, x2 L0 [% f+ h5 h, Y' ]
3.jpg

1 ], C* r% P- l8 {
当时使用Nagios主要是做邮件告警监控。但是Nagios有个问题:它是一个流式数据告警软件,可以对达到阈值的主机进行告警,却不利于追述历史数据。所以以前最古老的解决方案就是,nagios + cacti(nagios 告警、cacti图形展示) 结合工作。
3 S9 ^: V  m7 r& V3 W+ C0 D0 P
& J' b3 v0 M( v  |& A
3.仙人掌:Cacti
. A* B4 ~7 ^8 y2 G0 Q( Q8 `! v
Cacti 在英文中的意思是仙人掌的意思,Cacti是一套基于PHP、MySQL、SNMP及RRDTool开发的网络流量监测图形分析工具。它通过snmpget来获取数据,使用 RRDtool绘画图形,它的界面非常漂亮。# P8 r. _% n# b- \; B' K/ p$ M
但是有个缺点:cacti只是提供图形服务,没有提供告警功能,所以还是之前说的nagios + cacti的方案:
0 D$ U0 _1 k3 l( l+ P$ L5 h
4.jpg

% W& i2 x. F' b7 z0 k总的来说,最开始学习运维的菜鸟时代,觉得cacti高大上。但是可能刚开始基础较差,经常不出图,导致后来又去学了RRDtool的原理。7 T0 c+ y: k, A0 i) n( |" v

! @$ `4 I) v+ z) n4 D, `

/ [, o* F* B* p/ j4 S- e3 `
4.万物监控利器:zabbix
Zabbix是一款能够监控各种网络参数以及服务器健康性和完整性的软件。Zabbix使用灵活的通知机制,允许用户为几乎任何事件配置基于邮件的告警。这样可以快速反馈服务器的问题。基于已存储的数据,Zabbix提供了出色的报告和数据可视化功能。当然zabbix最优秀的地方在于,简单,并且可以做到自动化,自动发现,灵活的告警规则,可以定制脚本发送,对接各种第三方软件、实现很多自动化的东西:下面是我们基于zabbix 的一个简单结构:
5.png

3 ~; i( M, ^: l9 I: h) G补充:zabbix对我来说是万能了,自定义监控,我们可以涵盖了很多监控。包括硬件状态、带宽状态、域名告警时间等。6 s! ^8 R+ ~% C, W% K
由于zabbix有非常优秀的api,所以基于zabbix和cmdb的开发也是理所当然的,简单的截图说明一下我们之前对于zabbix 所做的工作。
2 P% q% K+ r# S0 Z8 Q3 X4 h
同步cmdb数据到主机主:
6.jpg
# j0 x2 J- h) Y! n4 \' h
cmdb与主机的模板绑定:
7.png

5 y9 F) Z* r/ o7 M$ j给主机添加维护:
8.png
8 [7 T/ ~& z; i/ }; ^) c; [
结合echart出图:
9.png

% S% v! ~% R( c9 d- _总结:以上都是zabbix的优点,如果说缺点的话那么只能说zabbix 依赖的是mysql数据库,数据量非常大的时候,会存在性能瓶颈问题。所以从Zabbix 4 版本后开始支持TimescaleDB时序数据库,不过目前成熟度还不高。还有一点是对云原生和微服务的支持。* Q" R$ M: L6 y6 m2 f: H& n

/ ~" R- Y% w( {% D
! j2 k* y4 L! \9 G: r
5.日志分析利器:ELK

/ C1 C1 E" T4 nELK是elastic公司提供的一套完整的日志收集以及展示的解决方案,是三个产品的首字母缩写,分别是ElasticSearch、Logstash 和 Kibana。/ u/ a1 H9 s7 w$ I; \) i$ X7 z: y6 }
10.png

0 U1 E. A/ h) x* e4 z
最初选择ELK是我们遇到日志量越来越庞大的时候;这个时候需要一个实时的,快速搜索的一个日志分析平台,然后我们选择了ELK。主要用来分析:nginx日志,开发业务日志,系统和历史数据日志等、并且对接到了我们的告警平台。
: q7 V  \8 G( N3 ^* Q3 D; M3 R$ H7 }5 U) V4 x% o& R2 ^: [
6.云基础设施监控利器:Prometheu
- a& u8 ]. M3 f! @# w; B
普罗米修斯是我这边最近主推的监控,一来是简单拿来即用的granafa图表。二来是我这边最近所遇到的困境:
) G3 ?/ F6 C! Y# c3 r$ D0 O0 l
基于云平台openstack 、k8s如何做监控、服务如何发现k8s资源并监控。微服务面临的挑战、我们监控的对象是动态可变的。无法进行固定有效配置。微服务实例间的调用关系非常复杂,如何通过网关等查找到我们相关的请求数据。例如我们这边网关是nacos、spring boot体系。监控系统必须在k8s基础上,快速水平扩容,这既是云原生的基本要求,也符合企业系统微服务化演进的实际情况。(罗辉)




上一篇:test
下一篇:如何在DevOps世界中简化复杂的企业工作流
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

参加 ITIL 4 基础和中级专家认证、v3专家升级、DevOps专家认证、ITSS服务经理认证报名
本站关键字: ITIL| ITSM| ISO20000| ITIL培训| ITIL认证| ITIL考试| ITSS| ITSS培训| ITSS认证| IT运维管理| DevOps| DevOps培训| DevOps认证| itop| itil4| sre| 开源ITSM软件

QQ|ITIL先锋论坛 ( 粤ICP备11099876号 )|appname

Baidu

GMT+8, 2021-8-6 07:54 , Processed in 0.126108 second(s), 29 queries .

Powered by Discuz! X3.4 Licensed

Copyright © 2001-2020, Tencent Cloud.

快速回复 返回顶部 返回列表