精华内容
下载资源
问答
  • 用 Python 开发一个企业级的监控平台

    万次阅读 2018-01-22 00:00:00
    然后在服务端写一个独立的微服务接口,负责接收客户端上传的监控信息,然后将数据进行处理后插入MongoDB,以供前端进行数据调用,下面代码截图是一个API插入的示例。 这个API通过HTTP Server的方式启动,然后监听...

    作者简介:

    郭宏泽,现任为胜科技技术总监,高级咨询师,IT解决方案专家。拥有12年IT行业工作经验,其中有8年一线运维经验,4年运维开发经验,曾就职于易车网、电信云计算、跟谁学等公司。开发过日志分析系统、CDN流量计费结算系统,自动化容器管理平台等。精通Linux相关技术及Python、Shell、JavaScript等语言。现任多家大型公司咨询顾问,已帮助IBM、惠普、朗讯等多家跨国公司进行容器化及DevOps转型。

    AdminSet开源运维平台创建者,DevOps Master,全球运维大会金牌讲师,高效运维社区核心成员。

    Python是一个浩瀚如烟的旷阔领域,有着丰富的应用场景,业务系统、云计算、大数据、人工智能都有Python的身影。

    Python是一个易于学习的语言,是一个以简洁实用为宗旨的语言,我在以前的工作中接触过PHP、C#、Java等语言,但当我第一次看到Python的时候,有一种相见恨晚的感觉,心里冒出一句话“就它了”。

    Python的兴起是由于云计算时代的来临,当IaaS逐渐成熟、PaaS百花齐放的时代到来时,Python终于迎来了它的黄金时代。

    由于入门简单、语法精炼、功能库丰富,Python在计算机领域渐渐成为了一种通用语言,无论是应用、平台还是工具,哪个没有Python的API接口或是SDK呢?这正说明了Python的实力。正因为这些原因,Python在DevOps领域成为一种标准,而且不可替代。

    如何选择Python版本

    Python目前有两个主流版本,Python 2和Python 3,而且都在维护更新,且这两个版本互不兼容。

    Python 2和Python 3的区别

    我们先来看看Python 2和Python 3 之间的主要区别,参见下表。更多新特性请参考:https://docs.python.org/3/whatsnew/3.0.html。


    Python 2

    Python 3

    Print 变函数

    Print“abc”

    Print("abc")

    旧式类和新式类

    只有新式类

    运算

    1/2=0

    1/2=0.5

    字符串格式化

    %,Format

    Format,%

    xrange

    xrange

    Range

    long重命名为int

    Long,int

    Int

    包导入

    相对导入

    绝对导入

    源文件编码

    Ascii

    utf8

    从Python社区官方态度来看,官方强烈建议直接学习Python 3,因为Python 2只会维护到2020年。那么看到这儿,可能你会觉得应该直接学习Python 3了,但实际上不是这样,我们必须从Python 2开始。

    如果我们对一件事举棋不定,那么最好看看别人是怎么做的,下图是Python各版本在2016年7月和8月的下载量统计图。

    通过数据换算(Y轴是指数),Python 2.6和Python 2.7的下载量占比超过90%。数据不会说谎,事实就是当前仍然是Python 2主导的世界,Python 2作为大部分应用和工具的基础,还会在相当长的时间内存在。

    为什么会出现这样的情况呢?原因有三:

    • 技术的发展是快的,但是在生产中落地是非常缓慢的。

    • 如果Python 2就能用,为什么非得升级到Python 3呢。

    • Python 3不是所有操作系统的默认解释器,在系统环境中使用Python 3会消耗巨大的成本。

    出于实用主义考虑,如果能用螺丝刀解决的问题绝不会用一个电钻来解决。使用Python的人大多数是实用主义者,所以出现了在Python3出现多年以后仍然无法普及的现象。

    如何学习Python

    Python 2和Python 3还有一种平衡的方法,可以同时兼容两个版本,那就是在Python 2中引用Python的__future__库。__future__库里面包含了Python 3的大多特性。 

    从Python 2开始学习,向Python 3演进,使用Python 2.7版本,利用Python 2.7的语法兼容性,尽量使用Python 2版本和Python 3版本都能兼容的语法,这样既保证了在现有系统中的兼容性,又为将来全面向Python 3迁移做好了准备。

    事实上Python 2的最新版本Python 2.7和Python 3的差异不超过10%,可以说是比较小的,另外Python 2.7已经尽可能地弥合了Python 2与Python 3之间的差异,做到了尽可能多地兼容Python 3。

    比如在Python 2.7中使用print “hello world”和 print(“hello world”) 两者都是可以的,但我们应该使用后者,以便全面向Python 3版本迁移。

    最后给出几条学习建议:

    • 从Python 2.7开始学习,不要使用Python 2.7以前的版本。

    • 了解Python 3弃用的语法和包,在书写代码过程中尽量避免。

    • 不要使有Python 3.5之前的Python 3.x版本。

    • 尽量多地使用Python 2与Python 3相兼容的语法。

    • 熟悉__future__库。

    • DevOps工程师应主要使用Python 2.7。

    • 业务开发工程师可以直接使用Python 3.5。

    开发一个简单的监控平台

    监控对运维的重要性

    “ 因为你是我的眼,让我看见这世界就在我眼前”,这是一首耳熟能详的歌曲《你是我的眼》。监控,对于运维工程师来说就是眼睛,如果没有监控,运维工作就无从谈起;如果没有监控,运维工程师就成了盲人。

    一个良好的监控系统可以快速地发现并定位问题,减少宕机时间,提高故障处理速度,减轻运维工作压力,甚至可以促进家庭和谐。

    但是对于这么重要的系统,我发现很多公司都做的都不好:要么监控不到位,很多盲区;要么监控过多,太多无效条目导致报警麻木;要么监控系统五花八门,工具琳琅满目,重复监控,条理不清,等等。

    我认为产生这些问题的原因主要有两点。其一,人的问题,是我们的运维工作人员对监控没有深刻的认识,经验不足;其二,工具的问题,没有得心应手的工具,开源、闭源,五花八门,难以统筹高效利用及整合。

    以前我们习惯于拿来主义,有问题需要用工具,上网查查别人都在用什么,我也下载一个试一试,差不多就行了。

    但是现在时代变了,IaaS、PaaS、SaaS的结构越来越复杂,对于运维工程师说来,必须对监控有深度定制或二次开发的能力才能满足当下的需要。

    所以我的建议是,可以考虑自研一套监控系统,这固然有压力,但是一旦成功,收益巨大。俗话说万事开头难,开了头其实就不难。我以自己的经验来说说自写一套监控系统的套路。

    服务器端

    前端开发主要会用到大量的页面元素,我建议使用目前开源的adminlte,这个前端框架元素非常丰富,页面简洁,比较适合作为监控系统的基础页面框架。

    adminlte本身是基于Bootstrap开发的,对于我们将来进行深度页面定制是非常友好的。图表库内置了font awesome和iconic,表单整合了Select2,adminlte几乎能满足你的任何要求。

    在图形展示上,建议使用Echarts监控图表(参见下图),它由百度团队开发维护,资料文档非常丰富,在图形质量、异步获取和加载方面都比较成熟,要把它嵌入到系统中,只需要引入一个JavaScript包发即可。

    后台开发使用Django,主要是快,无论是Model、FORM、Auth等系统,还是在插件中间件的丰富程度、文档的完善度上,Django都具有绝对优势。通过将平台微服务化,Django本身的速度劣势将被弥补。

    在监控数据的设计方面,对资产信息、用户关系等的监控肯定要使MySQL这种关系性数据库,但是对于监控条目的处理就得三思而后行了,我见过很多项目都是把监控条目直接丢到MySQL里,导致后期扩展困难,数据库成了监控平台的巨大瓶颈。

    我的方法是将所有监控信息全部写入MongoDB这样的NoSQL数据库,无论是在可扩展性还是性能上,它们都能应对当前海量的监控数据需求。

    然后在服务端写一个独立的微服务接口,负责接收客户端上传的监控信息,然后将数据进行处理后插入MongoDB,以供前端进行数据调用,下面代码截图是一个API插入的示例。

    这个API通过HTTP Server的方式启动,然后监听客户端的POST数据,接收到数据后以服务器本地时间为基准,打上监控数据的时间戳后存入MongoDB,并以主机名为依据,直接进行分表。

    客户端

    客户端的开发相对来说比较简单,主要引入了requests 进行HTTP动作的处理,引入了Schedule进行定时上报和计划任务,引入了Psutil进行性能信息采集。

    客户端的性能数据主要依靠Psutil采集,Psutil有非常丰富的监控接口,能够轻松实现对CPU、内存、网络、磁盘的监控。

    获取磁盘信息的函数截图如下:

    通过Psutil提供的接口采集性能信息,然后将结果封装成一个Json数据,使用Requests Post提交到服务器的API接口中去——一次监控过程就完成了。

    监控平台的通道也就打开了,以后监控任意条目的套路不过如此。NPM、中间件监控、APM,不都是这样吗?采集数据、上报、存盘并展现。

    开发规划

    服务端、客户端,数据库和图表展现完成之后,一个简单的监控平台雏形就完成了。这只是一个开始,DevOps的核心思想是持续学习、持续迭代,在这个过程中不断完善。有了平台和架子,我们就可以不断地添砖加瓦。

    • 对于硬件监控,可以通过Linux系统命令(比如smartctl、dmidecode等)来获取相关信息。

    • 对于NPM、CPU、内存、磁盘、网络和进程,可使用Psutil来完成。

    • 对于中间件监控,比如MySQL、Nginx,可以通过命令行或是中间件的监控接口来采集数据。

    • 对于某些自定义监控,比如监控某个文件大小、某个目录的文件数、某个文件的属性,可以用Shell来完成。

    • 对于APM、应用程序指标、函数调用、响应时间、业务数据等,我们可以通过埋点、API或是JVM嗅探来完成。

    • 对于报警系统,可以使用邮件、微信等形式,这个可以根据企业自身的需要来设置,都是十几行代码即可搞定。

    如果我们使用开源软件Cacti Zabbix,在实现和整合上都会比较麻烦,很多时候会受制于软件原有的结构,二次开发比较麻烦。

    所以,我们何不自己写一个,将所有的控制权都放在自己手上呢?况且又不是特别难,在开发平台的过程中,你的Python技术、软件工程能力都会有很大的提升,你将能够快速实现企业的需求,而不是跑到社区去哭诉“给我加个功能吧”。

    Python 开发三十六计:


    如果您对其中内容表示质疑,欢迎指出并发表意见,一经采纳,您将成为内测版读者,《DevOps三十六计》在年末的第一批印刷将在第一时间送到您的手中。


    想与郭宏泽老师直接交流?请加入 DevOps 三十六计交流群

    入群请加微信:gaoxiaoyunweiliuce


    关注 DevOps 三十六计公众号

    我们将长期发布 DevOps 三十六计完整内容

    更多相关文章阅读

    用 Python 代码自动抢火车票

    携程运维自动化平台,上万服务器变更也可以很轻松

    智能运维就是 由 AI 代替运维人员?

    看腾讯运维应对“18岁照片全民怀旧”事件的方案,你一定不后悔!

    运行无间:阿里巴巴运维保障体系的一种最佳实践

    芳华永在!一个老运维的20年奋斗史

    饿了么异地双活数据库实战

    运维版《成都》,听哭了多少人...

    阿里万亿交易量级下的秒级监控

    IT 运维的救赎——顺丰运维的理想践行


    腾讯 SNG 团队首次系统性披露其运维体系:


    第九届GOPS全球运维大会将于2018年4月13日-14日在深圳召开。大会为期2天,侧重方向包括AIOps、运维自动化和 DevOps。


    为期两天的大会将涵盖众多先进的技术与理念:



    点击阅读原文,进入大会官网

    展开全文
  • 网络性能监控指标

    千次阅读 2019-03-12 23:45:11
    网络性能监控(Network Performance Monitoring NPM)是指用户体验到的测量,诊断和优化网络服务质量的过程。NPM是应用程序性能管理(Application Performance Management APM)的补充。...测量的一个方向是...

    网络性能监控(Network Performance Monitoring NPM)是指用户体验到的测量,诊断和优化网络服务质量的过程。NPM是应用程序性能管理(Application Performance Management APM)的补充。

    网络性能监控解决了网络在最终用户体验中的作用。这包括以下指标:

    • Latency 延迟 - 获取数据包响应所需的时间。这是双向测量的。测量的一个方向是查看本地主机(如应用程序或负载平衡服务器(如HAProxy或NGINX))何时将数据包发送到远程主机并计算获取响应所需的时间。另一个方向是查看从远程主机收到数据包的时间,并测量应用程序(服务器)发送响应所需的时间。
    • 无序数据包的数量和百分比 - 这是一个重要的衡量标准,因为TCP不能将数据传递给应用程序,直到字节顺序正确。少量无序数据包通常不会对事物造成太大影响,但是当它们变得太高时,它们将影响应用程序性能。
    • TCP重传 - 当网络路径的一部分过载或出现性能问题时,它可能会丢弃数据包。TCP通过使用ACK来确认已接收到数据,从而确保数据的传送。如果发送方没有从接收方获得及时的ACK,它将重新发送具有未确认的TCP段的数据包。当TCP重新传输超过非常低的单个数字百分比级别时,应用程序性能开始下降。

    NPM解决方案传统上使用设备部署模型。该设备具有一个或多个接口的PCAP探针,连接到路由器或交换机跨接端口或中间数据包代理设备(例如Gigamon或Ixia提供的设备)。设备将通过span端口传输的所有数据包记录到内存中,然后记录到长期存储中。在虚拟化数据中心中,可以使用虚拟探测器,但它们也依赖于一种或另一种形式的网络链路。

    从硬件和软件许可的角度来看,物理和虚拟设备的成本很高。因此,在大多数情况下,将PCAP探针部署到网络中的几个选定点仅在财务允许的情况下是可行的。此外,设备部署模型是基于拥有相对单一应用程序实例的集中式数据中心的假设下而开发的。随着云和分布式应用程序模型的激增,数据包捕获的设备模型不太可行,因为在许多云托管环境中,甚至无法部署虚拟设备。

    用于网络性能监控的高度可扩展的SaaS模型将监控功能与存储和分析功能分开。通过部署轻量级监视软件代理来完成监视,这些代理可以导出在服务器和开源代理服务器(如HAProxy和NGNIX)上收集的基于PCAP的统计信息。导出的统计信息将发送到SaaS存储库,该存储库可以水平扩展以存储未汇总的数据,并为警报,诊断和其他用例提供基于大数据的分析。虽然基于主机的性能指标导出不能提供原始PCAP的完整粒度,但它提供了一种高度可扩展且经济高效的方法,可以无处不在地收集,保留和分析关键性能数据,从而补充PCAP。

    展开全文
  • 视频监控技术发展方向与市场定位

    千次阅读 2006-01-26 23:46:00
    、视频监控发展背景1.1安防行业发展状况 安防行业发展迅速且已初具规模,截至到2004年底,安防行业市场规模400多亿元。其中,安防设备市场45%,安防工程市场55%,出口占8%,监控约占一半,年销售额不足1000万...
      
    

    一、视频监控发展背景

    1.1安防行业发展状况

        安防行业发展迅速且已初具规模,截至到2004年底,安防行业市场规模400多亿元。其中,安防设备市场45%,安防工程市场55%,出口占8%,监控约占一半,年销售额不足1000万元的小企业占90%以上,预计2010年实现产值1500亿元。安防行业年均增长速度25%,从业企业15000家,人员100万。安防行业正由启动期走向发展期,现处于发展期,但离成熟期还很远。行业产业链基本形成,管理链正在逐步建立,缺乏上位法导致行业管理在部分领域出现真空。

        安防行业发展潜力巨大,市场会不断扩大,需求将更旺盛。现行安防市场准入门槛较低、竞争激烈,市场秩序很不规范。行业初步形成了珠江三角洲、长江三角洲、京津地区三大安防产业集群。安防行业形成以视频监控、出入口控制、入侵报警、防爆安检为主的十几类、8000多个产品。 安防应用范围日趋广泛,安防应用层面日益深入,但安防行业管理出现一些“真空”地带,这构成了安防行业发展的机会与威胁同时存在。

        1.2安防行业发展的机会与威胁

        国际反恐形势、西部开发与东北振兴、2008奥运与上海世博会、国内城镇化与快速城市建设、平安城市建设、部分应用领域安全事故频发这几方面构成了安防行业发展的主要积极因素;而安防内外部环境影响的其他条件多数是正反两方面都有,例如加入WTO、多行业大企业进军安防市场、国内安防产品外销形势,而安防市场秩序的影响则主要是负面的。

        目前行业协会为解决存在的问题正牵头着手建立安防五大体系:国家与行业的技术规范和标准体系;行业认证评定体系、行业培训体系、安防工程建设的系统安全评估、评价体系,行业信用体系。

        1.3安防技术发展存在的问题与趋势

        国内安防技术发展存在的主要问题有:1、高技术安防产品研发能力低,新产品与核心技术多依赖进口,未能形成有序的科技创新体系;2、现有安防技术系统不适应集成化、数字化、网络化、智能化要求;3、安防管理的技术支撑环境差,标准滞后,产品检测、认证评估手段较低;4、安防系统或网络运行管理不规范,接处警机制不健全;5、安防基础理论研究薄弱,制约安防技术效能发挥。
    安防技术发展的趋势主要表现为:1、数字化、网络化、智能化、集成化是方向;2、逐步建立健全安防科技创新体系;3、大力发展4C技术(通信/计算机/控制/多媒体显示技术)、智能建筑5A系统和智能运输ITS系统;4、网络技术与多种安防技术实施集成研发;5、创建并完善各级综合安全服务网。社会治安动态监测体系、城市预警体系和平安城市建设是国内安防行业的新机遇。

        1.4安防企业与市场存在的问题

        国内安防企业存在的主要问题有1、工程商施工资格不明确,有能力的系统集成商较少;2、企业管理能力欠缺,应变与抗风险能力不足;3、企业品牌意识缺乏,各类产品发展不均衡,人员素质有待提高;4、企业市场开拓力度不够,产品应用普及推广力度不足;5、企业、生产线数量多,平均生产规模小,利润低,多重身份交叉严重。

        国内安防市场存在的主要问题有1、地区、行业垄断,区域市场发展不平衡,条块分割现象严重;2、部分地区假冒伪劣泛滥,夸大代理的问题突出,走私现象严重,市场监管乏力;3、无序竞争、竞相压价,造成市场混乱;4、发展快,但企业整体规模较小,准入门槛不高。

        二、视频监控技术发展概述



        2.1 视频监控技术发展背景

        为了和电脑对应,传统的模拟设备已经开始向数字设备转换;数字资料已经开始方便地传送和管理;可以借助安防网络设备连接其他的数字产品来扩大应用范围;远程传送的需求也越来越大,这表明视频监控技术已全面进入数字时代。网络信息的发展;许多建筑物已经具备局域网和广域网;有许多要求是在PC控制下的升级系统;图象处理用PC有许多的弹性;多种的数据保存硬件(硬盘、备份光盘等)发展很快,基础设施的发展为视频监控技术的发展创造了条件。

        2.2视频监控技术发展

        视频监控技术发展经历了模拟监控、数字监控正在向大规模网络监控发展。视频监控系统的各组成部分――前端视频采集、视频传输、视频记录、控制、显示部分技术发展很快。

        2.3需求新特点呼唤视频监控技术变革

        监控点数量多且分散;网络化建设使网络视频传输变得经济、可行;海量数据传输和存储的需求;设备管理重要性增强甚至超过图象监控本身;管理者流动性增强;施工、布线成本昂贵,要求简化布线降低投资;信息安全受到普遍关注。市场的需求呼唤视频监控技术变革。

        2.4视频监控的几项关键技术

        视频监控的关键技术主要有视频采集压缩、视频信号可靠地传输、信息存储调用的智能化与系统的集中管理。

        2.5视频监控技术发展方向

        视频监控技术发展方向为分布采集集中管理、高品质图象压缩处理、开放标准统一接口、统一认证确保安全、操作人性化,以及功能集成化、结构模块化和传输多样化。

        三、视频监控产品发展概述



        3.1 IP监控系统是今后的重要发展方向

        由于视频监控与网络技术发展,IP监控系统越来越具有优势。IP监控系统与传统的模拟监控系统的比较见下表:

     
    IP监控系统
    模拟监控系统
    成本
    安装简便,节约布线;运作费用较低;中心控制,硬盘记录,通过网络存储,集中维护与操作;
    系统拓展,在网络上直接加网络摄像机
    同轴线缆,安装困难;
    运作费用高;本地录像,模拟磁带记录,在前端各点维护与操作,常换磁带;系统扩展工程庞大
    系统发展
    单一系统可覆盖广阔区域;
    便于拓展,只要“接入和使用”
    点对点
    系统连接复杂、混乱
    用户接入
    通过网络远程接入监控
    无远程接入,本地监控
    运作和管理
    远程监视和控制;
    通过网络远程记录(硬盘/磁带)
    无远程监视和控制;
    使用模拟磁带在前端记录和维护
    质量
    图像记录无衰减;
    使用数据库,记录数据便于检索;
    远距离传输图像信号损失很少。
    图像记录有损失;
    远距离传输图像信号损失大。
    智能
    用软件处理数字信号实现不同应用

     

    3.2 网络视频监控产品的比较 

     

        从网络视频监控发展过程中的几种形态来看,DVR出现之后,无论是初期的PC-DVR还是嵌入式DVR,组成的都是小范围的本地监控系统,随着Net DVR的出现,可以方便地构建范围更大的监控系统。几种网络视频监控产品的对比见下表:

     
    S-优点
    W-缺点
    P-定位
    DVR
    本机操作功能丰富,支持本地存储
    网络功能弱,扩展性差
    适合本地监控需求、监控点密度高的场合。
    NVS
    体积小巧、网络功能强大,网络扩展性好,适合在野外、无人值守条件下工作
    本地操作功能简化,通常不支持本地存储。
    适合于分布监控、集中管理的网络监控。
    IP
    Camera
    集Camera与NVS功能于一身,施工、维护方便
    网络性能相对于NVS较弱,市场上可选择的高性能的IP Camera较少,无法任意选配、更换摄像头。
    企业网及民用低端市场。



        3.3 CCTV设备用户提出的意见与建议

        根据我们的调查,CCTV设备用户提出的意见与建议主要是:

        1、    品牌产品价格过高,且各地有不统一的现象;
        2、    网络视频设备带宽占用太高,信号传输不稳定;
        3、    产品说明书不详细,技术参数不够,有较多不明确之处;
        4、    网络视频设备在接入方式、分控方式上网络适应性差;
        5、    改进外观及包装,增加个性花设计;
        6、    用户接收到的厂商信息不够,不足以支持购买决策;
        7、    产品个性化与针对性不强,多领域应用需求无法满足;
        8、    应增加产品的新功能,照顾网络传输等应用;
        9、    本地化生产或大规模生产后质量有所下降;
        10、    给工程商留下的利润空间太小;
        11、    市场秩序不好,假冒伪劣产品很多;
        12、    售后服务不好,技术支持力度不足,维修速度慢;
        13、    网络视频产品画面传输不流畅,离真实的实时还有差距;
        14、    渠道铺设不足,服务与供货受影响;
        15、    厂商要求的付款方式不够灵活,供货速度慢,周期长。

        3.4 对视频监控网络产品选择的建议

        跟椐上述情况我们提出以下建议:

        1、大的监控网络采用NVS;
        2、本地存储非常有必要或者客户对本地存储有偏好的采用DVR;
        3、在带宽允许的情况下采用NVS;
        4、用户集中认证和管理是今后的发展方向;
        5、对于大的监控网络的存储方案,采用分布存储,集中管理。

        四、视频监控企业经营与管理战略决策转变

     

        4.1 安防企业的现状与经营模式变革的方向

        4.1.1安防企业的现状

        安防多数企业的现状令人担忧。视频监控行业技术、资金门槛较低,经营模式容易复制,企业众多竞争激烈。工程拖欠款的恶性循环从工程商、厂商、板卡商逐层推进,使各类商家的利润普遍降低。低价恶性竞争,小企业成本低可接受较低利润,使大企业生存艰难;国内有实力的企业其产品多位于中端,与国外高端产品的技术含量及国内低端产品的价格都有距离,所以不易存活。

        跨国集团进入中国安防市场,其产品线丰富,品牌知名度高,资金雄厚,可提供整体安防系统集成平台来满足用户完整需求,国内小型作坊式企业及走私水货的不法商家进行恶性价格竞争,使利润越来越薄。

        4.1.2安防企业经营模式变革的方向 

        多角度、一体化资源充足的国内安防企业少,面临国外大企业进攻与国内小企业恶性价格战压力较大,故合作比竞争更重要。

        精细制造、精益求精是国内安防企业的出路。因为从全球来看,趋势是从大规模生产向大规摸定制转移,所以在细分市场上做得好、做得专就是出路。

        走集团式发展之路是国内安防企业尽快做大做强的捷径。横向联合不同相关产品厂商形成完整的产品链。与上游供应商、下游经销商、工程商形成纵向联合,这种联合可以是松散的,也可以互持股份,乃至于兼并收购等形式。企业合作成立松散的组织(如会员制),共同运作、协调发展、利益与风险共担。

        4.2安防监控设备外销是发展的必由之路 

        4.2.1安防监控设备外贸发展历程

        从整体发展看,安防监控设备外销“十五”是起步阶段,“十一五”是发展阶段,会放量且有较大突破。根据安防行业“十一五规划”预测,2010年安防出口交货值将占行业总销售额的20%以上。

        4.2.2外贸竞争状况

        目前外销市场以欧洲,北美为主,台湾与韩国是我们主要竞争对手,台湾低端产品较多,交货期短是其优势,韩国在技术与功能方面比国产品好,多在本土生产,出口较多,国内多为中低端产品,芯片受制约,因此发展受限。

        4.2.3外贸发展现状

        目前外贸以贴牌为主,有少量自主品牌,大力发展自主品牌是方向,但需要一个较长的过程。OEM仍处于磨合期,但距离高速发展阶段为期不远。

        4.2.4外销发展存在问题

        在想进行设备外销的厂商中,无合适渠道、合作伙伴,不了解国外市场者占绝大多数。还有部分厂商对国外产品的标准要求不太明确。 

        4.2.5安防监控设备外销发展思路 

        1、OEM仍是现阶段主流

        经测算贴牌与自主品牌销量为9:1。一是OEM利润较多(约高于国内销售一倍),二是通过贴牌国内厂商的制作流程与国外委托方的需要不断贴近,从而使其制造能力、技术实力、产品国际化程度等方面均得到较大提升;此外,OEM还能充分利用社会化分工的优势,提高生产量、降低成本、提升技术水平、加快产品进入市场的速度、缩短随市场需求的反应时间、管理水平和制造工艺。

        2、发展自有品牌是方向

        自有品牌可提高品牌的无形资产,现有自主品牌外销多通过代理商操作,本地化服务很重要。我们的竞争优势仍是成本,但出口的大本营珠江三角洲的成本尤其是人力成本正在逐渐上升,随之其优势在不断下降。

        3、两种方式并行发展

        对于OEM与自有品牌,在不同发展阶段的企业应采取不同策略,发展较成熟的企业应有自主品牌,条件差些的企业要通过OEM改进技术、获取发展利润,位于中间地位的企业要两种方式并行发展啊。企业可通过OEM解决技术和资金问题,通过做知名品牌代理建立渠道解决资金和市场问题。

        4.2.6 安防监控设备外销具体改进建议 

        1、在市场开拓方面,利用国外大型安防展会、研讨会及有影响力的安防技术期刊加大宣传力度,同时加深与国外民间行业组织机构、大型安防厂商的联系,吸引国外客户主动上门询问,促成进一步合作。

        2、加强渠道建设,协调好OEM与自有品牌之间的渠道冲突。对OEM来说,尽量回避与不正规、信誉不好的商家合作,以免影响自有品牌的形象;对于自有品牌建设而言,初期应减少代理商的数量和层级,争取寻找到有实力的专业经销、代理商,以防止渠道混乱,产品交易价格不清。

        3、在产品定位方面,不应该做低价诉求,宜将产品定位于性价比适中的中档或中档偏高处。在价格定位上,可参照同档国内产品与国外产品之间的某处价位。产品外观设计、包装、实用性及国际资格认证要按照当地用户的具体需求做专门化、人性化处理。

        4、在市场定位方面,对不同区域的市场可采用不同的产品及经营策略。例如凭借中档产品打入东南亚市场,对欧美市场则以OEM为主,中东、非洲、南美市场,可用低价策略进入。

        5、在经营管理方面,要注意向国外同行学习先进的管理经验,尤其是职业经理人制度,随时关注、及时吸纳相关国际化专业人才。

        4.3安防企业融资现状与建议 

        4.3.1安防企业融资现状

        怎样解决企业现金流正常运转是安防企业面临的重大问题。因为安防行业押款现象严重,这在早些年利润高、项目小时还可接受,现在则直接威胁企业生命,工程商的押款将通过厂商、板卡商传递,使整个企业链萎靡不振。另一方面,国内安防企业大多从民营小企业起步,现在逐渐达到高速发展阶段,在此阶段用于维持企业增长的资金明显增多,以至于远高于企业自身的原始积累资金,但由于银行贷款难,因此企业长远发展与资金支持存在长期矛盾。

        上市与资本运作(收购,兼并,融资,风险投资)对安防企业而言既是机遇又风险很大,应谨慎对待,如操作不当很容易导致企业畸形发展或受制于人。资金获取渠道不要只专著于外部环境想办法融资,更重要的是要做好企业经营管理,企业做好了投资自然会主动找上门(如国家科技基金、国外风险投资、国外大企业合资于合作等),杭州几家企业就是明证。

        4.3.2安防企业资金管理与融资建议

        厂商逐渐认识到压款问题的严重性,开始对资金控制,这种控制会逐步反向传递给经销商、工程商、用户。从而逐步改善链条中各类企业的资金状况。

        选择投资或合作伙伴要选有长远发展意识的企业投资或合作,如合作者急功近利只着眼当下利益那么对日常经营管理十分不利。

        提倡加强行业内部交流,行业内部寻求资金合作(如融资)可能性更大,因为互相了解运作流程与经营背景。

        关于资金问题,内部引资一般管理较混乱,吸引外资更好,因为外方一般操作正规,不容易介入管理,且关注长远发展,而非一味追求眼前利益。

        建立联合担保制度,成立相关组织,互助解决企业贷款问题。

        在企业引导政府投入(如科技基金等)方面,协会应发挥更大作用,单凭企业能量不够。协会应多为企业提供融资、合资、合作方面的服务,建立内外部资金吸引渠道(行业内部、国外企业、其他行业企业)。

        4.4加强品牌建设之安防品牌发展之路

        4.4.1国内安防行业品牌发展历程

        国内安防行业品牌发展历程经历了品牌蒙昧阶段(79-83年)、品牌萌芽阶段(84-96年),现在已进入品牌发展阶段(97年以后)。品牌发展阶段又可以进一步分为品牌意识启蒙期(97-02)和注重品牌竞争期(02年以后)。  

        4.4.2加强品牌建设让用户接收你的产品品牌

        品牌的建设一般经历创品牌――宣传品牌――品牌扩张与延伸――发展品牌――保护品牌,这样一个过程。

        在目前的注重品牌竞争阶段,商家的竞争手段与以往有较大差异。此时,企业不仅靠提高设备生产率、技术研发能力、劳动生产率和降价等方法来提高自身的竞争力,更应该依赖人才、知识、管理的系统优化和品牌的优势开展竞争。企业要实现从“产品经营”向“品牌经营”的战略转变。

    展开全文
  • 监控神器Prometheus

    千次阅读 2020-10-27 15:05:51
    监控系统的历史悠久,是一个很成熟的方向,而 Prometheus 作为新生代的开源监控系统,慢慢成为了云原生体系的事实标准,也证明了其设计很受欢迎。 本文主要分享在 Prometheus 实践中遇到的一些问题和思考,如果你...

    监控神器Prometheus

    监控系统的历史悠久,是一个很成熟的方向,而 Prometheus 作为新生代的开源监控系统,慢慢成为了云原生体系的事实标准,也证明了其设计很受欢迎。

     

    本文主要分享在 Prometheus 实践中遇到的一些问题和思考,如果你对 K8S 监控体系或 Prometheus 的设计还不太了解,可以先看下容器监控系列。

    参考:

    http://www.xuyasong.com/?p=1921

    知乎

    https://dbaplus.cn/news-134-3106-1.html

    容器监控系列:https://yasongxu.gitbook.io/container-monitor/

    几点原则

    几点原则

     

    • 监控是基础设施,目的是为了解决问题,不要只朝着大而全去做,尤其是不必要的指标采集,浪费人力和存储资源(To B商业产品例外)。

    • 需要处理的告警才发出来,发出来的告警必须得到处理。

    • 简单的架构就是最好的架构,业务系统都挂了,监控也不能挂。Google Sre 里面也说避免使用 Magic 系统,例如机器学习报警阈值、自动修复之类。这一点见仁见智吧,感觉很多公司都在搞智能 AI 运维。

     

    Prometheus 的局限

    Prometheus 的局限

    • Prometheus 是基于 Metric 的监控,不适用于日志(Logs)、事件(Event)、调用链(Tracing)。

    • Prometheus 默认是 Pull 模型,合理规划你的网络,尽量不要转发。

    • 对于集群化和水平扩展,官方和社区都没有银弹,需要合理选择 Federate、Cortex、Thanos等方案。

    • 监控系统一般情况下可用性大于一致性,容忍部分副本数据丢失,保证查询请求成功。这个后面说 Thanos 去重的时候会提到。

    • Prometheus 不一定保证数据准确,这里的不准确一是指 rate、histogram_quantile 等函数会做统计和推断,产生一些反直觉的结果,这个后面会详细展开。二来查询范围过长要做降采样,势必会造成数据精度丢失,不过这是时序数据的特点,也是不同于日志系统的地方。

     

    K8S 集群中常用的 exporter一级标题中常用的 exporter一级标题

     

    Prometheus 属于 CNCF 项目,拥有完整的开源生态,与 Zabbix 这种传统 agent 监控不同,它提供了丰富的 exporter 来满足你的各种需求。

     

    你可以在这里看到官方、非官方的 exporter。如果还是没满足你的需求,你还可以自己编写 exporter,简单方便、自由开放,这是优点。

     

    普罗米修斯:https://prometheus.io/docs/instrumenting/exporters/

     

    但是过于开放就会带来选型、试错成本。之前只需要在 zabbix agent里面几行配置就能完成的事,现在你会需要很多 exporter 搭配才能完成。还要对所有 exporter 维护、监控。尤其是升级 exporter 版本时,很痛苦。非官方exporter 还会有不少 bug。这是使用上的不足,当然也是 Prometheus 的设计原则。

     

    K8S 生态的组件都会提供/metric接口以提供自监控,这里列下我们正在使用的:

     

    • cadvisor: 集成在 Kubelet 中。

    • kubelet: 10255为非认证端口,10250为认证端口。

    • apiserver: 6443端口,关心请求数、延迟等。

    • scheduler: 10251端口。

    • controller-manager: 10252端口。

    • etcd: 如etcd 写入读取延迟、存储容量等。

    • docker: 需要开启 experimental 实验特性,配置 metrics-addr,如容器创建耗时等指标。

    • kube-proxy: 默认 127 暴露,10249端口。外部采集时可以修改为 0.0.0.0 监听,会暴露:写入 iptables 规则的耗时等指标。

    • kube-state-metrics: K8S 官方项目,采集pod、deployment等资源的元信息。

    • node-exporter: Prometheus 官方项目,采集机器指标如 CPU、内存、磁盘。

    • blackbox_exporter: Prometheus 官方项目,网络探测,dns、ping、http监控

    • process-exporter: 采集进程指标

    • nvidia exporter: 我们有 gpu 任务,需要 gpu 数据监控

    • node-problem-detector: 即 npd,准确的说不是 exporter,但也会监测机器状态,上报节点异常打 taint

    • 应用层 exporter: mysql、nginx、mq等,看业务需求。

     

    监事:http://www.xuyasong.com/?p = 1483kube-state-metrics:http://www.xuyasong.com/?p = 1525

    节点出口商:http://www.xuyasong.com/?p = 1539

     

    还有各种场景下的自定义 exporter,如日志提取后面会再做介绍。

     

    自定义 exporter:http://www.xuyasong.com/?p=1942

     

    K8S 核心组件监控与 Grafana 面板

     

    k8s 集群运行中需要关注核心组件的状态、性能。如 kubelet、apiserver 等,基于上面提到的 exporter 的指标,可以在 Grafana 中绘制如下图表:

     

     

    模板可以参考dashboards-for-kubernetes-administrators,根据运行情况不断调整报警阈值。

     

    dashboards-for-kubernetes-administrators:https ://povilasv.me/grafana-dashboards-for-kubernetes-administrators

     

    这里提一下 Grafana 虽然支持了 templates 能力,可以很方便地做多级下拉框选择,但是不支持templates 模式下配置报警规则,相关issue

     

    问题:https://github.com/grafana/grafana/issues/9334

     

    官方对这个功能解释了一堆,可最新版本仍然没有支持。借用 issue 的一句话吐槽下:

     

    关于 Grafana 的基础用法,可以看看《容器监控实践—Grafana》。

     

    容器监控实践—Grafana:http://www.xuyasong.com/?p=1693

     

    采集组件 All IN One

     

    Prometheus 体系中 Exporter 都是独立的,每个组件各司其职,如机器资源用 Node-Exporter,Gpu 有Nvidia Exporter等等。但是 Exporter 越多,运维压力越大,尤其是对 Agent做资源控制、版本升级。我们尝试对一些Exporter进行组合,方案有二:

     

    • 通过主进程拉起N个 Exporter 进程,仍然可以跟着社区版本做更新、bug fix。

    • 用Telegraf来支持各种类型的 Input,N 合 1。

       

    另外,Node-Exporter 不支持进程监控,可以加一个Process-Exporter,也可以用上边提到的Telegraf,使用 procstat 的 input来采集进程指标。

     

    合理选择黄金指标

     

    采集的指标有很多,我们应该关注哪些?Google 在“Sre Handbook”中提出了“四个黄金信号”:延迟、流量、错误数、饱和度。实际操作中可以使用 Use 或 Red 方法作为指导,Use 用于资源,Red 用于服务。

     

    • Use 方法:Utilization、Saturation、Errors。如 Cadvisor 数据

    • Red 方法:Rate、Errors、Duration。如 Apiserver 性能指标

     

    Prometheus 采集中常见的服务分三种:

     

    • 在线服务:如 Web 服务、数据库等,一般关心请求速率,延迟和错误率即 RED 方法。

    • 离线服务:如日志处理、消息队列等,一般关注队列数量、进行中的数量,处理速度以及发生的错误即 Use 方法。

    • 批处理任务:和离线任务很像,但是离线任务是长期运行的,批处理任务是按计划运行的,如持续集成就是批处理任务,对应 K8S 中的 job 或 cronjob, 一般关注所花的时间、错误数等,因为运行周期短,很可能还没采集到就运行结束了,所以一般使用 Pushgateway,改拉为推。

     

    对 Use 和 Red 的实际示例可以参考容器监控实践—K8S常用指标分析这篇文章。

     

    容器监控实践—K8S常用指标分析:http://www.xuyasong.com/?P=1717

     

    K8S 1.16中 Cadvisor 的指标兼容问题

     

    在 K8S 1.16版本,Cadvisor 的指标去掉了 pod_Name 和 container_name 的 label,替换为了pod 和 container。如果你之前用这两个 label 做查询或者 Grafana 绘图,需要更改下 Sql 了。因为我们一直支持多个 K8S 版本,就通过 relabel配置继续保留了原来的**_name。

     

     

    注意要用 metric_relabel_configs,不是 relabel_configs,采集后做的replace。

     

    Prometheus采集外部K8S集群、多集群

     

    Prometheus 如果部署在K8S集群内采集是很方便的,用官方给的Yaml就可以,但我们因为权限和网络需要部署在集群外,二进制运行,采集多个 K8S 集群。

     

    以 Pod 方式运行在集群内是不需要证书的(In-Cluster 模式),但集群外需要声明 token之类的证书,并替换address,即使用 Apiserver Proxy采集,以 Cadvisor采集为例,Job 配置为:

     

     

    bearer_token_file 需要提前生成,这个参考官方文档即可。记得 base64 解码。

     

    对于 cadvisor 来说,__metrics_path__可以转换为/api/v1/nodes/${1}/proxy/metrics/cadvisor,代表Apiserver proxy 到 Kubelet,如果网络能通,其实也可以直接把 Kubelet 的10255作为 target,可以直接写为:

     

    ${1}:10255/metrics/cadvisor,代表直接请求Kubelet,规模大的时候还减轻了 Apiserver 的压力,即服务发现使用 Apiserver,采集不走 Apiserver。

     

    因为 cadvisor 是暴露主机端口,配置相对简单,如果是 kube-state-metric 这种 Deployment,以 endpoint 形式暴露,写法应该是:

     

     

    对于 endpoint 类型,需要转换__metrics_path__为/api/v1/namespaces/${1}/services/${2}:${3}/proxy/metrics,需要替换 namespace、svc 名称端口等,这里的写法只适合接口为/metrics的exporter,如果你的 exporter 不是/metrics接口,需要替换这个路径。或者像我们一样统一约束都使用这个地址。

     

    这里的__meta_kubernetes_service_annotation_prometheus_io_port来源就是 exporter 部署时写的那个 annotation,大多数文章中只提到prometheus.io/scrape: 'true',但也可以定义端口、路径、协议。以方便在采集时做替换处理。

     

    其他的一些 relabel 如kubernetes_namespace 是为了保留原始信息,方便做 promql 查询时的筛选条件。

     

    如果是多集群,同样的配置多写几遍就可以了,一般一个集群可以配置三类job:

     

    • role:node 的,包括 cadvisor、 node-exporter、kubelet 的 summary、kube-proxy、docker 等指标。

    • role:endpoint 的,包括 kube-state-metric 以及其他自定义 Exporter。

    • 普通采集:包括Etcd、Apiserver 性能指标、进程指标等。

     

    GPU 指标的获取

     

    nvidia-smi可以查看机器上的 GPU 资源,而Cadvisor 其实暴露了Metric来表示容器使用 GPU 情况,

     

     

    如果要更详细的 GPU 数据,可以安装dcgm exporter,不过K8S 1.13 才能支持。

     

    更改 Prometheus 的显示时区

     

    Prometheus 为避免时区混乱,在所有组件中专门使用 Unix Time 和 Utc 进行显示。不支持在配置文件中设置时区,也不能读取本机 /etc/timezone 时区。

     

    其实这个限制是不影响使用的:

     

    • 如果做可视化,Grafana是可以做时区转换的。

    • 如果是调接口,拿到了数据中的时间戳,你想怎么处理都可以。

    • 如果因为 Prometheus 自带的 UI 不是本地时间,看着不舒服,2.16 版本的新版 Web UI已经引入了Local Timezone 的选项,区别见下图。

    • 如果你仍然想改 Prometheus 代码来适应自己的时区,可以参考《修改源码更改prometheus的时区问题》。

     

    2.16 版本:

    https://github.com/prometheus/prometheus/commit/d996ba20ec9c7f1808823a047ed9d5ce96be3d8f

    修改源码更改prometheus的时区问题:

    https://zhangguanzhang.github.io/2019/09/05/prometheus-change-timezone/

     

     

    关于 timezone 的讨论,可以看这个issue。

     

    问题:https://github.com/prometheus/prometheus/issues/500

     

    如何采集 LB 后面的 RS 的 Metric

     

    假如你有一个负载均衡 LB,但网络上 Prometheus 只能访问到 LB 本身,访问不到后面的 RS,应该如何采集 RS 暴露的 Metric?

     

    • RS 的服务加 Sidecar Proxy,或者本机增加 Proxy 组件,保证 Prometheus 能访问到。

    • LB 增加 /backend1 和 /backend2请求转发到两个单独的后端,再由 Prometheus 访问 LB 采集。

     

    版本的选择

     

    Prometheus 当前最新版本为 2.16,Prometheus 还在不断迭代,因此尽量用最新版,1.X版本就不用考虑了。

     

    2.16 版本上有一套实验 UI,可以查看 TSDB 的状态,包括Top 10的 Label、Metric。

     

     

    Prometheus 大内存问题

     

    随着规模变大,Prometheus 需要的 CPU 和内存都会升高,内存一般先达到瓶颈,这个时候要么加内存,要么集群分片减少单机指标。这里我们先讨论单机版 Prometheus 的内存问题。

     

    原因:

     

    • Prometheus 的内存消耗主要是因为每隔2小时做一个 Block 数据落盘,落盘之前所有数据都在内存里面,因此和采集量有关。

    • 加载历史数据时,是从磁盘到内存的,查询范围越大,内存越大。这里面有一定的优化空间。

    • 一些不合理的查询条件也会加大内存,如 Group 或大范围 Rate。

     

    我的指标需要多少内存:

     

    • 作者给了一个计算器,设置指标量、采集间隔之类的,计算 Prometheus 需要的理论内存值:计算公式。

       

    计算公式:https://www.robustperception.io/how-much-ram-does-prometheus-2-x-need-for-cardinality-and-ingestion

     

    以我们的一个 Prometheus Server为例,本地只保留 2 小时数据,95 万 Series,大概占用的内存如下:
     

     

     

     

    有什么优化方案:

     

    • Sample 数量超过了 200 万,就不要单实例了,做下分片,然后通过 Victoriametrics,Thanos,Trickster 等方案合并数据。

    • 评估哪些 Metric 和 Label 占用较多,去掉没用的指标。2.14 以上可以看 Tsdb 状态。

    • 查询时尽量避免大范围查询,注意时间范围和 Step 的比例,慎用 Group。

    • 如果需要关联查询,先想想能不能通过 Relabel 的方式给原始数据多加个 Label,一条Sql 能查出来的何必用Join,时序数据库不是关系数据库。

     

    Prometheus 内存占用分析:

     

    • 通过 pprof分析:https://www.robustperception.io/optimising-prometheus-2-6-0-memory-usage-with-pprof

    • 1.X 版本的内存:https://www.robustperception.io/how-much-ram-does-my-prometheus-need-for-ingestion

     

    相关 issue:

     

    • https://groups.google.com/forum/#!searchin/prometheus-users/memory%7Csort:date/prometheus-users/q4oiVGU6Bxo/uifpXVw3CwAJ

    • https://github.com/prometheus/prometheus/issues/5723

    • https://github.com/prometheus/prometheus/issues/1881

     

    Prometheus 容量规划

     

    容量规划除了上边说的内存,还有磁盘存储规划,这和你的 Prometheus 的架构方案有关。

     

    • 如果是单机Prometheus,计算本地磁盘使用量。

    • 如果是 Remote-Write,和已有的 Tsdb 共用即可。

    • 如果是 Thanos 方案,本地磁盘可以忽略(2H),计算对象存储的大小就行。

     

    Prometheus 每2小时将已缓冲在内存中的数据压缩到磁盘上的块中。包括Chunks、Indexes、Tombstones、Metadata,这些占用了一部分存储空间。一般情况下,Prometheus中存储的每一个样本大概占用1-2字节大小(1.7Byte)。可以通过Promql来查看每个样本平均占用多少空间:

     

     

        “`bash

    速率(prometheus_tsdb_compaction_chunk_size_bytes_sum [1h])

    /

    费率(prometheus_tsdb_compaction_chunk_samples_sum [1h]){instance =“ 0.0.0.0:8890”,job =“ prometheus”}

    1.252747585939941

        “`

     

    如果大致估算本地磁盘大小,可以通过以下公式:

     

     

    保留时间(retention_time_seconds)和样本大小(bytes_per_sample)不变的情况下,如果想减少本地磁盘的容量需求,只能通过减少每秒获取样本数(ingested_samples_per_second)的方式。

     

    查看当前每秒获取的样本数:

     

     

    有两种手段,一是减少时间序列的数量,二是增加采集样本的时间间隔。考虑到 Prometheus 会对时间序列进行压缩,因此减少时间序列的数量效果更明显。

     

    举例说明:

     

    • 采集频率 30s,机器数量1000,Metric种类6000,1000600026024 约 200 亿,30G 左右磁盘。

    • 只采集需要的指标,如 match[], 或者统计下最常使用的指标,性能最差的指标。

     

    以上磁盘容量并没有把 wal 文件算进去,wal 文件(Raw Data)在 Prometheus 官方文档中说明至少会保存3个 Write-Ahead Log Files,每一个最大为128M(实际运行发现数量会更多)。

     

    因为我们使用了 Thanos 的方案,所以本地磁盘只保留2H 热数据。Wal 每2小时生成一份Block文件,Block文件每2小时上传对象存储,本地磁盘基本没有压力。

    关于 Prometheus 存储机制,可以看《容器监控实践—Prometheus存储机制》。

     

    容器监控实践—Prometheus存储机制:http://www.xuyasong.com/?p=1601

     

    对 Apiserver 的性能影响

     

    如果你的 Prometheus 使用了 kubernetes_sd_config 做服务发现,请求一般会经过集群的 Apiserver,随着规模的变大,需要评估下对 Apiserver性能的影响,尤其是Proxy失败的时候,会导致CPU 升高。当然了,如果单K8S集群规模太大,一般都是拆分集群,不过随时监测下 Apiserver 的进程变化还是有必要的。

     

    在监控Cadvisor、Docker、Kube-Proxy 的 Metric 时,我们一开始选择从 Apiserver Proxy 到节点的对应端口,统一设置比较方便,但后来还是改为了直接拉取节点,Apiserver 仅做服务发现。

     

    Rate 的计算逻辑

     

    Prometheus 中的 Counter 类型主要是为了 Rate 而存在的,即计算速率,单纯的 Counter 计数意义不大,因为 Counter 一旦重置,总计数就没有意义了。

     

    Rate 会自动处理 Counter 重置的问题,Counter 一般都是一直变大的,例如一个 Exporter 启动,然后崩溃了。本来以每秒大约10的速率递增,但仅运行了半个小时,则速率(x_total [1h])将返回大约每秒5的结果。另外,Counter 的任何减少也会被视为 Counter 重置。例如,如果时间序列的值为[5,10,4,6],则将其视为[5,10,14,16]。

     

    Rate 值很少是精确的。由于针对不同目标的抓取发生在不同的时间,因此随着时间的流逝会发生抖动,query_range 计算时很少会与抓取时间完美匹配,并且抓取有可能失败。面对这样的挑战,Rate 的设计必须是健壮的。

     

    Rate 并非想要捕获每个增量,因为有时候增量会丢失,例如实例在抓取间隔中挂掉。如果 Counter 的变化速度很慢,例如每小时仅增加几次,则可能会导致【假象】。比如出现一个 Counter 时间序列,值为100,Rate 就不知道这些增量是现在的值,还是目标已经运行了好几年并且才刚刚开始返回。

     

    建议将 Rate 计算的范围向量的时间至少设为抓取间隔的四倍。这将确保即使抓取速度缓慢,且发生了一次抓取故障,您也始终可以使用两个样本。此类问题在实践中经常出现,因此保持这种弹性非常重要。例如,对于1分钟的抓取间隔,您可以使用4分钟的 Rate 计算,但是通常将其四舍五入为5分钟。

     

    如果 Rate 的时间区间内有数据缺失,他会基于趋势进行推测,比如:

     

     

    反直觉的 P95 统计

     

    histogram_quantile 是 Prometheus 常用的一个函数,比如经常把某个服务的 P95 响应时间来衡量服务质量。不过它到底是什么意思很难解释得清,特别是面向非技术的同学,会遇到很多“灵魂拷问”。

     

    我们常说 P95(P99,P90都可以) 响应延迟是 100ms,实际上是指对于收集到的所有响应延迟,有 5% 的请求大于 100ms,95% 的请求小于 100ms。Prometheus 里面的 histogram_quantile 函数接收的是 0-1 之间的小数,将这个小数乘以 100 就能很容易得到对应的百分位数,比如 0.95 就对应着 P95,而且还可以高于百分位数的精度,比如 0.9999。

     

    当你用 histogram_quantile 画出响应时间的趋势图时,可能会被问:为什么P95大于或小于我的平均值?

     

    正如中位数可能比平均数大也可能比平均数小,P99 比平均值小也是完全有可能的。通常情况下 P99 几乎总是比平均值要大的,但是如果数据分布比较极端,最大的 1% 可能大得离谱从而拉高了平均值。一种可能的例子:

     

     

    服务 X 由顺序的 A,B 两个步骤完成,其中 X 的 P99 耗时 100Ms,A 过程 P99 耗时 50Ms,那么推测 B 过程的 P99 耗时情况是?

     

    直觉上来看,因为有 X=A+B,所以答案可能是 50Ms,或者至少应该要小于 50Ms。实际上 B 是可以大于 50Ms 的,只要 A 和 B 最大的 1% 不恰好遇到,B 完全可以有很大的 P99:

     

     

     

    所以我们从题目唯一能确定的只有 B 的 P99 应该不能超过 100ms,A 的 P99 耗时 50Ms 这个条件其实没啥用。

     

    类似的疑问很多,因此对于 histogram_quantile 函数,可能会产生反直觉的一些结果,最好的处理办法是不断试验调整你的 Bucket 的值,保证更多的请求时间落在更细致的区间内,这样的请求时间才有统计意义。

     

    慢查询问题

     

    Prometheus 提供了自定义的 Promql 作为查询语句,在 Graph 上调试的时候,会告诉你这条 Sql 的返回时间,如果太慢你就要注意了,可能是你的用法出现了问题。

     

    慢查询:http://www.xuyasong.com/?p=1578

     

    评估 Prometheus 的整体响应时间,可以用这个默认指标:

     

     

    一般情况下响应过慢都是Promql 使用不当导致,或者指标规划有问题,如:

     

    • 大量使用 join 来组合指标或者增加 label,如将 kube-state-metric 中的一些 meta label和 node-exporter 中的节点属性 label加入到 cadvisor容器数据里,像统计 pod 内存使用率并按照所属节点的机器类型分类,或按照所属 rs 归类。

    • 范围查询时,大的时间范围 step 值却很小,导致查询到的数量过大。

    • rate 会自动处理 counter 重置的问题,最好由 promql 完成,不要自己拿出来全部元数据在程序中自己做 rate 计算。

    • 在使用 rate 时,range duration要大于等于step,否则会丢失部分数据

    • prometheus 是有基本预测功能的,如deriv和predict_linear(更准确)可以根据已有数据预测未来趋势

    • 如果比较复杂且耗时的sql,可以使用 record rule 减少指标数量,并使查询效率更高,但不要什么指标都加 record,一半以上的 metric 其实不太会查询到。同时 label 中的值不要加到 record rule 的 name 中。

     

    步骤:https://www.robustperception.io/step-and-query_range

    部分数据:https://chanjarster.github.io/post/p8s-step-param/

     

    高基数问题 Cardinality

     

    高基数是数据库避不开的一个话题,对于 Mysql 这种 DB 来讲,基数是指特定列或字段中包含的唯一值的数量。基数越低,列中重复的元素越多。对于时序数据库而言,就是 tags、label 这种标签值的数量多少。

     

    比如 Prometheus 中如果有一个指标 http_request_count{method="get",path="/abc",originIP="1.1.1.1"}表示访问量,method 表示请求方法,originIP 是客户端 IP,method的枚举值是有限的,但 originIP 却是无限的,加上其他 label 的排列组合就无穷大了,也没有任何关联特征,因此这种高基数不适合作为 Metric 的 label,真要的提取originIP,应该用日志的方式,而不是 Metric 监控。

     

    时序数据库会为这些 Label 建立索引,以提高查询性能,以便您可以快速找到与所有指定标签匹配的值。如果值的数量过多,索引是没有意义的,尤其是做 P95 等计算的时候,要扫描大量 Series 数据。

     

    官方文档中对于Label 的建议

     

     

    如何查看当前的Label 分布情况呢,可以使用 Prometheus提供的Tsdb工具。可以使用命令行查看,也可以在 2.16 版本以上的 Prometheus Graph 查看

     

     

     

    top10 高基数的 metric

     

     

    高基数的 label

     

     

    找到最大的 metric 或 job

     

    top10的 metric 数量:按 metric 名字分

     

     

    top10的 metric 数量:按 job 名字分

     

     

    Prometheus 重启慢与热加载

     

    Prometheus 重启的时候需要把 Wal 中的内容 Load 到内存里,保留时间越久、Wal 文件越大,重启的实际越长,这个是 Prometheus 的机制,没得办法,因此能 Reload 的就不要重启,重启一定会导致短时间的不可用,而这个时候Prometheus高可用就很重要了。

     

    Prometheus 也曾经对启动时间做过优化,在 2.6 版本中对于Wal的 Load 速度就做过速度的优化,希望重启的时间不超过 1 分钟。

     

    1分钟:https://www.robustperception.io/optimising-startup-time-of-prometheus-2-6-0-with-pprof

     

    Prometheus 提供了热加载能力,不过需要开启web.enable-lifecycle配置,更改完配置后,curl 下 reload 接口即可。prometheus-operator 中更改了配置会默认触发 reload,如果你没有使用operator,又希望可以监听 configmap 配置变化来 reload 服务,可以试下这个简单的脚本。

     

     

    使用时和 prometheus 挂载同一个 configmap,传入如下参数即可:

     

     

    你的应用需要暴露多少指标

     

    当你开发自己的服务的时候,你可能会把一些数据暴露 Metric出去,比如特定请求数、Goroutine 数等,指标数量多少合适呢?

     

    虽然指标数量和你的应用规模相关,但也有一些建议(Brian Brazil),比如简单的服务如缓存等,类似 Pushgateway,大约 120 个指标,Prometheus 本身暴露了 700 左右的指标,如果你的应用很大,也尽量不要超过 10000 个指标,需要合理控制你的 Label。

     

    建议(Brian巴西):https://www.robustperception.io/how-many-metrics-should-an-application-return

     

    node-exporter 的问题

     

    • node-exporter 不支持进程监控,这个前面已经提到了。

    • node-exporter 只支持 unix 系统,windows机器 请使用 wmi_exporter。因此以 yaml 形式不是 node-exporter 的时候,node-selector 要表明os类型。

    • 因为node_exporter是比较老的组件,有一些最佳实践并没有merge进去,比如符合Prometheus命名规范,因此建议使用较新的0.16和0.17版本。

     

    命名规范:https://prometheus.io/docs/practices/naming/

     

    一些指标名字的变化:

     

     

    如果你之前用的旧版本 exporter,在绘制 grafana 的时候指标名称就会有差别,解决方法有两种:

     

    • 一是在机器上启动两个版本的node-exporter,都让prometheus去采集。

    • 二是使用指标转换器,他会将旧指标名称转换为新指标

     

    指标转换器:https://github.com/prometheus/node_exporter/blob/master/docs/example-16-compatibility-rules.yml

     

    kube-state-metric 的问题

     

    除了文章中提到的作用,kube-state-metric还有一个很重要的使用场景,就是和 cadvisor 指标组合,原始的 cadvisor 中只有 pod 信息,不知道属于哪个 deployment 或者 sts,但是和kube-state-metric 中的 kube_pod_info 做 join 查询之后就可以显示出来,kube-state-metric的元数据指标,在扩展 cadvisor 的 label 中起到了很多作用,prometheus-operator 的很多 record rule 就使用了 kube-state-metric 做组合查询。

     

    容器监控实践—kube-state-metrics:http://www.xuyasong.com/?p=1525

     

    kube-state-metric 中也可以展示 pod 的 label 信息,可以在拿到 cadvisor 数据后更方便地做 group by,如按照 pod 的运行环境分类。但是 kube-state-metric 不暴露 pod 的 annotation,原因是下面会提到的高基数问题,即 annotation 的内容太多,不适合作为指标暴露。

     

    relabel_configs

     

    relabel_configs与metric_relabel_configs

     

    relabel_config 发生在采集之前,metric_relabel_configs 发生在采集之后,合理搭配可以满足很多场景的配置。

     

    如:

     

     

     

    Prometheus 的预测能力

     

    场景1:你的磁盘剩余空间一直在减少,并且降低的速度比较均匀,你希望知道大概多久之后达到阈值,并希望在某一个时刻报警出来。

     

    场景2:你的 Pod 内存使用率一直升高,你希望知道大概多久之后会到达 Limit 值,并在一定时刻报警出来,在被杀掉之前上去排查。

     

    Prometheus 的 Deriv 和 Predict_Linear 方法可以满足这类需求, Promtheus 提供了基础的预测能力,基于当前的变化速度,推测一段时间后的值。

     

    以 mem_free 为例,最近一小时的 free 值一直在下降。

     

     

    deriv函数可以显示指标在一段时间的变化速度:

     

     

    predict_linear方法是预测基于这种速度,最后可以达到的值:

     

     

     

    你可以基于设置合理的报警规则,如小于 10 时报警:

     

     

    predict_linear 与 deriv 的关系: 含义上约等于如下表达式,不过 predict_linear 稍微准确一些。

     

     

    如果你要基于 Metric做模型预测,可以参考下forecast-prometheus。

     

    预测普罗米修斯:https://github.com/nfrumkin/forecast-prometheus

     

    alertmanager 的上层封装

     

    Prometheus 部署之后很少会改动,尤其是做了服务发现,就不需要频繁新增 target。但报警的配置是很频繁的,如修改阈值、修改报警人等。alertmanager 拥有丰富的报警能力如分组、抑制等,但如果你要想把他给业务部门使用,就要做一层封装了,也就是报警配置台。用户喜欢表单操作,而非晦涩的 yaml,同时他们也并不愿意去理解 promql。而且大多数公司内已经有现成的监控平台,也只有一份短信或邮件网关,所以最好能使用 webhook 直接集成。

     

    例如: 机器磁盘使用量超过 90% 就报警,rule 应该写为:disk_used/disk_total > 0.9

     

    如果不加 label 筛选,这条报警会对所有机器生效,但如果你想去掉其中几台机器,就得在disk_used和disk_total后面加上{instance != “”}。这些操作在 promql 中是很简单的,但是如果放在表单里操作,就得和内部的 cmdb 做联动筛选了。

     

    • 对于一些简单的需求,我们使用了 Grafana 的报警能力,所见即所得,直接在图表下面配置告警即可,报警阈值和状态很清晰。不过 Grafana 的报警能力很弱,只是实验功能,可以作为调试使用。

    • 对于常见的 pod 或应用监控,我们做了一些表单化,如下图所示:提取了 CPU、内存、磁盘 IO 等常见的指标作为选择项,方便配置。

     

     

    • 使用 webhook 扩展报警能力,改造 alertmanager, 在 send message 时做加密和认证,对接内部已有报警能力,并联动用户体系,做限流和权限控制。

    • 调用 alertmanager api 查询报警事件,进行展示和统计。

     

    对于用户来说,封装 alertmanager yaml 会变的易用,但也会限制其能力,在增加报警配置时,研发和运维需要有一定的配合。如新写了一份自定义的 exporter,要将需要的指标供用户选择,并调整好展示和报警用的 promql。还有报警模板、原生 promql 暴露、用户分组等,需要视用户需求做权衡。

     

    错误的高可用设计

     

    有些人提出过这种类型的方案,想提高其扩展性和可用性。

     

     

    应用程序将 Metric 推到到消息队列如 Kafaka,然后经过 Exposer 消费中转,再被 Prometheus 拉取。产生这种方案的原因一般是有历史包袱、复用现有组件、想通过 Mq 来提高扩展性。

     

    这种方案有几个问题:

     

    • 增加了 Queue 组件,多了一层依赖,如果 App与 Queue 之间连接失败,难道要在 App 本地缓存监控数据?

    • 抓取时间可能会不同步,延迟的数据将会被标记为陈旧数据,当然你可以通过添加时间戳来标识,但就失去了对陈旧数据的处理逻辑。

    • 扩展性问题:Prometheus 适合大量小目标,而不是一个大目标,如果你把所有数据都放在了 Exposer 中,那么 Prometheus 的单个 Job 拉取就会成为 CPU 瓶颈。这个和 Pushgateway 有些类似,没有特别必要的场景,都不是官方建议的方式。

    • 缺少了服务发现和拉取控制,Prom 只知道一个 Exposer,不知道具体是哪些 Target,不知道他们的 UP 时间,无法使用 Scrape_* 等指标做查询,也无法用scrape_limit做限制。

     

    处理逻辑:https://www.robustperception.io/staleness-and-promql

    scrape_limit:https://www.robustperception.io/using-sample_limit-to-avoid-overload

     

    如果你的架构和 Prometheus 的设计理念相悖,可能要重新设计一下方案了,否则扩展性和可靠性反而会降低。

     

    prometheus-operator 的场景

     

    如果你是在 K8S 集群内部署 Prometheus,那大概率会用到 prometheus-operator,他对 Prometheus 的配置做了 CRD 封装,让用户更方便的扩展 Prometheus实例,同时 prometheus-operator 还提供了丰富的 Grafana 模板,包括上面提到的 master 组件监控的 Grafana 视图,operator 启动之后就可以直接使用,免去了配置面板的烦恼。

     

    operator 的优点很多,就不一一列举了,只提一下 operator 的局限:

     

    • 因为是 operator,所以依赖 K8S 集群,如果你需要二进制部署你的 Prometheus,如集群外部署,就很难用上prometheus-operator了,如多集群场景。当然你也可以在 K8S 集群中部署 operator 去监控其他的 K8S 集群,但这里面坑不少,需要修改一些配置。

    • operator 屏蔽了太多细节,这个对用户是好事,但对于理解 Prometheus 架构就有些 gap 了,比如碰到一些用户一键安装了operator,但 Grafana 图表异常后完全不知道如何排查,record rule 和 服务发现还不了解的情况下就直接配置,建议在使用 operator 之前,最好熟悉 prometheus 的基础用法。

    • operator 方便了 Prometheus 的扩展和配置,对于 alertmanager 和 exporter 可以很方便的做到多实例高可用,但是没有解决 Prometheus 的高可用问题,因为无法处理数据不一致,operator目前的定位也还不是这个方向,和 Thanos、Cortex 等方案的定位是不同的,下面会详细解释。

     

    高可用方案

     

    Prometheus 高可用有几种方案:

     

    • 基本 HA:即两套 Prometheus 采集完全一样的数据,外边挂负载均衡

    • HA + 远程存储:除了基础的多副本 Prometheus,还通过 Remote Write 写入到远程存储,解决存储持久化问题

    • 联邦集群:即 Federation,按照功能进行分区,不同的 Shard 采集不同的数据,由Global节点来统一存放,解决监控数据规模的问题。

    • 使用 Thanos 或者 Victoriametrics,来解决全局查询、多副本数据 Join 问题。

       

    就算使用官方建议的多副本 + 联邦,仍然会遇到一些问题:

     

    • 官方建议数据做 Shard,然后通过Federation来实现高可用,

    • 但是边缘节点和Global节点依然是单点,需要自行决定是否每一层都要使用双节点重复采集进行保活。也就是仍然会有单机瓶颈。

    • 另外部分敏感报警尽量不要通过Global节点触发,毕竟从Shard节点到Global节点传输链路的稳定性会影响数据到达的效率,进而导致报警实效降低。

    • 例如服务Updown状态,Api请求异常这类报警我们都放在Shard节点进行报警。

       

    本质原因是,Prometheus 的本地存储没有数据同步能力,要在保证可用性的前提下,再保持数据一致性是比较困难的,基础的 HA Proxy 满足不了要求,比如:

     

    • 集群的后端有 A 和 B 两个实例,A 和 B 之间没有数据同步。A 宕机一段时间,丢失了一部分数据,如果负载均衡正常轮询,请求打到A 上时,数据就会异常。

    • 如果 A 和 B 的启动时间不同,时钟不同,那么采集同样的数据时间戳也不同,就不是多副本同样数据的概念了

    • 就算用了远程存储,A 和 B 不能推送到同一个 TSDB,如果每人推送自己的 TSDB,数据查询走哪边就是问题了。

       

    因此解决方案是在存储、查询两个角度上保证数据的一致:

     

    • 存储角度:如果使用 Remote Write 远程存储, A 和 B后面可以都加一个 Adapter,Adapter做选主逻辑,只有一份数据能推送到 TSDB,这样可以保证一个异常,另一个也能推送成功,数据不丢,同时远程存储只有一份,是共享数据。

    • 查询角度:上边的方案实现很复杂且有一定风险,因此现在的大多数方案在查询层面做文章,比如 Thanos 或者 Victoriametrics,仍然是两份数据,但是查询时做数据去重和 Join。只是 Thanos 是通过 Sidecar 把数据放在对象存储,Victoriametrics 是把数据 Remote Write 到自己的 Server 实例,但查询层 Thanos-Query 和 Victor 的 Promxy的逻辑基本一致。

       

    存储方案:https://blog.timescale.com/blog/prometheus-ha-postgresql-8de68d19b6f5/

     

    我们采用了 Thanos 来支持多地域监控数据。

     

    高可用 Prometheus:Thanos 实践:

    http://www.xuyasong.com/?p=1925

     

    容器日志与事件

     

    本文主要是 Prometheus 监控内容, 这里只简单介绍下 K8S 中的日志、事件处理方案,以及和 Prometheus 的搭配。

     

    日志处理:

     

    • 日志采集与推送:一般是Fluentd/Fluent-Bit/Filebeat等采集推送到 ES、对象存储、kafaka,日志就该交给专业的 EFK 来做,分为容器标准输出、容器内日志。

    • 日志解析转 metric:可以提取一些日志转为 Prometheus 格式的指标,如解析特定字符串出现次数,解析 Nginx 日志得到 QPS 、请求延迟等。常用方案是 mtail 或者 grok

     

    日志采集方案:

     

    • sidecar 方式:和业务容器共享日志目录,由 sidecar 完成日志推送,一般用于多租户场景。

    • daemonset 方式:机器上运行采集进程,统一推送出去。

     

    需要注意的点:对于容器标准输出,默认日志路径是/var/lib/docker/containers/xxx, kubelet 会将改日志软链到/var/log/pods,同时还有一份/var/log/containers 是对/var/log/pods的软链。不过不同的 K8S 版本,日志的目录格式有所变化,采集时根据版本做区分:

     

    • 1.15 及以下:/var/log/pods/{pod_uid}/

    • 1.15 以上:var/log/pods/{pod_name+namespace+rs+uuid}/

     

    事件:在这里特指 K8S Events,Events 在排查集群问题时也很关键,不过默认情况下只保留 1h,因此需要对 Events 做持久化。一般 Events 处理方式有两种:

     

    • 使用 kube-eventer 之类的组件采集 Events 并推送到 ES

    • 使用 event_exporter 之类的组件将Events 转化为 Prometheus Metric,同类型的还有谷歌云的 stackdriver 下的 event-exporter

     

    多维数据集事件:https://github.com/AliyunContainerService/cube-events

    event_exporter:https://github.com/caicloud/event_exporter

    活动出口商:

    https://github.com/GoogleCloudPlatform/k8s-stackdriver/tree/master/event-exporter

     

    >

     

    参考资料

     

    • https://tech.meituan.com/2018/11/01/cat-in-depth-java-application-monitoring.html

    • https://dbaplus.cn/news-134-1462-1.html

    • https://www.infoq.cn/article/P3A5EuKl6jowO9v4_ty1

    • https://zhuanlan.zhihu.com/p/60791449

    • http://download.xuliangwei.com/jiankong.html#0-%E7%9B%91%E6%8E%A7%E7%9B%AE%E6%A0%87

    • https://aleiwu.com/post/prometheus-bp/

    • https://www.infoq.cn/article/1AofGj2SvqrjW3BKwXlN

    • http://bos.itdks.com/e8792eb0577b4105b4c9d19eb0dd1892.pdf

    • https://www.infoq.cn/article/ff46l7LxcWAX698zpzB2

    • https://www.robustperception.io/putting-queues-in-front-of-prometheus-for-reliability

    • https://www.slideshare.net/cadaam/devops-taiwan-monitor-tools-prometheus

    • https://www.robustperception.io/how-much-disk-space-do-prometheus-blocks-use

    • https://www.imooc.com/article/296613

    • https://dzone.com/articles/what-is-high-cardinality

    • https://www.robustperception.io/cardinality-is-key

    • https://www.robustperception.io/using-tsdb-analyze-to-investigate-churn-and-cardinality

    • https://blog.timescale.com/blog/prometheus-ha-postgresql-8de68d19b6f5/

    • https://asktug.com/t/topic/2618

    展开全文
  • 、视频监控技术概述

    千次阅读 2017-12-07 17:45:31
    14年大四进入实验室,接触到的第一个项目就是“警情识别显示系统”。项目PC版当时已经完善,自己工作主要是后续的嵌入式版本移植。因为项目验收,亲自研究过整个监控系统的硬件搭建,向当时布线工程师学会了如何接模
  • 监控行业相关的种分辨率

    千次阅读 2012-09-27 17:27:31
    <!-- @page {margin:2cm} p {margin-bottom:0.21cm; direction:ltr; color:#000000; text-align:justify;...目前监控行业中主要使用Qcif(176×144)、CIF(352×288)、HALFD1(704×2
  • 我认为计算机视觉给交通带来的主要有如下几个方面:第一个是感知,对于我们车辆而言就是车辆的检测,第二个是车辆身份的识别,第三是车辆身份的比对,第四个是车辆的行为分析,第五个是驾控,也就是现在非常火的...
  • 如何建立起一套有效的APP监控体系

    万次阅读 2016-05-19 16:09:03
    移动APP是近年刚刚出现的新产品形态,如何保障 移动APP质量是一个新的挑战和话题。今天,我们重点介绍APP端问题如何发现、如何定位、如何止损,以及如何建立起一套有效的监控体系,为APP稳定应用保驾护航。分为...
  • NetHogs监控Linux/Centos的每进程流量

    千次阅读 2020-06-01 17:28:48
    但是如果你想要找一个能够按进程实时统计网络带宽利用率的工具,那么NetHogs值得一。 【背景】在日常运维环境中,我们肯定会遇到以下这种需求: 1、网络流量异常,不知道是哪个程序的流量爆涨? 2、日常需要...
  • 大约在02年后,公司开始对计算机保密工作比较重视了,...于是我们所的书记找到我,问我能不一个限制优盘使用的软件。我大概花了不到5秒钟思考,说。当时我是这么想的,要想完成这项功能,那么首先需要判断优盘
  • Hadoop全链路监控解决方案

    千次阅读 2015-10-18 23:10:32
    前言我在最近的篇文章中都或多或少的提到了一个很重要的词-"监控".为什么要提到这个词呢,因为如果你和我一样是一名大数据工程师,你手下管理着批量的集群机器,并且同时这个集群的规模还会不定时的扩大,机器一旦变多...
  • 用过第二iftop 还不错 原文地址:http://www.piis.cn/jiaocheng/web1200.asp 这些工具使用不同的机制来制作流量报告。nload等一些工具可以读取"proc/net/dev"文件,以获得流量统计信息;而一些工具使用pcap库来...
  • RabbitMQ监控(1)——RabbitMQ简介

    千次阅读 2016-03-23 12:54:57
    最近公司想要开发一套针对RabbitMQ的监控系统,和短信及邮件接口整合,对性能做到实时的监控,表示这真的很及时,这样我们就“24小时不离岗”只要手机开着,就对网站性能有较好的把控,下面将分部介绍如何实现...
  • 多年以来一直以稳定运行为前提,确保业务永不掉线,带领运维团队自主开发了运维系统,包含,资产管理,工单管理,监控系统,域名管理,公有云管理,私有云管理等平台,并将运维数据进行分析整理,将运维工作透明化,...
  • DCIF分辨率的是视频图像来历是将奇、偶两个HALF D1,经反隔行变换,组成一个D1(720*576),D1作边界处理,变成4CIF(704×576),4CIF经水平3/4缩小、垂直2/3缩小,转换成528×384.528×384的像素数正好是CIF像素数...
  • 多个Zigbee监测网络远程监控的实现 作者:李 强  1....基于IEEE802.15.4标准的ZigBee传感器网络技术是一种短距离、低速率无线网络技术。...通常的实现方式是在两种异质网络的结合点(网关节点)上实现一个
  • 滴滴夜莺(Nightingale)是款经过大规模生产环境验证的、分布式高性能的运维监控系统。基于Open-Falcon,结合滴滴内部的最佳实践,在性能、可维护性、易用性方面做了大量的改进,支撑了滴滴内部数十亿监控指标,...
  • 视频监控技术概述

    千次阅读 2018-01-24 19:07:23
     视频监控技术按照主流设备发展过程,可以分为4大的阶段,即20世纪70年代开始的模拟视频监控阶段、20世纪90年代开始的数字视频阶段、2000年兴起的智能网络视频监控阶段及2010开始的高清视频监控阶段。  模拟监控...
  • 网络流量监控

    万次阅读 2018-10-11 15:35:07
    1.网络流量监控有什么用? 网络流量监控可以用来分析网络 ...镜像技术可以在不影响报文正常处理流程的情况下,将镜像端口的报文复制到份观察端口,用户利用数据监控设备来分析复制到观察端口的...
  • DevOps监控微服务的五条原则

    千次阅读 2017-11-16 14:51:35
    微服务的需求可以归纳为一个词:速度。这种更快提供功能完善且可靠的软件的需求,彻底改变了软件开发模式。毫无疑问,这个改变对软件管理,包括系统监控的方式,都产生了影响。在这篇文章里,我们将重点关注放在有效...
  • Zigbee监测网络远程监控的实现 多Zigbee监测网络远程监控的实现 作者:李 强  1.概述  基于IEEE802.15.4标准的ZigBee传感器网络技术是种短距离、低速率无线网络技术。其低功耗、易部署等特性...
  • 探讨研究无人机的3个出发点:1、最近在股权众筹平台,看到了一个“无人机”的项目,在考虑是否投点钱。股权投资是一项重大决策,需要认真调研相关资料。2、京东物流开始尝试无人机了,为了跟上公司的科技化步伐,...
  • 本文将介绍机器学习和统计分析的种不同技术和应用,然后展示如何应用这些方法来对特定用例进行异常检测和状态监控。 数字化转型,数字化,工业4.0等...... 这些都是你之前可能听过的术语。然而,这些流行语背后...
  • Linux进程实时监控监控工具

    万次阅读 2018-08-30 11:58:48
    背景说明: 一、htop是TOP的增强版;...Linux性能计数器是一个新的基于内核的子系统,它提供一个性能分析框架,比如硬件(CPU、PMU(Performance Monitoring Unit))功能和软件(软件计数器、tracepoin...
  • Zabbix中内置了很多监控参数(Key),可以获取监控对象中的系统、CPU、网络、内存、文件系统等信息。下面就详细介绍一下这些监控参数的意义。
  • 浅谈安防监控中视频图像处理技术

    千次阅读 2019-08-16 08:48:45
    随着计算机软件、硬件技术的日新月异的发展和普及,人类已经进入一个高速发展的信息化时代,人类大概有80%的信息来自图像,科学研究、技术应用中图像处理技术越来越成为不可缺少的手段。安防行业已经进入一个崭新的...
  • 舆情分析的几个概念

    万次阅读 2017-09-22 16:14:02
    下面是舆情分析领域的几个基础术语的定义,也可认为是研究方向,也为文本挖掘的任务和文献查找提供了思路。 舆情:通常是指较多群众关于现实社会及社会中各种现象、问题所表达的信念、态度、意见和情绪表现的总和;...
  • final—修饰符(关键字)如果一个类被声明为final,意味着它不再派生出新的子类,不作为父类被继承。因此一个类不既被声明为 abstract的,又被声 明为final的。将变量或方法声明为final,可以保证它们在使用中...
  • Spark程序监控

    千次阅读 2016-11-03 11:14:40
    任务和调度状态的列表 RDD大小和内存使用的统计信息 正在运行的executor的信息 环境信息 如果在同台机器上有多...在应用程序运行期间,你可以在这Web页面获得Spark实时监控信息,如果希望在程序运行完以后查
  • 但是从物联网的现状来,目前从技术上尚不实现像互联网一样,变成一个所有子网都可以无缝接入的全球一体化网络。这说明物联网的核心技术突破还需要很长的一段路要走。 物联网传输技术 3.物联网海量数据融合、...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 81,971
精华内容 32,788
关键字:

一个监控能看几个方向