建设DevOps统一运维监控平台
运维监控平台建设技术需求

运维监控平台建设技术需求1. 背景随着互联网的发展,现代企业对IT基础设施的重要性越来越高,因此企业运维的工作也越来越复杂。
运维人员需要不断监控各种系统的运行状况和性能数据,以及及时处理各种问题和故障,保证业务的稳定性和可靠性。
为此,需要建设一套完善的运维监控平台,以实现快速响应和及时处理各种运维问题。
2. 需求概述运维监控平台需要满足以下功能需求:2.1 监控数据采集和存储运维监控平台需要能够实时采集各个系统的性能数据和日志信息,并将数据存储到专门的数据库中。
同时,需要支持数据的自定义清洗、处理和逻辑分析,以便对系统性能进行有效监控和管理。
数据可以采用异步收集的方式,保证对被监控系统的运行影响最小。
2.2 监控数据分析和报警运维监控平台需要支持对采集的监控数据进行实时分析和计算,以便判断系统的性能是否正常,并及时向相应的运维人员发送报警通知,以便尽快解决问题。
为了实现有效的报警功能,可以设置报警规则和阈值。
2.3 监控数据可视化和报表运维监控平台需要支持对监控数据的可视化展示和分析,以便运维人员能够直观地了解系统的运行情况和性能指标。
监控数据报表需要支持自定义查询和生成,满足不同用户的需求。
2.4 历史数据管理和查询运维监控平台需要支持历史数据的记录和管理,以便对系统的性能进行历史记录和分析。
同时,需要支持用户自定义查询,以方便用户快速查找历史数据。
3. 技术架构需求为了实现运维监控平台的功能需求,需要考虑以下技术架构需求:3.1 高可用性和容错性运维监控平台需要支持高可用和容错性,以保证系统可以在面对故障和异常情况时,快速切换、恢复或者采取相应措施,保证系统的稳定性和可用性。
3.2 可扩展性和灵活性运维监控平台需要支持可扩展性和灵活性,以便随着业务的发展和扩大,可以方便地扩展系统的规模和容量,同时支持对相关模块的灵活配置和调整,以快速满足用户的需求。
3.3 数据安全和隐私运维监控平台需要保证数据的安全和隐私,以便防止私密数据泄露和未授权访问。
2023-统一运维管理平台总体建设方案V2-1

统一运维管理平台总体建设方案V2随着企业信息化程度的提升和业务规模的不断扩大,IT系统的管理和维护成为了一个关键的问题。
企业需要一种集中化的运维管理平台来提升运维效率和降低运维成本,同时还需确保IT系统的稳定性和安全性。
在这样的背景下,统一运维管理平台成为了必不可少的一项工程。
第一步,明确需求在开始统一运维管理平台的建设工作之前,首要的任务就是明确需求。
我们需要全面分析现有的IT系统和运维流程,建立用户需求和技术需求,确定统一运维管理平台的功能和特点。
第二步,选择合适的运维工具和系统由于不同的运维工具和系统功能和性能存在差异,因此需要根据需求选择合适的工具和系统。
我们需要根据数据中心的规模和复杂度来选择适合企业的运维工具,确保所有运维工作能够无缝连接并协同工作。
第三步,建立统一的管理平台在确定了可行的方案之后,我们需要开始建设统一运维管理平台。
由于不同的企业情况不一,建设统一运维管理平台的形式和步骤也会有所差异。
需要重点关注以下问题:1、统一数据采集和监控:建立统一的数据采集和监控平台,对各种设备和应用进行监控和数据采集,目的是为了发现系统中可能存在的问题并尽早排除。
2、自动化运维:考虑通过引入自动化运维技术,自动化运维可以降低人力成本,提高管理效率。
3、统一日志管理:运用日志管理技术,将各种设备和应用系统的日志统一收集和分析,便于分析排查问题。
4、统一监管和访问控制:建立统一的授权和访问控制机制,保障数据和应用程序的安全性。
第四步,运维管理平台的使用培训在完成了统一运维管理平台的建设之后,需要进行相关的运维人员使用培训和测试,确保运维人员能够熟练地使用平台,发现并解决问题。
总结统一运维管理平台建设是企业信息化建设的重要组成部分,对于优化IT系统运维和降低运维成本有着不可忽视的作用。
在建立统一运维管理平台过程中,我们需要全面明确需求,选择适合企业的运维工具和系统,建立统一的管理平台,以及进行人员的使用培训,确保运维工作顺利开展。
企业级DevOps平台建设方案

