建设DevOps统一运维监控平台
运维监控平台解决方案

运维监控平台解决方案
《运维监控平台解决方案》
随着企业科技的发展,IT基础设施的复杂性和规模不断增加,运维监控变得至关重要。
然而,传统的手动监控方法已经远远不能满足当前的需求。
因此,许多企业正在寻找更高效和智能的解决方案来优化他们的运维监控。
在当前的云计算和大数据环境下,运维监控平台解决方案变得尤为重要。
这样的解决方案可以帮助企业实时监控其IT基础
设施的状态,发现并解决潜在的问题,从而提高系统的可靠性和稳定性。
在这个过程中,运维监控平台解决方案需要具备以下特点:
1. 自动化监控:运维监控平台需要能够自动监控和收集各种系统指标和日志,提供可视化的报表和图表,帮助管理员快速发现和诊断问题。
2. 实时警报:平台需要能够及时发出警报并给出解决方案,以便运维人员可以迅速采取行动,减少系统故障对业务的影响。
3. 大数据分析:平台需要具备大数据分析的能力,可以分析历史数据,识别系统的异常和趋势,并提供智能化的预测和建议。
4. 故障排查:平台需要提供全面的排查工具,帮助运维人员快速定位并解决故障,缩短故障修复的时间。
5. 安全性和可扩展性:平台需要具备强大的安全机制,确保数据的保密性和完整性。
同时需要具备良好的可扩展性,以应对不断增长的数据量和系统规模。
综上所述,运维监控平台解决方案是企业IT运维管理的重要工具,可以帮助企业提高系统的可靠性和稳定性,降低运维成本,提高服务质量。
因此,企业应该根据自身的需求和实际情况,选择适合自己的运维监控平台解决方案,并不断优化和升级,以应对未来的挑战。
2023-统一运维管理平台总体建设方案V2-1

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

规划
人员
技术
项目的组织架构
项目发起人
何**
运维研发
甲方:郭**、吴*华、刘*、陈*、张*芝 、韩*武 、陶*龙 乙方:
负责人:罗*强对接人:杨*超、
甲:段** 乙:***
项目经理
IT项目管理
王*
项目指导委员会
陈*峰、魏*、李*、顾*、何*敏、倪*、朱*、朱*
快递环境项目推广
立项决策人
杨**
架构师
甲方:何** 乙方:***
测 试
运 维
开发
测 试运 维Fra bibliotek规范优先、效率低、成本高
质量、效率、成本、规范之间平衡
面向管理过程(ITIL流程)
面向IT运营过程(执行)--DevOps
从软件研发模式看DevOps
集成团队!共享面向客户的价值共享集成目标共享质量责任
Test
Dev
QA
、生产
预发布
Dev
Ops
研发
敏捷迭代 0
质量保证1 2
环境部署、故障定位、日志拉 取、数据库优化、业务故障定 位(人工)
环境管理、持续集成、持续交付、 智 能监控、IT运营分析、故障自愈、容 灾切换
基础设施、数据存储运维自动化管理、架构微 服务化(部分)、Docker容器化、DevOps 持续交付、双中心(试点)、故障预防,IT运 营分析
研发者PaaS平台、Docker容器化平 台、架构微服务化、双中心、机器学 习、舆情分析、IT运营分析
开发测试团队。设立测试研发团队,负 责测试能力自动化。
DevOps研发团队。负责从持续交付的角 度端到端的能力集成。
服务主管、流程主管角色不变。
资源 交付 团队
Opsview运维监控平台解决方案

