聊聊监控系统

1、 为什么需要监控系统

作为运维者,第一个接触的基本上是监控平台,各种各样的监控,看各种各样的指标,好像没有监控就觉得不正常,那么为什么需要监控呢?

监控:预防故障,例如当磁盘空间增长到一定的程度的时候,就会产生故障,这个时候监控系统的作用就是当达到一个阀值的时候,发出告警,然后进行处理。

监控:预测变化趋势,例如我的分布式文件系统,每天数据增长1T空间,那么我总共有多少空间,剩余空间大小,是否要进行扩容等操作。

监控:当故障发生的时候,能提供给我基本信息给与我排查的思路,例如redis不可读,是否能看到是哪个实例,能看到相关的日志信息,能测试是否刻读写,能查看哪个是master。

监控:监控系统关键指标,例如对于web服务器来说,响应速度,来判断是否中间件有问题,是否数据库有问题,还是网络有问题;活跃的用户数,每天我的网站有多少用户访问;有多少新注册的用户。

2、 如何选择监控系统

看过好多监控系统,各种各样的公司使用的监控系统各不一样,有的用nagios,有的用zabbix,有的自研,so much more choice。。。

选择监控系统的时候,无非是需要几个特性的支持:

是否支持多主机监控,例如监控一个分布式系统的集群;

是否支持多维度的数据分析,例如一个主机上有多少个容器,一个主机上容器总共使用了多少内存,每个容器又使用了多少内存;

是否支持各种各样的告警方式,设置一个阀值,可以声音告警,可以颜色告警,可以邮件通知,可以短信通知,可以短信通知,可以电话通知

是否支持告警过滤或者屏蔽,当一个告警是相同的时候,充斥着大量的告警,平台是否支持暂时忽略,或者只通知几次,后面在界面上显示告警的内容,开始发生的时间,发生的次数;

3、 告警系统的优化

当一个告警系统每天发出的告警数量超过10条,是不是应该优化?这个主要看运维的人数,如果每个告警都需要人工进行干涉,那么这个告警数量可能过多,要么优化运维的系统,要么把开发加入运维的团队中进行on call。

当一个告警系统每天发出的误报数量在5条以上,如何优化?如果是正常的动作导致,那就不应该告警,例如在进行发布应用的时候,一个port down,这种告警就不应该发生,应该做到自动屏蔽。

当一个告警系统发出了迷惑性的告警,何为迷惑性,就是监控平台发出了告警,但是却找不到明确的错误信息,那么这种告警必须进行优化,在告警的时候,应该给出具体的报错信息,总是有人喜欢自定义告警,然后不给出本来的报错信息,非要进行封装一层。。。。自作聪明。。。从现象直接能看到本质问题,这种告警平台是最好的。

4、 容器的监控

对于一个容器系统,我需要监控哪些指标?

宿主机的负载,内存,CPU,磁盘,网络;

容器数量,容器的运行状态,容器的使用的内存,进程,cpu,网络,磁盘;

其实,当你使用了k8s管理平台之后,可能你会发现,这种监控可能没有太大的含义。。。

当使用了这种重量级的管理平台之后,都是有自愈功能的。。。。就是当一个容器里面运行着java进程,OOM被杀之后,k8s的管理平台会自己再次创建一个容器,自动进行dns解析,自动进行负载均衡,自动进行服务。。。self-healing。。。金刚狼的能力。。。

分析OOM,那是媛们的事情。。。这个时候,运维在干啥,无须进行人工干涉,传统运维都是出现OOM,手动重启下java进程,现在。。。。运维平台自己干活了。。

期望状态?你期望服务是什么状态,它会自动进行调度到最终的状态。。。你要几个副本进行负载均衡,就给你几个。

你要进行升级,自动rolling进行更行,先创建一个高版本的镜像,然后删除一个实例容器,负载均衡加入轮询。。。怕发布的时候中断服务?那是不可能的,7*24。。so easy。。。

要进行扩容,都不需要手动进行处理,可以根据流量自己进行判断,流量太高了,就自动进行创建容器,进行负载均衡。。。。流量降低了,自动销毁容器,进行负载均衡。。。

对于这种能自我管理的应用或者服务,还需要监控么。。。。

