高可用——网站运行监控

“不允许没有监控的系统上线”,这是许多网站架构师在做项目上线评审时常说的一句话。

网站运行监控对于网站运维和架构设计优化至关重要,运维没有监控的网站,由于驾驶没有仪表的飞机。

一、监控数据采集

广义上的网站监控涵盖所有非直接的业务行为的数据采集与管理,

包括共数据分析师和产品设计师使用的网站用户行为日志、业务运行数据,以及供运维工程师和开发工程师使用的系统性能数据等。

1.用户行为日志收集

用户行为日志指用户在浏览器上所做的所有操作及其所在的操作环境,

包括用户操作系统和浏览器版本信息、IP地址、页面访问路径、页面停留时间等

这些数据对统计网站PV/UV指标、分析用户行为、优化网站设计、个性化营销与推荐等等非常重要。

具体用户行为日志收集手段有两种。

(1)服务器端日志收集

这个方案比较简单,Apache等几乎所有Web服务器都具备日志记录功能,可以记录大部分日志行为日志,开启Web服务器的日志记录功能即可。

其缺点是可能会出现信息失真,如IP地址是代理服务器地址而不是用户真实IP;无法识别访问路径等。

(2)客户端浏览器日志收集

利用页面嵌入专门的JavaScript脚本可以收集用户真实的操作行为,因此比服务器日志收集更加精准,

其缺点是比较麻烦,需要在页面嵌入特定的Javascript脚本来完成。

此外,大型网站的用户日志数据量惊人,数据处理与计算压力很大,

目前许多网站逐步开发基于实时计算框架Storm的日志统计与分析工具。

2.服务器性能监控

收集服务器性能指标,如系统Load、内存占用、磁盘IO等尽早做出故障预警,及时判断应用状况,防范于未然,将故障扼杀在萌芽时期非常重要。

此外根据性能监控数据,运维工程师可以合理安排服务器集群规模,架构师即使改善系统性能,调整伸缩性策略。

目前网站使用比较广泛的开源性能监控工具是Ganglia,它支持大规模服务器集群,并支持以图形的方式在浏览器展示实时性能曲线。

3.运行数据报告

除了服务器系统性能监控,网站还需要控制一些与具体业务场景相关的技术和业务指标,

比如缓冲命中率、平均响应延迟时间、每分钟发送邮件数目、待处理的任务总数等。

对于服务器性能监控,网站运维人员可以在初始化系统时统一部署,应用程序开发完全不关心服务器性能监控。

而运行数据需要在具体程序中采集报告,汇总后统一显示,应用程序需要在代码中处理运行数据采集的逻辑。

二、监控管理

监控数据采集后,除了用作系统性能评估、集群规模伸缩性预测等,还可以根据实时监控数据进行风险预警,

并对服务器进行失效转移,自动负载调整,最大化利用集群所有机器的资源。

1.系统报警

在服务器正常运行的情况下,在各项监控指标都维持在一个特定水平,如果这些指标超过某个阀值,

就意味着系统可能将要出现故障,这时就需要对相关人员报警,及时采取措施,在故障还未发生时就将其扼杀在萌芽状态。

监控管理系统可以配置报警阀值和值守人员的联系方式,报警方式除了邮件,即时通信工具,

还可以配置手机短信、语音报警,系统发生报警时,工程师即使在千里之外也能及时被通知。

2.失效转移

除了应用程序访问失败进行失效转移,监控系统还可以在发现故障的情况下主动通知应用,进行失效转移。

3.自动优雅降级

优雅降级是指网站为了应付突然爆发的访问高峰,主动关闭部分功能,释放部分系统资源,保证网站核心功能正常访问的一个手段。

网站在监控管理基础上实现自动优雅降级,是网站柔性架构的理想状态:

监控系统实时监控所有服务器的运行状况,根据监控参数判断应用访问负载情况,

如果发现部分应用负载过高,而部分应用负载过低,就会适当卸载负载应用部分服务器,

重新安装启动部分高负载应用,使应用负载整体均衡,如果所有应用负载都很高,而负载压力还在继续,就会自动关闭部分非重要功能,保证核心功能的正常运行。

原文地址:https://www.cnblogs.com/yangmingxianshen/p/8411649.html

时间: 2024-08-06 03:52:00

高可用——网站运行监控的相关文章

Redis高可用部署及监控

Redis高可用部署及监控 目录                        一.Redis Sentinel简介 二.硬件需求 三.拓扑结构 1.单M-S结构 2.双M-S结构 3.优劣对比 四.配置部署 1.Redis配置 2.Redis Sentinel配置 3.启动服务 4.故障模拟检测 五.备份恢复 1.备份策略 2.灾难恢复 六.运维监控 1.安全监控 2.性能监控   一.           Redis Sentinel简介   Redis Sentinel是redis自带的集

大型网站技术架构,5网站的高可用架构之高可用网站的软件质量保证

