精华内容
下载资源
问答
  • windows平台 监控KafkaOffsetMonitor Kafka分布式实战(干货)spring cloud 实战(干货)mybatis 实战(干货)spring boot 实战(干货)React 入门实战(干货)构建中小型互联网企业架构(干货)python 学习持续更新...

    windows平台 监控KafkaOffsetMonitor Kafka

    1.概述

    Kafka的一个监控系统——KafkaOffsetMonitor。

    • KafkaOffsetMonitor简述
    • KafkaOffsetMonitor安装部署
    • KafkaOffsetMonitor运行预览

    2、KafkaOffsetMonitor简述

    KafkaOffsetMonitor是有由Kafka开源社区提供的一款Web管理界面,这个应用程序用来实时监控Kafka服务的Consumer以及它们所在的Partition中的Offset,你可以通过浏览当前的消费者组,并且每个Topic的所有Partition的消费情况都可以观看的一清二楚。它让我们很直观的知道,每个Partition的Message是否消费掉,有木有阻塞等等。

    这个Web管理平台保留的Partition、Offset和它的Consumer的相关历史数据,我们可以通过浏览Web管理的相关模块,清楚的知道最近一段时间的消费情况。

    Web管理平台有以下功能:

    • 对Consumer的消费监控,并列出每个Consumer的Offset数据
    • 保护消费者组列表信息
    • 每个Topic的所有Partition列表包含:Topic、Pid、Offset、LogSize、Lag以及Owner等等
    • 浏览查阅Topic的历史消费信息

    这些功能对于我们开发来说,已经绰绰有余了

    3、KafkaOffsetMonitor安装部署

    下载

    在安装KafkaOffsetMonitor管理平台时,我们需要先下载其安装包,其资源可以在Github上找到,考虑到Github访问的限制问题,我将安装包上传到百度云盘:

    安装部署

    KafkaOffsetMonitor的安装部署较为简单,所有的资源都打包到一个JAR文件中了,因此,直接运行即可,省去了我们去配置。这里我们可以新建一个目录单独用于Kafka的监控目录,我这里新建一个kafka_monitor文件目录,然后我们在准备启动脚本,脚本内容如下所示:

    #! /bin/bash
    java -cp KafkaOffsetMonitor-assembly-0.2.0.jar \
     com.quantifind.kafka.offsetapp.OffsetGetterWeb \
     --zk dn1:2181,dn2:2181,dn3:2181 \
     --port 8089 \
     --refresh 10.seconds \
     --retain 1.days
    

    启动命令的含义,首先我们需要指明运行Web监控的类,然后需要用到ZooKeeper,所有要填写ZK集群信息,接着是Web运行端口,页面数据刷新的时间以及保留数据的时间值。

    启动

    imageimage

    5.总结

    在运行KafkaOffsetMonitor的JAR包时,需要确保启动参数的配置正确,以免启动出错,另外,Github的上的KafkaOffsetMonitor的JAR中的静态资源有些链接用到了Google的超链接,所有如果直接只用,若本地木有代理软件会启动出错,这里使用我所提供的JAR,这个JAR是经过静态资源改版后重新编译的使用本地静态资源。

    • Topic:创建Topic名称
    • Partition:分区编号
    • Offset:表示该Parition已经消费了多少Message
    • LogSize:表示该Partition生产了多少Message
    • Lag:表示有多少条Message未被消费
    • Owner:表示消费者
    • Created:表示该Partition创建时间
    • Last Seen:表示消费状态刷新最新时间
    展开全文
  • 平台监控报表系统

    千次阅读 2014-05-06 08:59:31
    综合利用Nagios、Ganglia和Splunk搭建起的云计算平台监控体系,具备错误报警、性能调优、问题追踪和自动生成运维报表的功能。有了这套系统,就可轻松管理Hadoop/HBase云计算平台。 云计算早已不是停留在概念阶段...

    综合利用Nagios、Ganglia和Splunk搭建起的云计算平台监控体系,具备错误报警、性能调优、问题追踪和自动生成运维报表的功能。有了这套系统,就可轻松管理Hadoop/HBase云计算平台。

    云计算早已不是停留在概念阶段了,各大公司都购买了大量的机器,开始正式的部署和运营。而动辄上百台的性能强劲的服务器,为运营管理带来了巨大的挑战。

    • 如果没有方便的监控报警平台,对于管理员而言犹如噩梦,每天都将如救火队员一样,飞快地敲击键盘,用原始的Unix命令在多台机器中疲于奔命。
    • 如果没有好的日志管理平台,对于开发者Troubleshooting更是一件泪流满面的事情。
    • 而如果你是运维团队的总负责人,简洁清晰的Report则非常重要。Stakeholder们动不动就可能问起系统的SLA、机器的利用率等诸多问题,毕竟,公司为此投入了巨大的资金和人力。

    朋友们,当我们管理起公司寄予厚望的云计算平台时,当我们面对如此多充满挑战的实际问题时,该怎么办?

    概述

    我们在搭建趋势云计算平台时,遇到了很多的问题和挑战。开始搭建时,第一次来了那么多性能强劲的机器,我们在感到兴奋的同时,也不免有些顾虑。大家坐在一起讨论,问题就列了满满一白板。

    • 出了问题怎么办,有没有预警机制?
    • 有没有可视化的管理界面?
    • 管理平台需要自己开发吗?开发难度有多大?
    • 有没有开源的管理工具?
    • 那么多日志分布在各个机器上,有没有更有效的方法管理?
    • 能否生成好的报表?
    • 机器宕机,管理员能否收到短信通知?
    • 如何做性能调优?
    • 扩容升级时,能否给出依据?

    带着这些问题,我们开始了自己的云计算平台管理和运营之旅,一路走来,收获颇丰。现在基本上形成了如图1所示的一整套云计算平台监控体系。

    图1 云计算平台监控架构

    在这个系统中,我们综合利用了NagiosGangliaSplunk,搭建起云计算平台监控体系,使其具备错误报警、性能调优、问题追踪和自动生成运维报表的功能。有了这套系统,我们终于能够轻松管理Hadoop/HBase云计算平台了。接下来将简单介绍它们的特点和功能。

    Nagios:云计算平台的智能报警器

    总不能天天盯着机器看吧,因此我们首先关心的是机器的监控与报警。最理想的境界是:如果机器出故障了,我能第一时间处理;如果机器没有问题(最好永远没有问题),我能去喝茶、钓鱼和睡大觉。

    发现机器有没有问题,对我们而言不是什么难事。写个脚本,Ping一下IPTelnet每台机器的Service端口,如果增加了新机器就改改配置即可。但这样也太原始了吧,可视化效果差,不好维护,没有层次,不好管理,出不来报表,总不能老是用Excel人工写报表吧。有没有更好的方法呢?

    有,你可以用Nagios

    Nagios是一个可运行在Linux/Unix平台之上的开源监视系统,可以用来监视系统运行状态和网络信息。Nagios可以监视所指定的本地或远程主机以及服务,同时提供异常通知功能。

    Nagios可以提供以下几种监控功能。

    • 监控网络服务(SMTPPOP3HTTPNNTPPing等)。
    • 监控主机资源(处理器负荷、磁盘利用率等)。
    • 简单的插件设计使得用户可以方便地扩展自己服务的检测方法。
    • 并行服务检查机制。
    • 具备定义网络分层结构的能力,并使用“parent”主机定义来表达网络主机间的关系,这种关系可被用来发现和明晰主机宕机或不可达状态。
    • 当服务或主机问题产生与解决时将告警发送给联系人(通过电子邮件、短信、用户定义方式)。
    • 具备定义事件处理功能,可以在主机或服务的事件发生时获取更多问题定位。
    • 自动的日志回滚。
    • 可以支持并实现对主机的冗余监控。
    • 可选的Web界面用于查看当前的网络状态、通知和故障历史、日志文件等。

    Nagios最好用的地方就是它将这些每天管理员做的工作自动化,你只需设定好要监听的端口即可,它会默默地工作,帮忙定时地去检测服务端口的状态,一旦发现问题,会及时发出报警。报警可以是电子邮件也可以是手机,从而使得管理员第一时间就能收到系统的状况。

    Nagios的报表功能也很强大。管理员可以很容易地得到每天、每周和每月的Service运行状况。

    图2 SPN 后台运行的所有Service的当前状态

     

    如图2所示,红色部分清楚地标注有问题的机器,点开链接,就可以得到有问题机器的情况。虽然在HBase中,几台Region Server宕机不会对整体服务产生大的影响,但多少会影响到系统的Performance。而且,如果某几台Region Server频繁宕机,对整个系统的稳定性也会产生不好的影响。有了Nagios,我们可以快速定位有问题的机器,及时地将一些机器移除出HBase系统,待调整好了再上线运行,以保证系统的稳定性。

    现在,Nagios已经成为了很多公司必备的监控工具。只需要简单地配置,就可以实现强大的功能,将管理员从日常烦琐的工作中解放出来。

    有了Nagios,哪怕就是管理上千台机器,也不会手忙脚乱,而是有一种统领千军、运筹帷幄的感觉。

    Ganglia:看到云计算平台的方方面面

    Nagios的确不错,但你是不是真的可以喝茶、钓鱼、睡大觉呢?显然还不行。有了Nagios,你基本上可以做个优秀的救火队员,能在事发第一时间到达现场、处理事故。但如何防患于未然,真正做到运筹帷幄、游刃有余呢?

    我们需要更加精确的数据,能够看到云计算平台的方方面面,能根据这些数据,做出性能调整、升级、扩容等的决策,从而保证Service能够满足不断增长的业务需求。

    这时候,你需要Ganglia

    Ganglia是UC Berkeley发起的一个开源实时监视项目,用于测量数以千计的节点,为云计算系统提供系统静态数据以及重要的性能度量数据。Ganglia系统基本包含以下三大部分。

    Gmond:Gmond运行在每台计算机上,它主要监控每台机器上收集和发送度量数据(如处理器速度、内存使用量等)。

    Gmetad:Gmetad运行在Cluster的一台主机上,作为Web Server,或者用于与Web Server进行沟通。

    Ganglia Web前端:Web前端用于显示GangliaMetrics图表。

    HadoopHBase本身对于Ganglia的支持非常好。通过简单的配置,我们可以将HadoopHBase的一些关键参数以图表的形式展现在GangliaWeb Console上。这些对于我们洞悉HadoopHBase的内部系统状态有很大的帮助。

    Hadoopconf文件夹下面,找到hadoop-metrics.properties,配置好GangliaServer即可。这里要注意,Ganglia 3.0Ganglia 3.1的区别,它们使用了不同的class

    dfs.class=org.apache.hadoop.metrics.ganglia.GangliaContext31

    dfs.period=10

    dfs.servers={Ganglia_Server}:8649

    有了这些图表,HadoopHBase就不再是一个黑盒。无论是HadoopNamenodeDatanode,还是HBaseMasterServerRegionServer任何时刻的情况,都会一目了然。由于图标的跨度可以是小时、天、月甚至是年,这样,就可以非常方便地定期生成周报、月报和年报。同时,根据图中Metrics的状况,我们可以通过调整参数、增加内存和硬盘、增加机器等的方法调整单个机器或者整个Service的性能。

    图3 Hadoop其中一个DataNode的Metrics

     

    Nagios 最大的问题在于不能洞悉到Service内部的状况。像HadoopHBase这样的分布式系统,一个节点的故障并不等于整个Service的故障,影响的只是Service的性能。所以,在测定ServiceSLA时,我们不能以某一台机器的故障作为Service故障的评判标准。比如在我们的HBase SLA的设定上,我们定义了HBase Service完全不能工作的评判标准如下。

    • Master Server 联系不上。
    • 所有RegionServer 都无法联系上。
    • -ROOT- 表无法访问。
    • .META. 表无法访问。

      图4 Ganglia对Hadoop/HBase使用情况的监测

    那么,我们就可以根据这个规则定义SLA,通过定期调用HBaseAdmin相应API ,将测试的结果发给Ganglia。采用同样的方法,我们还可以自定义一些规则,监视HBase MasterZookeeper等的情况。

    通过这些方法,我们完全能够针对Hadoop/HBase使用的实际情况,做出Service级别而不是机器级别的监控系统并生成报表。

    此外,Ganglia还可以通过Server反馈回来的Load信息,给出各个机器的Load情况,给我们做升级和扩容提供依据。

    如图5所示,Ganglia分别会用不同颜色,标注出当前时刻的机器Load分布情况。如果Load过重,就应该检查机器的具体使用情况。

    图5 HBase Cluster Load Metrics

    Ganglia的安装配置,可以参考:http://www.spnguru.com/?p=604

    Splunk:像查Google一样查日志

    有了NagiosGanglia,算是成功了一大半。作为一名优秀的管理员,我们需要具备一定的Troubleshooting能力,对一些常见的问题能给出解决方案。那么,对日志的分析就必不可少。

    Hadoop/HBase的日志分布在各个机器上面,而日志之间关联性强。Client端的错误有可能是Region Server引起,而Region Server的错误有可能是Zookeeper导致。有没有一个统一的日志管理平台呢?

    众里寻它千百度,蓦然回首,我们找到了Splunk——日志界的Google

    很遗憾,Splunk不是开源的,但它的免费版本提供每天500MB日志索引。如果数据量较小,通过定义好Log的级别,基本上也能满足需求。但对于数据量较大的公司,就有些捉襟见肘。

    Splunk支持AdHoc的日志搜索,而且可以与Nagios配合使用。比如Nagios报警某台RegionServer端口不可达,我们收到Notification后,登录Splunk,直接搜索shutdownhost名称,找到RegionServer退出的日志。点击详细信息,分析日志,就能快速定位问题。如图6所示。

    图6 Splunk与Nagios配合使用进行日志搜索

     

    HadoopHBase有了进一步了解后,我们可以利用Splunk实时检测日志中的关键字,定义关键字规则,如监控“shutdown”、“quit”、“ERROR”、“Zookeeper Session Expired”等,一旦出现,利用SplunkNotification功能,发出邮件通知管理员,管理员通过Splunk定位问题,就可以在系统真正出现问题之前,对系统进行调整,防患于未然。

    具体Splunk的设置,可以参考:http://www.spnguru.com/?p=122

    总结

    搭建一套云计算平台,强大的监控管理系统是必不可少的。当然,任何工具都不是万能的,在实际维护过程中,我们也发现,NagiosSplunk经常出现误报,如果规则定义得不好,大量的警报邮件如潮水一样涌来,反而掩盖了真正的问题。可以说,在云计算平台的运维管理上,没有一劳永逸的事情,随着规模的不断增大和应用的不断多样化,需要大家不断地实践和总结。


    展开全文
  • 阿里云iot物联网平台监控设备在线离线状态解决方案 需求 目前使用阿里云的iot作为物联网平台应用,在整个系统内有很多设备,每天都会在固定的时间段内在线和离线。 我们需要监控这些设备的状态,如果设备在线或者...

    阿里云iot物联网平台监控设备在线离线状态解决方案

    需求

    目前使用阿里云的iot作为物联网平台应用,在整个系统内有很多设备,每天都会在固定的时间段内在线和离线。

    我们需要监控这些设备的状态,如果设备在线或者离线,给管理员发送通知(短信),以便让相关人员及时处理。

    在这里插入图片描述

    具体实现

    服务端订阅

    在产品详情的服务端订阅中,可以通过服务端订阅来接受iot平台的消息。

    在这里插入图片描述

    其中:

    • 服务端订阅,通过HTTP2通道推送,目前只提供了Java和**.NET**语言的SDK。
    • 服务端订阅 (推送MNS)。将物联网平台的消息推送到队列中,然后服务端基于SDK从队列中获取消息实现通信。

    由于语言限制,我们选择MNS的方式进行消息接受,需求是监控状态,所以只选择设备状态变化通知

    在这里插入图片描述

    同步监控消息

    通过上一步之后,阿里云会在MNS上创建一个对应的消息队列,如果设备有在线离线状态的变更,对应的消息就会被推送到对应的队列中。

    在这里插入图片描述
    列表的操作部分可以直接接收消息,当然这样做消息会被消费,如果队列已经写入系统逻辑,就需要谨慎操作。

    在这里插入图片描述

    拉取MNS队列并处理消息

    从控制台的拉取消息看,主要数据内容在payload中,通过文档可以查看,通过base64可以解析得到消息的详细内容。

    {
        "status":"online|offline",
        "productKey":"12345565569",
        "deviceName":"deviceName1234",
        "time":"2018-08-31 15:32:28.205",
        "utcTime":"2018-08-31T07:32:28.205Z",
        "lastTime":"2018-08-31 15:32:28.195",
        "utcLastTime":"2018-08-31T07:32:28.195Z",
        "clientIp":"123.123.123.123"
    }
    

    在这里插入图片描述
    下面列出PHP作为服务端处理的主要逻辑代码,作为参考。

    
        /**
         * 拉取状态队列消息
         */
        public function actionIotStatus(){
            $endPoint  = "https://************.mns.cn-shanghai.aliyuncs.com";
            $accessId = \Yii::$app->params['aliyun']['accesskeyid'];
            $accessKey = \Yii::$app->params['aliyun']['accesssecret'];
    
            $queueName = \Yii::$app->params['iot']['mnskey'];
            $client = new Client($endPoint, $accessId, $accessKey);
            $queue = $client->getQueueRef($queueName);
            $receiptHandle = NULL;
            try
            {
                $res = $queue->receiveMessage(30);
                $receiptHandle = $res->getReceiptHandle();
                //得到消息句柄
               $body =   $res->getMessageBody();
               $bodyArr = json_decode($body,true);
                $payload = json_decode(base64_decode($bodyArr['payload']),true); //解析
                $deviceName = $payload['deviceName'];
                //todo 这里写的逻辑是给管理员发送短信和通知
    
    			//删除消息,避免再次被接收到
                try
                {
                    $res = $queue->deleteMessage($receiptHandle);
                    echo "DeleteMessage Succeed! \n";
                }
                catch (MnsException $e)
                {
                    echo "DeleteMessage Failed: " . $e;
                    return;
                }
    
            }
            catch (MnsException $e)
            {
                echo "ReceiveMessage Failed: " . $e;
                return;
            }
        }
    

    总结

    • 详细看文档的好处在于一旦有需求就能找到最合适的实现方式。

    参考资料

    展开全文
  • 按《SRE Google运维解密》对监控的划分,监控可以分为“黑盒监控”与“白盒监控”,黑盒监控解决的是“系统哪些功能出问题了”,白盒监控解决的问题是“什么原因导致了上述故障”。通俗来讲——白盒监控可以帮助我们...

    按《SRE Google运维解密》对监控的划分,监控可以分为“黑盒监控”与“白盒监控”,黑盒监控解决的是“系统哪些功能出问题了”,白盒监控解决的问题是“什么原因导致了上述故障”。通俗来讲——白盒监控可以帮助我们快速定位问题原因,但要知道服务出了什么问题,还需要我们从黑盒监控入手。

     

    黑盒监控

     

    监控对象

     

    电商网站的哪些功能发生故障会使用户认为网站宕机?评价、优惠、库存等功能异常显然无法使我们得到上述的结论,而登录、加入购物车、下单、指定收货地址等功能中任一环节异常都会导致用户无法下单。因此,我们将电商平台的核心流程即订单流程功能点概括如表1所示,并且我们将核心页面的流量情况做出仪表盘展现出来(图1):

     

    表1 订单核心功能点▼

       
              核心页面 功能点
             

    首页

           
    页面元素是否加载正常;

    登录功能是否正常

             

    搜索页

           

    页面元素是否加载正常;

    按关键字搜索是否返回正确结果

             

    商详页

           
    页面元素是否加载正常;

    获取商品价格是否正常;

    检查商品是否售罄

             

    购物车页

           
    页面元素是否加载正常;

    加载购物车信息是否正常;

    查询购物车商品数量是否正常

             

    结算页

           
    页面元素是否加载正常;

    收货人、收货地址、联系方式、支付方式等信息是否可以正常添加

             

    下单页

           

    页面元素是否加载正常;

    提交订单是否正常

             

    支付页

           

    页面元素是否加载正常;

    支付是否正常

     

    图1 各核心页面流量PV▲

     

    监控经验

     

    触发反作弊策略

     

    用于订单监控的账号达到单位时间内允许登录、下单的上限被电商项目内部反作弊系统或下游交易系统判定为异常行为,从而出现弹出验证码、下单被告知已达上限等现象,导致订单监控抛出异常。

     

    针对此类问题可以在运营后台添加账号白名单,如果电商系统不支持此功能,可以通过多个账号轮询发起订单监控,最终聚合监控结果来规避此问题。

     

    在售商品库存被耗尽

     

    订单监控在预发环境进行调试时,频繁下单导致在售商品库存耗尽,影响了商品售卖。我们创建了测试商品(无法被用户浏览到)用于订单监控,规避此问题。

     

    服务变更导致订单监控异常

     

    在产品快速迭代的同时,代码实现逻辑、接口参数等也在不断迭代,如果监控滞后于服务代码的变更,必然会引起订单监控的异常,某电商项目近半年因变更导致订单监控异常的有:

    1. 登录密码加密逻辑变更

    2. 价格获取逻辑变更

    3. 商详页URL变更

    4. 电子发票获取逻辑变更

     

    支付页同样需要监控

     

    虽然因为电商关联众多支付平台(各大银行网银、移动支付工具)且订单监控会产生真实交易数据,导致我们无法监控真实支付环境节,但我们也需要确认下单流程能否正常跳转支付页。

     

    白盒监控

     

    白盒监控依靠的是系统内部暴露的性能指标。我们对用户请求进行了全链路的监控,包括CDN和高防访问成功率、不同地域不同运营商VIP访问成功率、模块及实例级别监控状态、第三方依赖状态的内容。

     

    监控对象

     

    从用户的使用角度,架构分为接入层、应用层、数据及依赖层、基础服务及实例,共4部分。

     

    接入层

     

    CDN、IP高防、云WAF、负载均衡。

     

    应用层

     

    应用模块,比如我们会对关键URL的服务质量进行语义监控,关键URL包括运维工程师经验得到的关键URL(可枚举的关键页面、关键接口),以及通过全量分析日志找出访问请求量TOP10的URL。

     

    数据及依赖层

     

    缓存、数据库、ElasticSearch、Kafka、云存储、外部API接口依赖。

     

    基础服务及实例

     

    实例出公网的连通性、内网机器之间的ping延时、性能指标(CPU、内存、网络流量、网络连接、磁盘IO、磁盘使用率等)。

     

    监控经验

     

    1. 对于处在公网的接入层组件,我们使用分布在全国各地的探测节点进行语义监控。

       

    2. 对于CDN既要监控各边缘节点缓存的静态资源是否可被访问到,同时也要监控未被缓存的静态资源回源访问是否正常。

       

    3. 报警阈值建议以百分比代替绝对值,可以帮助我们省去后续因流量、实例等规模变更导致反复调整报警阈值的问题。

       

    4. 以监控请求延时为例,我们推荐使用分组计数代替平均值,即延迟在0~100ms的请求量有多少,100~300ms的请求量有多少。原因是1%的异常请求耗时是平均值的10倍,通过平均值监控无法发现异常。

       

    5. 添加监控策略后一定要进行回归验证(比如在业务低峰期进行故障演练),不能等故障发生时再检验报警的有效性。

       

    6. 报警策略的设置会直接影响报警的准确性(比如3/3和3/5的策略,前者表示连续三个周期有三次不符合阈值规则就报警,后者表示五个周期中有三次不符合阈值规则就报警。3/3要更加严格,可以避免波动的监控报警,比如网络的可用性会受到网络抖动的影响;而3/5要更加敏感,适用于相对比较稳定的监控项,比如磁盘使用率)。

       

    7. 误报会降低运维工程师对报警信息的敏感性和警惕性,也会增加工作之外的生活压力,对于不能明确反映系统故障的报警项应该降级为邮件报警,遵循少即是多的道理。

    仪表盘

    仪表盘

     

    上述指标结合Grafana,可以帮助我们在服务发生故障时,快速精准定位,为实现服务第一时间快速止损提供有力保障。

     

    订单监控的仪表盘分为如下四个部分,各个指标一目了然:

     

    • CDN和高防访问成功率

     

    图2 仪表盘-CDN和高防访问成功率

     

    • VIP访问成功率

     

    图3 仪表盘- VIP访问成功率

     

    • 模块状态统计

    图4 仪表盘- 模块状态统计

     

    • 第三方依赖状态

    图5 仪表盘-第三方依赖状态

     

    常见故障及其预案建设

     

    运营商故障

     

    案例:电信运营商故障导致接入层IP无法提供服务。

    应对预案:流量切换。我们制定了流量切换即切换流量入口IP作为应对运营商故障的预案:即为电商系统分地域(华南、华北)、分运营商(移动单线、电信单线、联通单线、BGP多线)申请多个接入IP。在综合考虑网络质量、延迟等因素后,我们总结流量切换的优先级如下:

    1. 切换到同地域同运营商的流量入口

    2. 切换到跨地域同运营商的流量入口

    3. 切换到同地域跨运营商的流量入口

    4. 切换到跨地域跨运营商的流量入口

     

    接入层故障

     

    案例: CDN二级节点部分缓存机器服务故障,导致服务页面异常。

    应对预案:降级。我们通过添加一层域名指向,将IP高防、CDN、云WAF等接入层组件接入到系统中来,当这些组件部分节点或全部节点发生故障时,我们通过调用DNS接口快速完成CNAME变更,从而绕过故障组件。

     

    IDC故障

    案例: IDC无法访问公网,导致无法生成订单快照进而影响下单核心流程。

    应对预案:多AZ建设。由下图可知,当N大于1时,N+1值越高,代表冗余度越低,硬件成本越低,但隐含项是IDC建设成本高昂,即图中拆线斜率越小。出于成本及冗余度考量,我们推荐AZ个数设定为4个,即当N等于3时,我们可以取得硬件成本与服务稳定性收益的最大平衡:

    图6 硬件成本与服务稳定性收益趋势图

     

    应用层故障

     

    应对预案:以季度为周期,我们通过“chaos monkey”搭建故障演练平台,对多个电商项目逐个进行例行故障破坏演练,实现全产品线任意模块均可快速完成回滚、重启、扩容、迁移等预案。既可以提前暴露出架构中的薄弱环节、又可以让一线运维工程师、研发熟悉常见故障处理方法,熟悉应急故障组织管理流程。

     

    第三方依赖故障

    案例:因云缓存升级认证方式,导致登录页、商详页等页面无法展现,影响用户下单。

    应对预案:为应对云数据库、云缓存等故障,我们通过如下方法优先保证核心页面可正常展现:

    1. 构建多级缓存。

    2. 访问率较高的首页、商详静态化,并上线CDN。

    3. 抽取页面公共静态资源,并进行动静资源分离。

    4. 部分数据异步请求。

    展开全文
  • 大快搜索大数据可视化平台监控功能深度解析 在上一篇的文章中已经明确说过DKM作为大快发行版DKhadoop的管理平台,它的四大功能分别是:管理功能,监控功能,诊断功能和集成功能。管理功能已经给大家列举了一些做了...
  • 本篇承接上一篇《DKM平台监控参数说明》,继续就大快的大数据一体化处理架构中的平台监控参数进行介绍和说明。 DKhadoop大数据处理平台架构的安装相关文章已经分享过,详细的内容可以找一下看看。在上一...
  • 转载自 ... CentOS7.2部署Zabbix Server及Agent进行平台监控 Zabbix Server CentOS7.2_64 IP:172.17.8.112 Zabbix Agent CentOS7.2_64 IP:172.17.8.16(物理机) Zabbix Agent CentOS7
  • Kubernetes平台监控方案之:Exporters+Prometheus+Grafana

    万次阅读 多人点赞 2018-07-10 10:21:25
    监控平台本身的业务需求分析来看,我们至少应该希望通过Prometheus平台获取到以下监控数据: 性能指标 1.容器相关的性能指标数据(如:cpu, memory, filesystem) 2.Pod相关的性能指标数据 3.主机节点相关的...
  •   ...大数据平台监控(二):Ganglia与Nagios的整合 分类: linux2014-10-31 17:29 850人阅读 评论(1) 收藏 举报 监控大数据平台nagiosganglia 基本介绍 Ganglia:Ga
  • [Rtsp]海康网络摄像头基于RTSP协议的windows平台监控 分享| 时间:2014-07-09 17:54来源:酷播 极酷网页播放器 基于RTSP协议的windows平台监控。 1.1 选取海康网络摄像头(支持RTSP,标准H.264 RTP封装的...
  • 360容器平台监控实践

    2018-12-13 18:00:00
    女主宣言360 近年来上线了容器云平台,给团队工作带来了一些便利,同时也给运维工作带来了很多挑战。InfoQ记者张婵10月30日采访整理,首发于公众号“高效开发运维"。P...
  • 平台监控平台监控项种类繁多,有hdfs、yarn、zookeeper、kafka、storm、spark、hbase等平台服务。每个服务下有多种角色类别,如hdfs服务中包括Namenode、Datenode、Failover Controller、JournalNode 。每个角色...
  • kubenetes平台监控cAdvisor查看

    千次阅读 2016-10-20 11:46:21
    cAdvisor是谷歌开源的一个容器监控工具,该工具提供了webUI和REST API两种方式来展示数据,从而可以帮助管理者了解主机以及容器的资源使用情况和性能数据。 cAdvisor集成到了kubelet组件内,因此可以在kube集群中每...
  • influxdb是一个时序数据库,非常适合用来记录监控信息。 拉取镜像 docker pull tutum/influxdb 启动镜像 docker run -d -p 8083 : 8083 -p 8086 : 8086 -e ADMIN_USER = "root...
  • 原文:Prometheus unbound: Open ...Prometheus是一个广泛监视企业IT事件(包括容器)的开源监控系统,本周发布了1.0版本。这也是CNCF(Cloud Native Computing Foundation,云端本地计算)的第二个产品。这个组织致...
  • 文章来源:...   大数据平台监控(一):Ganglia在集群中快速安装方案 分类: linux2014-10-29 15:55 554人阅读 评论(0) 收藏 举报 集群ganglia快速安装ganglia安装集群监控 基本介绍
  • 关于iOS平台监控和直播的实现

    千次阅读 2016-10-07 18:12:58
    平台之间传递视音频以及数据 。 与 RTSP + RTP 组合提供流媒体服务的方式不同 , RTMP 协议本身既可以传输多媒体数据也可以控制多媒体播放 。 RTMP 协议使用 TCP 协议作为其传输层的网络协议 。 TCP 是面向连接的...
  • Ganglia是UC Berkeley发起的一个开源集群监视项目,设计用于测量数以千计的节点。Ganglia的核心包含gmond、gmetad以及一个Web前端。...利用ganglia监控整个大数据平台,可以显著的提高平台的运维效率。
  • 由于上证所,深交所level1,level2金融数据服务器在上午9:00开始到11:30和下午13:00开始到15:30一共5个小时的时间内流量比较大所以被监控服务器的网络流速算是一个被监控的重要指标。可以通过累加一段时间内各个...
  • psutil is a cross-platform library for retrieving information onrunning processes and system utilization (CPU, memory, disks, network)in Python. https://pypi.python.org/pypi/psutil .../usr/bi

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 24,650
精华内容 9,860
关键字:

平台监控