Opsview运维监控平台解决方案简介Opsview是一种强大的运维监控平台,用于管理和监控企业的IT 基础设施。
本文档将介绍Opsview的功能特点以及如何实施和管理这个解决方案。
功能特点Opsview提供了以下功能特点:1. 综合监控: Opsview通过集成多种监控工具和插件,提供了全面的监控能力,包括服务器、网络设备、数据库、应用程序等多个方面。
综合监控: Opsview通过集成多种监控工具和插件,提供了全面的监控能力,包括服务器、网络设备、数据库、应用程序等多个方面。
2. 灵活可定制: Opsview允许用户根据自己的需求和环境进行定制,可以轻松添加新的监控任务和告警规则,满足不同业务的监控需求。
灵活可定制: Opsview允许用户根据自己的需求和环境进行定制,可以轻松添加新的监控任务和告警规则,满足不同业务的监控需求。
3. 实时告警: Opsview能够实时监测系统状态和性能,并在出现问题时及时发送告警通知,帮助管理员快速响应和解决问题。
实时告警: Opsview能够实时监测系统状态和性能,并在出现问题时及时发送告警通知,帮助管理员快速响应和解决问题。
4. 数据分析: Opsview提供丰富的数据分析功能,包括图表、报表等,帮助管理员了解系统的趋势和性能表现,并及时做出相应的调整和优化。
数据分析: Opsview提供丰富的数据分析功能,包括图表、报表等,帮助管理员了解系统的趋势和性能表现,并及时做出相应的调整和优化。
5. 集成性: Opsview可以与其他企业系统集成,如CMDB、Ticketing系统等,实现监控数据的共享和联动。
集成性: Opsview 可以与其他企业系统集成,如CMDB、Ticketing系统等,实现监控数据的共享和联动。
实施和管理1. 需求分析: 在实施Opsview解决方案之前,需要对企业的监控需求进行详细分析,明确要监控的对象和指标,以及告警的规则和通知方式。
统一运维大数据分析管理平台建设方案 智慧运维大数据分析平台建设方案

统一运维大数据分析管理平台建设方案统一运维大数据分析管理平台建设方案目录第1章.方案概述 (4)1.1.项目背景 (4)1.2.需求分析 (5)1.3.建设目标 (6)1.3.1.建立统一运维门户 (6)1.3.2.建立IT异构资源的全面集中化管理 (7)1.3.3.建立全面准确的资产配置管理 (7)1.3.4.建立符合最佳实践的服务流程管理 (8)1.3.5.建立IT资源全面直观的可视化管理 (8)第2章.解决方案 (10)2.1.系统设计原则 (10)2.1.1.实用性和模块化原则 (10)2.1.2.一致性和开放性原则 (10)2.1.3.安全性与可靠性原则 (11)2.2.系统安全设计 (11)2.2.1.用户安全机制 (11)2.2.2.SSO统一认证 (12)2.2.3.权限分权分域 (12)2.3.系统建设方法 (12)2.3.1.体系架构 (12)2.3.2.功能架构 (16)2.3.3.技术架构 (16)2.3.4.部署架构 (17)第3章.功能概述 (18)3.1.运维监控系统 (18)3.1.1.统一运维管理 (18)3.1.2.资源监控管理 (22)3.1.3.拓扑管理 (41)3.1.4.IP地址管理 (53)3.1.5.告警管理 (56)3.1.6.业务管理 (60)3.2.3D机房管理 (64)3.2.1.监控可视化管理 (65)3.2.2.资产管理可视化 (70)3.2.3.机房3D图形化展示 (72)3.2.4.配线可视化管理 (74)3.2.5.容量可视化管理 (76)3.2.6.资源分配情况管理 (78)3.2.7.上下架可视化 (79)3.2.8.自定义动画 (80)3.2.9.交互式演示汇报 (80)3.3.配置文件管理 (81)3.3.1.巡检管理 (82)3.3.2.机房虚拟现实展现 (84)3.3.3.资产管理系统 (88)3.3.4.供应商管理 (88)3.3.5.配置建模管理 (89)3.3.6.空间资源管理 (91)3.3.7.配置项导入 (93)3.3.8.配置项管理 (94)3.3.9.配置项视图 (97)3.4.运维流程管理系统 (99)3.4.1.服务台 (99)3.4.2.服务设计 (106)3.4.3.服务产品设计向导 (107)3.4.4.服务流程管理 (123)3.4.5.服务量化管理 (155)3.4.6.值班管理 (171)3.4.7.任务管理 (176)3.4.8.公告管理 (177)3.4.9.移动终端运维 (178)3.4.10.报表统计分析 (180)3.4.11.第三方接口 (184)3.4.12.运维知识库系统 (185)3.5.统一运维大数据管理分析系统 (192)3.5.1.统一运维大数据基础系统 (192)3.5.2.统一运维数据分类管理 (192)3.5.3.运维大数据检索与展现 (197)3.5.4.海量日志文件分析 (200)3.5.5.指标动态基线预测 (204)3.5.6.运维支撑能力评估 (206)第1章. 方案概述1.1.项目背景运维大数据分析系统是一套深度分析和挖掘多种异构数据源运维数据的大数据平台。
企业级DevOps平台建设方案

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

统一运维大数据分析平台建设和应用综合解决方案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。