5.6 高可用网站的软件质量保证 在网站运维实践中,除了网络.服务器等硬件故障导致的系统可用性风险外,还有来自软件系统本身的风险. 本节不再赘述传统的软件测试和软件质量保证管理,而是讲一些不同的质量保证手段. 5.6.1 网站发布 网站的发布过程事实上和服务器宕机效果相当,其对系统可用性的影响也和服务器宕机相似. 由于应用的不断发布,用户需要面对的是每周一到两次的宕机故障. 但是,网站发布毕竟是一次提前预知的服务器宕机,所以过程可以更柔和,对用户影响更小.通常使用发布脚本来完成发布,其流程如下图

构建高性能高可用网站设计要点总结

顺序不代表重要性,请根据场景自行斟酌! 1.高可用:破除单点故障.保证服务无状态或者状态一致,任何节点挂掉不应该影响整个服务,服务启动后可以被自动发现.使用LVS或Nginx负载均衡,需要支持水平扩容. 2.模块化:任何系统都不应该太复杂,不应该承担太多责任,按照低耦合高内聚的原则,需要将系统抽象为多个模块,分而治之. 3.依赖链:根据依赖倒置原则,高层模块不该依赖低层模块,模块之间的依赖链尽量清晰有序,避免循环依赖.依赖密切的两个模块可以考虑合并,或者共用一个中介者对外提供服务. 4.监控:通

高可用网站多点部署架构实战经验总结

本文是学习大型分布式网站架构的技术总结.对架构一个高性能,高可用,可伸缩,可扩展的分布式网站进行了概要性描述,并给出一个架构参考.一部分为读书笔记,一部分是个人经验总结.对大型分布式网站架构有很好的参考价值. 一.大型网站的特点 用户多,分布广泛 大流量,高并发 海量数据,服务高可用 安全环境恶劣,易受网络攻击 功能多,变更快,频繁发布 从小到大,渐进发展 以用户为中心 免费服务,付费体验 二.大型网站架构目标 高性能:提供快速的访问体验. 高可用:网站服务一直可以正常访问. 可伸缩:通过硬件增

阿里P9架构师谈:高并发网站的监控系统选型、比较、核心监控指标

在高并发分布式环境下,对于访问量大的业务.接口等,需要及时的监控网站的健康程度,防止网站出现访问缓慢,甚至在特殊情况出现应用服务器雪崩等场景,在高并发场景下网站无法正常访问的情况,这些就会涉及到分布式监控系统,对于核心指标提前监控,防患于未然. 常见的开源监控系统 1.Zabbix Zabbix是一个基于WEB界面的提供分布式系统监控以及网络监控功能的企业级开源运维平台,也是目前国内互联网用户中使用最广的监控软件. 入门容易.上手简单.功能强大并且开源免费. Zabbix易于管理和配置,能生成比

读书笔记5大型网站的高可用架构

一.网站实现高可用的手段 实现高可用架构的主要手段是数据和服务的冗余备份和失效转移,一旦某些服务器宕机,就将服务切换到其他可用的服务器上,如果磁盘损坏,则从备份的磁盘读取数据 二.可用性度量与考核 首先,不得不说:要保证一个网站永远完全可用几乎是一件不可能完成的任务(Mission Impossible,是不是有点碟中谍的感觉). (1)如何度量网站可用性? 一个神奇的数字—9!你有几个9,就代表了你的可用性.例如QQ可用性达到了4个9:99.99% ①2个9=基本可用 ②3个9=较高可用 ③4

大型网站技术架构(五)--网站高可用架构

大型网站技术架构(一)--大型网站架构演化 大型网站技术架构(二)--架构模式 大型网站技术架构(三)--架构核心要素 大型网站技术架构(四)--网站的高性能架构 网站的可用性(Avaliability)描述网站可有效访问的特性. 1.网站可用性的度量与考核       网站不可用时间(故障时间)=故障修复时间点-故障发现(报告)时间点       网站年度不可用时间=(1-网站不可用时间/年度时间)× 100% 可用性指标时网站架构设计的重要指标,对外是服务承诺,对内是考核指标,具体到每个工程

大型网站技术架构(五)--网站高可用架构(转)

网站的可用性(Avaliability)描述网站可有效访问的特性. 1.网站可用性的度量与考核       网站不可用时间(故障时间)=故障修复时间点-故障发现(报告)时间点       网站年度不可用时间=(1-网站不可用时间/年度时间)× 100% 可用性指标时网站架构设计的重要指标,对外是服务承诺,对内是考核指标,具体到每个工程师,更多的是使用故障分.      所谓故障分是指对网站故障进行分类加权计算故障责任的方法.如下是个案例: 分类 描述 权重 事故级故障 严重故障,网站整体不可用

网站高可用架构--二

可复用的服务模块为业务产品提供基础公共服务,这些服务通常独立分布式部署,被具体应用远程调用.可复用的服务和应用一样,都是无状态服务,应此可以使用类似负载均衡的失效转移策略实现高可用的服务.除此之外,具体实践中,还有以下几点高可用的服务策略: 1.分级管理 运维上将服务器进行分级管理,核心应用和服务优先使用更好的硬件,在运维响应速度上也格外迅速.同时在服务部署上也进行必要的隔离,避免故障连锁反应.低优先级的服务通过启动不同的线程或者部署在不同的虚拟机上进行隔离,而优先级较高的服务需要部署在不同的物