企业级DevOps平台建设方案一、DevOps 平台建设历程随着DevOps 理念的兴起,企业的数字化转型的需求也愈发强烈,于是开始着手研发DevOps 平台,并在这个过程中不断探索微服务、DevOps、容器云、ChatOps 等的关系和最佳实践。
这里为什么要强调“企业级”呢?一个小团队如果想要实现DevOps 能力其实可以很简单,因为团队规模不大,比较容易管理,同时负责的应用也不会特别多,通过集成一些开源的工具完全可以做到持续集成、持续部署、持续交付,同样可以带来极大的效率提升,这其实也是一些互联网企业内部小团队的特色。
但是当这一切放大到一个数百人,数千人甚至数万人的企业时,就会发现遇到的问题、阻碍呈几何级的上涨。
一个企业要考虑的因素太多,历史越悠久的企业,内部的文化、流程越是根深蒂固,而当一个平台需要打通整个IT 生命周期时,现有的文化、流程,现有的组织结构都不得不慎重推敲下是否能够满足。
所以,如何建设适合自己企业的DevOps 平台,即使现有市场的DevOps 理念已经基本普及开了,但是到落地的时候,却总会发现困难重重。
到底该怎么去落地呢?明确定位:DevOps 是覆盖IT 全生命周期的生产线对于DevOps 平台的定位还是要再明确下,DevOps 代表的含义早已不仅仅是简单的开发运维一体化,而是在此基础上,打通产品、项目的软件研发全生命周期,覆盖持续交付、持续改进等能力,在纵向打通应用的全生命周期(需求、设计、开发、编译、构建、测试、部署、运维等),横向打通架构、开发、测试、质量、运维、运营等部门。
我们把DevOps 分为三大领域,敏捷过程、持续交付、持续改进,三者相互独立却又相辅相成。
通过DevOps 平台将企业软件研发的全生命周期管理起来,在保证质量、安全的前提下,通过一些自动化的手段不断提升软件交付的效率,通过不断精益度量对过程、对技术持续改进,最终支撑起企业的IT 精益运营。
理清思维:DevOps 思维和互联网思维的区别可能很多人对于DevOps 的理念还存在这样的误解:DevOps 来源于互联网,也只适合互联网企业。
devops 运维管理制度

devops 运维管理制度(实用版4篇)目录(篇1)1.DevOps 概念及背景2.DevOps 与运维管理制度的关系3.DevOps 运维管理制度的特点4.DevOps 运维管理制度的实施5.DevOps 运维管理制度的优势和挑战正文(篇1)1.DevOps 概念及背景DevOps(开发运维一体化)是一种实践,其目的是缩短软件开发周期,提高软件质量,从而更好地满足业务需求。
在传统的软件开发和运维过程中,开发团队和运维团队往往各自为政,缺乏有效的沟通和协作。
DevOps 则倡导将这两个团队整合起来,实现软件开发和运维的无缝衔接。
2.DevOps 与运维管理制度的关系DevOps 是一种理念,而运维管理制度则是实现这一理念的具体方法。
在 DevOps 模式下,运维管理制度需要适应开发和运维一体化的要求,为开发者和运维人员提供统一的工作平台,确保项目的顺利推进。
3.DevOps 运维管理制度的特点- 强调自动化:DevOps 运维管理制度要求自动化运维流程,提高工作效率,减少人为错误。
- 强调协作:通过建立跨职能团队,实现开发和运维的无缝协作,确保项目快速推进。
- 强调持续交付:运维管理制度需要支持频繁的发布和部署,确保软件能够快速上线。
- 强调安全合规:在 DevOps 模式下,运维管理制度需要确保软件开发和运维过程的安全合规,避免风险。
4.DevOps 运维管理制度的实施实施 DevOps 运维管理制度需要从以下几个方面入手:- 建立跨职能团队:将开发团队和运维团队整合在一起,形成一个共同负责软件开发和运维的团队。
- 制定统一的流程:确保开发和运维团队遵循相同的流程,避免因沟通不畅而产生的问题。
- 引入自动化工具:利用自动化工具简化运维流程,提高工作效率。
- 确保安全合规:在实施 DevOps 运维管理制度的过程中,要重视安全合规性,避免因安全问题导致的风险。
5.DevOps 运维管理制度的优势和挑战优势:- 提高软件开发和运维效率,缩短项目周期。
企业IT监控运维平台建设方案