充其量。。。只要做好响应的规划就好了,给你多少内存,给你多少CPU,给你多少磁盘,偶尔看看增长趋势。。。。so。。。

但是。。。在出现故障的时候,还是需要告警平台。。。

适用的场景不同,从而选择不同,当你需要一个能使用shell直接连接的时候,监控工具weavescope,很是漂亮。。。

当你需要进行多纬数据分析的时候,并且设定阀值,自动进行告警的时候,那么prometheus还是很酷的。

5、 IAAS的监控

在很多的时候,构建一个IAAS平台,一种自我测试的监控系统,那是相当酷的。。。我喜欢

何为自我测试呢?

例如构建了分布式的文件系统,相隔几分钟,自己上传一个文件,访问文件,删除文件,如果这个测试能通过,那么表示基础设施完全正常。

例如构建一个DAAS,数据库即服务,那么相隔几分钟,自己创建一个mysql的master和slave,然后写入数据,HA切换,然后删除,如果这个测试能通过,那么表示基础服务完全正常。

这种思想还是极好的。

监控平台如何构建?不想大段的论述了,据我所知,python。。。提供各种各样的restful API,然后在前台界面中进行各种各样的接口调用就好了,其实就是拆。。。将原来的一个功能,分拆为很多很多接口,定义endpoint就好了,其实这种正好切合了容器的微服务思想。。。

本文分享自微信公众号 - SRE运维实践(gh_319dd73ec076)

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2018-03-06

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏kubernetes中文社区

Kubernetes 中 traefik ingress 的使用

简单的说,ingress就是从kubernetes集群外访问集群的入口,将用户的URL请求转发到不同的service上。Ingress相当于nginx、apac...

18530
来自专栏陶辉笔记

linux内核调度算法(3)–多核系统的负载均衡

多核CPU现在很常见,那么问题来了,一个程序在运行时,只在一个CPU核上运行?还是交替在多个CPU核上运行呢?Linux内核是如何在多核间调度进程的呢?又是内核...

30530
来自专栏杨建荣的学习笔记

MySQL分布式高可用的一个补充

前几天码了一篇迁移到MySQL的架构演进的文章,迁移到MySQL的架构演进(一),收到的反馈还不少,看来大家碰到的都是共性的问题。

11820
来自专栏kubernetes中文社区

Kubernetes服务发现之Service详解

Kubernetes Pod 是有生命周期的,它们可以被创建,也可以被销毁,然后一旦被销毁生命就永远结束。通过ReplicationController 能够动...

17120
来自专栏Java架构

微服务之架构技术选型与设计

本文主要介绍了架构技术选型与设计-微服务选型,Spring cloud 实现采用的技术,希望对您的学习有所帮助。

18750
来自专栏kubernetes中文社区

kubernetes 之 master高可用集群搭建

1、k8s的node默认已经有高可用了,因为在pod会随机分配到各个node上,如果有pod挂了,就会分配到其他node上,所以这里主要是做一下master的高...

52830
来自专栏lakezhong的专栏

ECMP在Linux内核的实现

ECMP(Equal Cost Multi Path),中文名叫等价多路径,是路由里的一项技术,作用是,在IP交换网络中存在到达同一目的地址的多...

63540
来自专栏lakezhong的专栏

一个简化的可横向扩容的高可用的四层接入网关的原理说明——ECMP

图1是一个简化的可横向扩容的高可用的四层接入网关的组网图,主要由入口路由(Ingress Router)、负载均衡服务器(Load Direct...

40750
来自专栏kubernetes中文社区

Kubernetes 使用Service暴露应用

(凡人皆有一死来描述pod,没有比这跟准确的了)。事实上,Pod是有生命周期的。当一个工作节点(Node)销毁时,节点上运行的Pod也会销毁,然后通过Repli...

15160
来自专栏Hadoop实操

0656-6.2.0-如何配置Haproxy高可用

Fayson在之前的文章有提到《如何使用HAProxy实现HiveServer2负载均衡》《如何使用HAProxy实现Impala的负载均衡》集群采用了hapr...

19920

扫码关注云+社区

领取腾讯云代金券

年度创作总结 领取年终奖励