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

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

 找回密码
 立即注册

扫描二维码登录本站

QQ登录

只需一步,快速开始

查看: 936|回复: 0

大话Devops之监控神器

[复制链接]
发表于 2020-7-30 16:09:06 | 显示全部楼层 |阅读模式
本帖最后由 陈小宝 于 2020-7-30 16:33 编辑
4 F2 y8 u: k* ~, A  i: [% c
! F& E- P( N7 O' o  I# E( V( u在过往的运维经历中,很多研发甚至是运维自己都把运维放在了一个资源(服务器、网络)提供者的定位上。& L3 }- X# k- [( I" ~9 {
常常就造成了运维人的惯性思维——我是一块砖,哪有需要往哪搬。
+ I/ g$ V- X, i: d2 l/ g
" P9 v6 e$ K- G! |( O0 u

# Z3 _+ m9 ]( Z/ Q  ~* U3 O, h
思考一个问题:在云计算、大数据、微服务的新时代场景下,我们如何提升运维的价值?
; X1 `6 g# i" u) V3 j8 d
>> 3点提升运维价值 <<
% D! L# R  g4 b9 D7 j我认为可从以下3点,提升运维工作价值:
1 T) p' U! U0 {: i! a2 N7 C0 [0 n4 z8 o
1.服务质量

* K5 L/ n: B7 {9 z$ l系统无中断地执行其功能的能力,我们称之为高可用性(High Availability,HA)。
* H4 w! D& u5 U  x5 [1 ~& |, T9 ^. L
度量系统运行情况的指标最常用的是:MTBF(Mean Time Between Failure,即平均无故障工作时间)、MTTR(Mean Time To Repair,即平均修复时间)、MTTF(Mean Time To Failure,即平均失效时间)。
4 L; w1 ]) r5 ^' k2 h, Z9 B6 y( j. M' ?8 _/ i  C
; e0 s2 z' t- z: G, ?; |9 v
MTBF:新产品在规定的工作环境下,从开始工作到出现第一个故障的时间平均值。MTBF 越长表示可靠性越高,正确工作能力越强 。MTTR:可修复产品的平均修复时间,即从出现故障到修复中间的这段时间。MTTR 越短表示易恢复性越好。MTTF:系统平均能够正常运行多长时间,才发生一次故障。系统的可靠性越高,平均无故障时间越长。
" i& y/ u# }( ~6 g# ?
而度量高可用性的方式是根据:系统损害、无法使用的时间,以及由无法运作恢复到可运作状况的时间,与系统总运作时间的比较。
0 i) U( H7 N) i2 ?) ^% \! t! `* O7 w! g( X& e
. q9 i' ?2 X. c5 U' W3 U7 p/ |; F
计算公式为:A = MTBF / (MTBF + MTTR)9 j; j: L, j; B* N' k, S1 |4 @% g

  Y' [! c# i  \4 @! Q. T; }' v可用性的年故障时间:99.9999%    32秒
* G* ]. x$ q! Y; Z2 \1 y99.999%      5分15秒+ \  A% l# _! Q. O4 x
99.99%    52分34秒
6 N  n( N. a: c! g+ m1 c( Z99.9%      8小时46分
0 k7 ?, U' w9 c99%       3天15小时36分9 ^; X+ \7 x  s4 a+ l! T8 u9 u9 W

* T6 k7 ]$ ~# T: J3 d
为了提高 MTTR,要做到出现故障后尽快发现故障,尽快定位故障原因,尽快修复,尽量不造成新的故障。
4 f+ \: l; M5 i: l7 C2 n1 Y$ G! c  g3 A" ?5 V
, X0 X( C4 n/ y, e+ I0 t# v( Z
做好监控能帮我尽快发现故障,所以我们需要一套完善的监控系统。
2.成本控制
1 _4 W! J& }* q" C0 B  r7 g
总体来说,就是如何利用我们手头的资源尽量的最大化我们的工作服务。8 |2 {/ m1 D0 d5 a1 ^; u7 B" f+ x
我们需要检测最高系统访问量下的成本消耗,所以我们要有一套完善的监控机制,确保资源不够时候能快速扩容,过了高峰期之后,我们又能快速缩容。
3.自动化和标准化
. _. \' K% W' o* V- Z
这个也是现在ITILxf.com" target="_blank" class="relatedlink">DevOps比较主流的概念了,底层基于cmdb。上次业务系统做好标准化,尽量花很少的成本去做更多的事情。
4 A5 C) |$ h0 b! a! N+ _
打通了运维和开发的一个格局,快速的实现产品的迭代发布和更新周期。当然归根结底是我们要把业务系统关联性和监控性打通。
) j' Q! f1 B# B" r0 I  [
下面是我在前东家的时候,我们对基础平台的构建,当然后面也简单讲到我们对监控系统的二次开发:+ E  S# T7 g  M5 ~  e2 d
1.jpg

( a0 i6 l# [8 G" |; m$ Z/ b
监控解决了什么问题
6 w  _( p5 R, j0 X对于我们运维来说,可能百分之七十的时间,都在跟监控系统打交道,那么一个好的运维监控系统能带给我们什么呢?
+ X# f" ]8 [- O6 T' C5 S- l. M
1.硬件层面的监控
7 H* [. E% P" a0 L$ E$ N6 J8 b
如果服务器出现硬件问题可以提前知晓,提前安排好解决方案,避免突然出现问题造成损失;9 C8 z& p9 F" |/ L. A/ r1 W) Z6 D7 E
2.软件层面的监控

8 K* L" t9 @9 {如果系统资源与服务出现问题,可以及时知晓并解决,同时可以根据周期内监控数据,做好调优;
$ c3 z+ Y0 _0 Z2 Q, v) G# m# [
3.微服务层面的监控
7 j' }$ C: w" Q( K$ P  b: P1 n$ w
在软件工程发展至今,好像不提自己公司有微服务都觉得落伍了。
4.云平台层面的监控
. X$ w7 ^; P. f/ X4 V
如果我们底层是以openstack、k8s为基础提供pass平台,那么我们监控也是致命的环节。
$ [- X6 N9 G9 Q3 w* T6 r1 m
在出现故障之前替换掉某个主机,或者节点,避免出现更大故障也是需要的(比如做openstack,我们发现ceph硬盘有坏的,要及时更换,同步分片)6 ?0 B! l5 {% P! P7 F+ i
" {' o6 Z* P" u9 @' F  u6 E; G( p6 o

' I5 p4 \" ~6 ^8 ]- Y运维软件简单介绍
* }) L/ e+ l) \) x$ X9 w2 v8 Z- V3 m5 E3 T
从11年毕业至今,做过CDN行业的运维,在电商行业众划算、试客联盟做过运维经理,在某国内大型FM平台做过Devops工程师,到现在如今在某500强企业任职openstack 工程师。
7 r9 e* ^0 j- K; X
技术都是由共通性的,只要把某一部分学会了完成我们的目标即可(记住一点,没有好与坏之说,只是你在特定场景下满足了你的生产需求),当然后面我会阐述为啥我们用prometheus。. e% `/ j8 H1 m
* J1 G. r: ?$ }5 Y" {" Q# x

! S/ k& f3 w  b
1.网络监控:Smokeping
+ L1 b$ ~' u- g2 D; }' q7 a
Smokeping 是一款用于网络性能监测的监控软件,通过它可以知晓自己公司IDC的网络状况:如延时,丢包率,是否BGP多线等。通过rrdtool制图方式,图形化地展示网络的时延情况,进而能够清楚的判断出网络的即时通信情况。
) }9 [7 @9 j  `& r
最早选择这款软件的时候,是在我们对BGP机房选型和网络测试。机房给两台主机,然后我就基于这款软件的IP端去做网络检测,效果挺不错:6 M0 O! T2 a0 L+ n' |% e# y' y
2.jpg

  r2 h8 ?6 g* `/ V
2.邮件告警监控:nagios
  _  h4 T% X, L1 J% J
Nagios是一款开源的企业级监控系统,能够实现对系统CPU、磁盘、网络等方面参数的基本系统监控,以及 SMTP,POP3,HTTP,NNTP等各种基本的服务类型。另外通过安装插件和编写监控脚本,用户可以实现应用监控,并针对大量的监控主机和多个对象 部署层次化监控架构。/ W! K( o4 ]% t
3.jpg
! u& B8 \7 F( r3 X% A7 o" q# x. {
当时使用Nagios主要是做邮件告警监控。但是Nagios有个问题:它是一个流式数据告警软件,可以对达到阈值的主机进行告警,却不利于追述历史数据。所以以前最古老的解决方案就是,nagios + cacti(nagios 告警、cacti图形展示) 结合工作。
3 @5 Y  H: t$ x6 ~) K" _9 O$ _& M  s4 `! }% A' U3 A
3.仙人掌:Cacti

& T1 t3 y( b" o, r6 UCacti 在英文中的意思是仙人掌的意思,Cacti是一套基于PHP、MySQL、SNMP及RRDTool开发的网络流量监测图形分析工具。它通过snmpget来获取数据,使用 RRDtool绘画图形,它的界面非常漂亮。
( b* a) H# h( r+ [: a
但是有个缺点:cacti只是提供图形服务,没有提供告警功能,所以还是之前说的nagios + cacti的方案:
% m8 z+ p) E* }* O0 z
4.jpg
5 M* G4 @: y6 p( t
总的来说,最开始学习运维的菜鸟时代,觉得cacti高大上。但是可能刚开始基础较差,经常不出图,导致后来又去学了RRDtool的原理。
7 j  a4 W7 h6 ^! ^9 {/ D" T$ v3 p  B" }0 l
( f4 @; w1 w" n
4.万物监控利器:zabbix
Zabbix是一款能够监控各种网络参数以及服务器健康性和完整性的软件。Zabbix使用灵活的通知机制,允许用户为几乎任何事件配置基于邮件的告警。这样可以快速反馈服务器的问题。基于已存储的数据,Zabbix提供了出色的报告和数据可视化功能。当然zabbix最优秀的地方在于,简单,并且可以做到自动化,自动发现,灵活的告警规则,可以定制脚本发送,对接各种第三方软件、实现很多自动化的东西:下面是我们基于zabbix 的一个简单结构:
5.png
4 N6 V9 \7 p; s% ^* D$ H
补充:zabbix对我来说是万能了,自定义监控,我们可以涵盖了很多监控。包括硬件状态、带宽状态、域名告警时间等。% f& w. T! F( r+ b2 o* G" r
由于zabbix有非常优秀的api,所以基于zabbix和cmdb的开发也是理所当然的,简单的截图说明一下我们之前对于zabbix 所做的工作。
7 \- g- q; a% d
同步cmdb数据到主机主:
6.jpg
0 l1 t# `6 k* L& O! _3 `
cmdb与主机的模板绑定:
7.png
! R1 @* t+ ^# w- c
给主机添加维护:
8.png

3 A  y3 o0 R4 [1 e
结合echart出图:
9.png

6 P1 ?- }% Z4 v总结:以上都是zabbix的优点,如果说缺点的话那么只能说zabbix 依赖的是mysql数据库,数据量非常大的时候,会存在性能瓶颈问题。所以从Zabbix 4 版本后开始支持TimescaleDB时序数据库,不过目前成熟度还不高。还有一点是对云原生和微服务的支持。& \: O8 x; R* A' e0 W

. G* @0 U$ p5 n, z, C6 U$ M- Q( H
- R; H; x/ y+ G+ w% V0 R
5.日志分析利器:ELK

  Z1 `/ u9 c2 |+ s& sELK是elastic公司提供的一套完整的日志收集以及展示的解决方案,是三个产品的首字母缩写,分别是ElasticSearch、Logstash 和 Kibana。
4 f; k* M: L6 Z+ D: I/ V
10.png

2 j: i+ j- x# H
最初选择ELK是我们遇到日志量越来越庞大的时候;这个时候需要一个实时的,快速搜索的一个日志分析平台,然后我们选择了ELK。主要用来分析:nginx日志,开发业务日志,系统和历史数据日志等、并且对接到了我们的告警平台。
2 K! d0 _: j9 Z. [5 E2 ~; m% A! r, {& D8 \3 `" n
6.云基础设施监控利器:Prometheu
+ x3 M% g) R9 [) F2 F* m) N
普罗米修斯是我这边最近主推的监控,一来是简单拿来即用的granafa图表。二来是我这边最近所遇到的困境:
4 n; a. H: u6 h' P+ |) k) D
基于云平台openstack 、k8s如何做监控、服务如何发现k8s资源并监控。微服务面临的挑战、我们监控的对象是动态可变的。无法进行固定有效配置。微服务实例间的调用关系非常复杂,如何通过网关等查找到我们相关的请求数据。例如我们这边网关是nacos、spring boot体系。监控系统必须在k8s基础上,快速水平扩容,这既是云原生的基本要求,也符合企业系统微服务化演进的实际情况。(罗辉)




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

本版积分规则

参加 ITIL 4 基础和专家认证、长河ITIL实战沙盘、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, 2022-5-23 04:02 , Processed in 0.112432 second(s), 31 queries .

Powered by Discuz! X3.4 Licensed

Copyright © 2001-2020, Tencent Cloud.

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