集中监控
✓ 所有系统都 纳入到统一 个平台进行 监控
✓ 监控信息集 中管理
统一策略
✓ 统一故障与 指标定义
✓ 故障的分析 策略设置
✓ 故障监控与 预测策略
统一告警
✓ 统一告警能 力支持
✓ 统一告警规 范设置
✓ 集中告警策 略配置
统一操作
✓ 统一故障告 警处理
✓ 统一故障自 动修复处理
及可靠的故障处理能力
现主动式IT监控与告警。
能化运维奠定基础。
。
18
实施效益
医发提考疗展升核行方日表业向常现
降低运维 人力成本
提升内外客 户满意度
提升 ICT收入
• 通过本次OMC平台的 实施,提升子公司的 系统运维能力,进而 可以满足母公司对子 公司各项运维动作的 要求,避免在日常考 核中失分。
7
目录
1
项目背景
2
建设目标
3
实施内容
4
平台特性
5
项目实施计划
8
总体解决方案
基于项目的背景与建设目标,本期将通过部署、实施一套智能化的IT监控平台系统。为公司注入全面采集 IT系统各级资源数据能力,智能化的故障与风险分析能力、主动故障告警能力,让IT维护人员能够及时发现、 甚至提前预测系统故障,进而帮助公司建立主动式的IT监控运维告警模式。
16
实现可视化IT系统监控以及深度的IT运维数据分析
平台提供了可视化报表监控系统,让管理人员可以直观、及时的掌握各系统的整体运行与故障情况,并进 行对应的工作安排。同时,系统还会对所采集到的指标数据、故障数据、故障风险等数据进行深度的分析,发 现故障的原因,指导系统的优化,帮助公司实现从传统的IT运维统计转向智能运维运营。
DevOps自动化运维平台介绍

运维自动化要诀
People Process
价值 观 文化
目标
DevOps
Tool
技术 合作
谢谢
工 具 库
权限系统 测试工具
文件中心 设备调度
包系统 路由系统
配置
脚本
变 更 通 知 中 心
命令通道
一致性监控
生产环境
Agenda
1
自动化与devops的动机
2
织云自动化平台简介
目录
CONTENTS
3
运维标准化的设计与实现
4
织云核心功能与架构
标准化与自动化
自动化
标准化
减对象,立标准
• • • • • • 组件选型 监控 容量 包管理 配置管理 测试工具 • • • •
事件
策略
• • •
执行
突发高负载 预测高负载 低负载>30天
流程
1. 2. 3. 4. 5. 6. 7.
平均负载 设备总数 高负载设备数 最高负载 高负载阀值 路由一致 上线时间
需求 决策API 容量系统
rabbitMQ
worker worker 流程系统
策略树
• • • L5 cmlb tgw
worker
4
织云核心功能与架构
为什么要自动化
30亿/年 人与程序 解放双手 拯救世界
行业 运维 企业 成本 趋势 使命 规模
10w机器 100人
云计算 devops
为什么要DevOps
DevOps是一种文化 DevOps是合伙人制
流程导向
DevOps依托于系统实现 DevOps is everywhere
新一代运维管理平台建设方案

新一代运维管理平台建设方案本文主要介绍新一代运维管理平台的建设思路,选这个主题,一方面是因为运维在整个IT生命周期中作用越来越重要,另一方面新的技术及架构给运维带来了新的方向与思考。
如何做好运维,成为更多企业及运维人员关心的重点。
一、运维平台的重要性随着信息化建设的不断发展,企业的IT已从原来的一个后台管理职能,转变成了生产营销中心,IT越来越多地渗透到企业生产运营之中。
同时IT技术架构也在逐步朝微服务、容器、云化、开源等方向演进,在新的架构规划体系下,IT系统将变得更加复杂,对于平台的运维支撑能力、资源支撑能力等带来更高的要求。
在当前的IT系统建设及数据中心规模扩强的速度下,没有一套合适的运维管理平台,运维工作将举步维艰,因此建设一个更可靠、更智能的运维管理平台就显得尤为重要。
二、运维平台发展历史广义上的运维平台发展经历了三个阶段:1.第一个阶段,以专业化网管工具为代表,包括网络设备、主机、数据库、中间件、存储等进行专业监控管理的各种专业化工具。
2.第二阶段,以ITIL流程化管理为代表的综合网管,通过事件、服务、流程等贯穿监控、变更、资产管理等一系列IT运维管理。
3.第三阶段,以敏捷、DevOps为代表的运维管理平台,主张开发运维一体化、自动化,强调需求、资源的服务化。
目前第三阶段还在迭代演进中,随着人工智能的新起,AIOps的概念开始盛行,因此结合敏捷及智能,成为新一代运维管理平台的建设的核心目标。
三、建设原则IT运维管理是一个非常宽泛的范围,整个IT生命周期都跟运维有着关系,运维难做,运维管理平台更难做,这个领域缺少标准和规范,目前也就Gartner对ITOM/ITOA有一些功能范围上的定义。
运维管理平台包括监控、ITSM、CMDB、自动化运维操作、日志分析、用户体验、APM、数据库管理、云平台管理、网络管理、业务监控、拨测、运维大数据等这些类别,有些企业建设了很多项目或购买了许多工具,但仍觉得用不上、不好用、用不起来,为什么?个人觉得包括几个方面原因,如管理思维的问题、技术架构的问题、组织文化的问题等。
统一运维大数据分析平台建设和应用综合解决方案

统一运维大数据分析平台建设和应用综合解决方案2020年3月30统一运维大数据分析管理平台建设方案目录第1章.方案概述 (4)1.1.项目背景 (4)1.2.需求分析 (5)1.3.建设目标 (7)1.3.1.建立统一运维门户 (7)1.3.2.建立IT异构资源的全面集中化管理 (7)1.3.3.建立全面准确的资产配置管理 (8)1.3.4.建立符合最佳实践的服务流程管理 (9)1.3.5.建立IT资源全面直观的可视化管理 (9)第2章.解决方案 (10)2.1.系统设计原则 (10)2.1.1.实用性和模块化原则 (10)2.1.2.一致性和开放性原则 (11)2.1.3.安全性与可靠性原则 (11)2.2.系统安全设计 (12)2.2.1.用户安全机制 (12)2.2.2.SSO统一认证 (12)2.2.3.权限分权分域 (12)2.3.系统建设方法 (13)2.3.1.体系架构 (13)2.3.2.功能架构 (17)2.3.3.技术架构 (17)2.3.4.部署架构 (18)第3章.功能概述 (19)3.1.运维监控系统 (19)3.1.1.统一运维管理 (19)3.1.2.资源监控管理 (23)3.1.3.拓扑管理 (45)3.1.4.IP地址管理 (59)3.1.5.告警管理 (61)3.1.6.业务管理 (66)3.2.3D机房管理 (70)3.2.1.监控可视化管理 (72)3.2.2.资产管理可视化 (76)3.2.3.机房3D图形化展示 (78)3.2.4.配线可视化管理 (80)3.2.5.容量可视化管理 (82)3.2.6.资源分配情况管理 (84)3.2.7.上下架可视化 (85)3.2.8.自定义动画 (86)3.2.9.交互式演示汇报 (87)3.3.配置文件管理 (87)3.3.1.巡检管理 (88)3.3.2.机房虚拟现实展现 (91)3.3.3.资产管理系统 (95)3.3.4.供应商管理 (96)3.3.5.配置建模管理 (97)3.3.6.空间资源管理 (99)3.3.7.配置项导入 (101)3.3.8.配置项管理 (102)3.3.9.配置项视图 (105)3.4.运维流程管理系统 (107)3.4.1.服务台 (107)3.4.2.服务设计 (115)3.4.3.服务产品设计向导 (116)3.4.4.服务流程管理 (135)3.4.5.服务量化管理 (169)3.4.6.值班管理 (186)3.4.7.任务管理 (192)3.4.8.公告管理 (193)3.4.9.移动终端运维 (194)3.4.10.报表统计分析 (196)3.4.11.第三方接口 (201)3.4.12.运维知识库系统 (203)3.5.统一运维大数据管理分析系统 (210)3.5.1.统一运维大数据基础系统 (210)3.5.2.统一运维数据分类管理 (210)3.5.3.运维大数据检索与展现 (215)3.5.4.海量日志文件分析 (219)3.5.5.指标动态基线预测 (223)3.5.6.运维支撑能力评估 (226)第1章. 方案概述1.1.项目背景运维大数据分析系统是一套深度分析和挖掘多种异构数据源运维数据的大数据平台。
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
建设DevOps统一运维监控平台--全面的系统监控日期:2017-03-14 17:20 浏览:100 评论:0前言随着Devops、云计算、微服务、容器等理念的逐步落地和大力发展,机器越来越多,应用越来越多,服务越来越微,应用运行基础环境越来多样化,容器、虚拟机、物理机不一而足。
面对动辄几百上千个虚拟机、容器,数十种要监控的对象,现有的监控系统还能否支撑的住?来自于容器、虚拟机、物理机、网络设备、中间件的指标数据如何采用同一套方案快速、完整的收集和分析告警?怎样的架构、技术方案才更适合如此庞大繁杂的监控需求呢?目录:一、统一监控平台架构解析二、系统监控的技术栈三、开源系统监控软件Zabbix VS Nagios VS Open-Falcon四、基于k8s容器云背景下的系统监控实践:cAdvisor+Heapster+Influxdb五、容器时代的监控利器:Prometheus一、统一监控平台架构解析先做一下回顾,统一监控平台由七大角色构成:监控源、数据采集、数据存储、数据分析、数据展现、预警中心、CMDB(企业软硬件资产管理)。
监控源:从层次上来分,大致可以分为三层,业务应用层、中间件层、基础设施层。
业务应用层主要包括应用软件、企业消息总线等,中间件层包括数据库、缓存、配置中心、等各种系统软件,基础设施层主要有物理机、虚拟机、容器、网络设备、存储设备等等。
数据采集:数据源如此多样,数据采集的任务自然轻松不了。
数据采集从指标上划分可以分为业务指标、应用指标、系统软件监控指标、系统指标。
应用监控指标如:可用性、异常、吞吐量、响应时间、当前等待笔数、资源占用率、请求量、日志大小、性能、队列深度、线程数、服务调用次数、访问量、服务可用性等,业务监控指标如大额流水、流水区域、流水明细、请求笔数、响应时间、响应笔数等,系统监控指标如:CPU负载、内存负载、磁盘负载、网络IO、磁盘IO、tcp连接数、进程数等。
从采集方式来说通常可以分为接口采集、客户端agent采集、通过网络协议主动抓取(http、snmp等)数据存储:采集到的数据一般都会存储到文件系统(如HDFS)、索引系统(如elasticsearch)、指标库(如influxdb)、消息队列(如kafka,做消息临时存储或者缓冲)、数据库(如mysql)数据分析:针对采集到的数据,进行数据的处理。
处理分两类:实时处理和批处理。
技术包括Map/Reduce计算、全日志检索、流式计算、指标计算等,重点是根据不同的场景需求选择不同的计算方式。
数据展现:将处理的结果进行图表展现,在多屏时代,跨设备的支持必不可少。
预警:如果在数据处理过程发现了问题,则需要进行异常的分析、风险的预估以及事件的触发或告警。
CMDB(企业软硬件资产管理):CMDB在统一监控平台中是很重要的一环,监控源虽然种类繁多,但是他们大都有着关系,如应用运行在运行环境中,应用的正常运行又依赖网络和存储设备,一个应用也会依赖于其他的应用(业务依赖),一旦其中任何一个环节出了问题,都会导致应用的不可用。
CMDB 除了存储软硬件资产外,还要存储这样一份资产间的关联关系,一个资产发生了故障,要能根据这个关系迅速得知哪些其他的资产会被影响,然后逐一解决问题。
OK,回顾到此为止,进入正题,系统监控。
二、系统监控的技术栈系统监控的部分技术栈如下图所示,监控技术众多,这里自然不可能列出所有的技术,选择了部分比较经典、受欢迎的开源技术。
系统监控不同于日志监控,有很多开源软件把数据库采集、数据存储、数据展现、事件告警的任务都完成了,所以对于系统监控的技术栈中,将这些开源软件暂且排除,待后面章节再进行讲解。
此处主要关注于如何自建一个统一系统监控平台。
数据采集:系统监控数据采集一般分为两种方式:主动采集、客户端采集。
主动采集一般是通过SNMP、SSH、Telnet、IPMI、JMX等手段进行远程采集,客户端采集则是需要在每一个要监控的主机中部署一个客户端进行数据采集并发送到远程服务端进行接收。
数据缓冲:和日志监控一样,在面临海量监控时,考虑到网络的压力和数据处理的瓶颈,可以在数据存储前先经过一层数据缓冲,将采集到的数据先放置到消息队列中,然后再从分布式队列中读取数据并存储。
如果数据量不大的话,则可以不考虑此层。
数据存储:对于系统监控数据,通常采用时序数据库来存储,时序数据库全称为时间序列数据库。
时间序列数据库主要用于指处理带时间标签(按照时间的顺序变化,即时间序列化)的数据,带时间标签的数据也称为时间序列数据。
如influxdb和opentsdb,是其中翘楚。
OpenTSDB是用hbase存储所有的时序(无须采样)来构建的一个分布式、可伸缩的时间序列数据库,可以从大规模的集群(包括集群中的网络设备、操作系统、应用程序)中获取相应的metrics并进行存储、索引以及服务,从而使得这些数据更容易让人理解,如web 化,图形化等。
用JAVA语言实现,对于JAVA系的同学们是一个福音,不过其依赖hbase 也许会让一部分同学望而却步,毕竟还要先去维护hbase。
Influxdb是新兴的一个时序数据库,用go语言编写,无需外部依赖,发展很快,最新版本已经到了1.2。
提供类sql的查询语法,安装方便,单点即可使用,虽然有集群的能力,不过该特性是非开源的(不过单点性能基本也都能满足企业需求了)。
提供Http API,便于调用和封装。
对于想基于influxdb自行进行数据处理和展现的同学们而言很是友好。
数据展现:说到时序数据的图形化展现,Grafana是一个不得不提的利器。
Grafana是一个开源的时序数据的查询和展现软件,提供了灵活丰富的图形化选项;可以混合多种风格,有着功能齐全的度量仪表盘和图形编辑器。
支持与Graphite、Elasticsearch、CloudWatch、Prometheus、InfluxdbDB等众多数据存储对接,进行数据的查询和图表展现。
一些开源的监控软件如zabbix、Graphite、Prometheus也都有着自己的数据图形化展现能力,但是一般也都是建议使用Grafana来代替它们的页面。
可想而知Grafana的优秀。
当然,Grafana的数据源都是来自时序数据库,在实际场景中,可能你想要查看的报表的一部分数据还来自于业务系统,这就是Grafana或者其他的监控软件做不到的了,去扩展是一种方式,另外一种方式就是结合自己的需求实现图表展现,通过对时序数据的计算分析以及结合业务数据,使用如echarts等开源图表前端框架进行展现。
这时候Influxdb的优势就体现出来了,对外提供http api非常适合自主封装图形化页面。
告警:在日志监控的分享中,确实没有对告警进行说明。
像Zabbix、Nagios、Open-Falcon、Prometheus等开源监控软件,都是有些自己的告警能力的。
如果你采用了他们作为监控平台,实际上告警能力就已经有了。
如果是纯自建统一监控平台的话,也可以自己实现告警中心。
我们自己的做法是,在数据处理时,根据配置的事件触发规则,生成相应事件扔到kafka 中,事件处理引擎监听kafka中的事件数据,进行解析并根据事件处理策略进行告警通知等处理。
三、开源系统监控软件Zabbix VS Nagios VS Open-Falcon上面大致介绍了运维监控的技术栈,但是实际上已经有些开源监控软件功能都很全面,从数据采集到数据展现都提供了支持,如果是小团队,不想自建监控平台的话,选择这些开源软件其实是一个很好的选择。
ZabbixZabbix是一个企业级的开源分布式监控解决方案,支持实施从数以万计的服务器、虚拟机、网络设备等收集百万的指标数据,具备常见的商业监控软件所具备的功能(主机的性能监控、网络设备性能监控、数据库性能监控、FTP等通用协议监控、多种告警方式、详细的报表图表绘制)支持自动发现网络设备和服务器;支持分布式,能集中展示、管理分布式的监控点;扩展性强,server提供通用接口,可以自己开发完善各类监控。
Zabbix重要组件说明:zabbix server:负责接收agent发送的报告信息的核心组件,所有配置、统计数据及操作数据都由它组织进行;database storage:专用于存储所有配置信息,以及由zabbix收集的数据;web interface:zabbix的GUI接口;proxy:可选组件,常用于监控节点很多的分布式环境中,代理server收集部分数据转发到server,可以减轻server的压力;agent:部署在被监控的主机上,负责收集主机本地数据如cpu、内存、数据库等数据发往server端或proxy端;优点:All in One:部署相当便捷Server对宿主机性能要求很低。
自动发现服务器与网络设备分布式监控,以及WEB集中管理功能同时支持agent采集和无agent采集,主机通过agent 或者ipmi采集数据,网络设备、存储设备等通过SNMP 客户端采集数据,agent支持常用的UNIX和Windows操作系统功能全面,数据采集、数据存储、数据展现、事件告警。
开放式接口,扩展性强,插件编写容易不足:数据库瓶颈,使用mysql作为底层存储,大数据读写的时候,对于数据库的压力非常大需要在主机中安装agent对容器监控支持不好,需要自己扩展。
NagiosNagios 全名为(Nagios Ain’t Goona Insist on Saintood),最初项目名字是NetSaint。
它是一款免费的开源IT 基础设施监控系统,其功能强大,灵活性强,能有效监控Windows 、Linux、VMware 和Unix 主机状态,交换机、路由器等网络设置等。
Nagios核心功能是监控报警,告警能力很不错,但是图形展示效果很差。
同时nagios更加灵活,很多功能都要通过插件化来实现,对于技术能力没那么强的同学,上手会有些困难。
当然,对于运维老手,上手会很快。
Nagios 的功能特性如下:监控网络服务(SMTP、POP3、HTTP、NNTP、PING等);监控主机资源(处理器负荷、磁盘利用率等);简单地插件设计使得用户可以方便地扩展自己服务的检测方法;并行服务检查机制;具备定义网络分层结构的能力,用"parent"主机定义来表达网络主机间的关系,这种关系可被用来发现和明晰主机宕机或不可达状态;当服务或主机问题产生与解决时将告警发送给联系人(通过EMail、短信、用户定义方式);可以定义一些处理程序,使之能够在服务或者主机发生故障时起到预防作用;自动的日志滚动功能;可以支持并实现对主机的冗余监控;可选的WEB界面用于查看当前的网络状态、通知和故障历史、日志文件等;Open-FalconOpen-Falcon是小米运维部门开源出来的互联网企业级监控系统,目前包括小米、金山云、美团、京东金融、赶集网等都在使用Open-Falcon。