标签：Monitoring

共 30 篇相关文章

IT 累计浏览 2,681

脚本错误量极致优化-监控上报与Script error

这篇讲的是前端监控中一个常见痛点：脚本错误上报后却只拿到一堆无用的“Script error.”信息，无法定位问题。作者以手Q家校群的优化实践为案例，系统梳理了从监控到上报的完整流程。文章首先厘清了两种核心监控方式：try-catch用于捕获特定代码块的已知错误，而window.onerror则像一张大网，能捕获全局未预料的语法和运行时错误。两者结合，才能高效地构建监控体系。在信息上报环节，介绍了通过动态创建Image标签这类轻量可靠的常见做法。但文章的重点和亮点在于深入剖析了“Script error”的成因。它揭示了当页面加载并执行跨域脚本（例如CDN上的脚本）时，出于安全策略，浏览器会阻断详细的错误信息传递，只返回一个笼统的“Script error.”。针对这一经典难题，文章指出了根本解法：需要同时在服务器端为跨域JS文件设置正确的CORS响应头，并在客户端为script标签添加crossOrigin属性，这样才能让onerror事件获得完整的错误详情。对于前端开发者而言，这篇文章的价值在于它不仅讲清了“怎么做”，更讲透了“为什么”，提供了一套可落地的脚本错误监控最佳实践，直接助力提升线上项目的稳定性和问题排查效率。

IT 累计浏览 3,041

《火星救援》中你应该知道的5个高可用系统故障恢复原则

这篇文章从电影《火星救援》出发，将主角马克·沃特尼的火星生存挑战，与互联网高可用系统的故障恢复实践做了精彩类比，提炼出了五条关键原则。作者指出，故障发生时应秉持信息透明原则，及时向内部与外部同步状态，这比隐瞒问题更能赢得理解与支援。面对紧迫的恢复时限，技术负责人需在信息不全的情况下快速决策。在解决过程中，既要鼓励工程师发挥主观能动性积极尝试，也要善于利用系统预留的“救生锤”——比如那些99.9%时间不用的功能开关或旧接口。最后，当常规手段失效时，可能需要像电影里抛弃所有负重一样，采取一些简单粗暴但有效的方法来快速恢复服务，事后再进行数据修复。文章没有停留在抽象理论，而是紧扣电影情节与技术场景的对应点，比如NASA的新闻发布会对应故障公告，探路者号对应遗留系统，让这些工程原则变得生动可感。文末那个马克在地球喝咖啡的比喻，也巧妙点出了运维人员平凡日常中的珍贵。

IT 累计浏览 3,161

限流系统如何发现系统的热点

这篇讲的是如何利用限流系统的内部机制，来解决一个棘手的实际问题：如何在海量调用参数中，实时发现系统热点。作者从热点的两个核心挑战出发：一是如何在海量参数中只保留最可能成为热点的记录，二是如何在分布式集群中高效汇总统计信息。文章的核心方案巧妙地结合了两种技术：用ConcurrentLinkedHashMap（一种LRU缓存结构）控制内存，仅保存近期访问量最高的参数；同时利用限流系统已有的动态滑动窗口算法，计算这些参数在短时间内的平滑QPS。对于分布式统计，文章利用了限流系统自身暴露的QPS端口作为数据采集点，并通过多线程任务队列进行快速合并，使得在千台机器规模的集群上也能在数秒内获得结果。最终的性能数据表明，该方案在日常机器上可达到29万的吞吐量，内存消耗可控，有效解决了实时热点发现与系统性能之间的平衡问题。

IT 累计浏览 2,460

软件开发中的最佳实践是什么？

这篇讲的是“最佳实践”这个在软件开发领域被频繁使用、却又充满歧义的术语。作者从自身发布的教程出发，犀利地指出，这个词在不同语境下至少有三种截然不同的面貌。他将其梳理为一个“连续统一体”：最理想的状态是实践经验证优于其他所有方法；更常见的是被标准机构或行业广泛接受的“标准化实践”；而最要警惕的，则是用它作为挡箭牌、让个人主张显得更权威的“愤世嫉俗”用法。作者进而列举了敏捷、自动化测试、持续集成、设计模式、代码审查等一系列常被奉为圭臬的行业实践。他抛出了关键问题：在共同认可的行业智慧与盲目追随之间，界线何在？一个实践如何从“因为别人说好”，进阶到经过客观评估、证明对特定团队和组织确实有效？文章的真正目的，是提供一套启发式框架，帮助开发者穿越技术热情与组织实际效益之间的张力。它鼓励读者超越口号，基于可衡量的数据和事实去审辨，最终弄清楚哪些所谓的“最佳实践”，才是对你真正有益的实践。

IT 累计浏览 2,742

监控进程

这篇讲的是Linux下如何更灵活地监控和管理进程。当服务因资源耗尽、程序崩溃或误操作意外终止时，虽然系统自带的SysVinit、Upstart或Systemd能实现基础重启，但应对“CPU占用超标就重启”或“同时管理数百个PHP Worker”这类复杂场景就显得力不从心。文章随后深入对比了Monit和Supervisor两款专业工具。Monit通过轮询进程状态，能实现基于资源阈值的智能监控与重启，比如配置其在Nginx的CPU使用率连续5次超过80%时自动重启。Supervisor则擅长批量管理同类进程，可以轻松配置并维持100个PHP Worker进程的常驻数量，它更专注于进程的生命周期管理。不过，两者各有特点。Monit更像一个灵活的资源监控与响应器；Supervisor则是强大的进程组管理器，但通常要求被管理的进程以前台模式运行。文章还巧妙地解决了一个递归问题：如何监控监控者本身？通过让SysVinit来“守护”Supervisor进程，利用系统的初始化能力构建了一道最后的防线。

IT 累计浏览 4,261

服务器监控软件Zabbix初窥

这篇讲的是作者从工作中对服务器监控系统的兴趣出发，初次探索了开源监控软件Zabbix的体验。Zabbix始创于2001年，使用C语言和PHP开发，以GPL v2开源发布，经过十多年积累已形成成熟的解决方案。作者详细描述了安装过程：从SourceForge下载源码包，按照官方Wiki配置后直接make install，整个过程出乎意料地简单顺畅，比以往编译其他软件轻松得多。前端安装也不复杂，类似WordPress的配置。文章接着解析了Zabbix的核心概念：通过host group分组管理主机，定义item监控属性（如CPU、内存、网络流量），设置trigger触发规则（例如CPU超过90%报警），并基于events触发通知，支持邮件、短信、微信等多种方式，逻辑严密且功能全面。在对比层面，作者将Zabbix与所在公司的内部

IT 累计浏览 1,921

Exadata：存储节点上所有监控指标与其监控概览

Kaya 在 os2ora.com 上分享了这篇关于 Exadata 存储节点监控的深度指南。文章系统性地梳理了存储服务器上所有关键监控指标，从磁盘 I/O、网络吞吐到内存与 CPU 利用率，每一个指标都对应着系统健康状态的特定维度。作者没有停留在罗列指标的层面，而是深入讲解了如何将这些分散的指标整合成一个清晰的监控概览。文章特别强调了不同指标在性能分析中的关联性，例如如何通过结合等待事件与资源消耗数据来定位瓶颈。对于 DBA 和运维人员来说，这相当于提供了一套完整的“仪表盘解读手册”，帮助他们在日常巡检或故障排查时，能快速抓住重点，理解系统负载背后的含义。这篇指南的价值在于其极强的实用性，它将枯燥的监控列表转化为一套可操作的监控逻辑，让读者能更有效地利用 Exadata 平台自带的丰富遥测数据来保障数据库环境的稳定与高效。

IT 累计浏览 1,881

关于memcacheq的几个命令

这篇讲的是三个非常实用的MemcacheQ运维监控命令，作者从日常运维需求出发，直接分享了能快速掌握队列核心状态的Shell指令。第一个命令用于查看指定队列的**阻塞情况**。它通过周期性查询stats队列，并计算出待处理条目数（总数减去已处理数），让你实时看到是否有消息积压。第二个和第三个命令则分别关注队列的**写入速率**和**消费速率**。它们同样通过轮询获取队列总条目数，但核心是通过awk脚本计算相邻两次查询之间的数值差，从而直观反映出单位时间内的新增消息量和被消费的消息量。这三个命令结构简洁，都采用了“循环+网络查询+文本处理”的组合，作者巧妙地将监控逻辑嵌入到一行命令中。对于使用MemcacheQ作为消息队列的开发者和运维人员来说，这套命令提供了无需额外工具就能快速诊断队列健康状况、排查生产问题的直接手段。

IT 累计浏览 4,221

storm集群的监控

这篇讲的是如何为大数据处理框架Storm搭建一套实用的监控体系。作者从生产环境中Storm集群运维的痛点出发——缺乏可视化指标导致排障困难、性能瓶颈难以定位。核心方案是构建一个结合了Telegraf、InfluxDB和Grafana的监控栈，分别负责指标采集、存储和展示。文章具体拆解了实现步骤：利用Telegraf插件收集JVM、Topology吞吐量、Spout/Bolt延迟等关键运行时数据；通过InfluxDB进行高效存储和时间序列查询；最后在Grafana中搭建看板，将拓扑级别的数据、节点状态和历史趋势直观呈现。其中还介绍了如何设置合理的告警阈值，以便在任务积压或资源紧张时快速触发通知。最终效果是，团队拥有了对集群健康度的全景视图，故障定位时间显著缩短，也能基于历史数据更好地进行容量规划和性能调优。整个方案偏重轻量与实用，对已采用或考虑使用Storm的团队有直接的参考价值。

IT 累计浏览 2,540

环境为王-论贴吧环境解决方案

这篇讲的是贴吧团队为应对内容生态治理难题所设计的一套综合解决方案。面对早期贴吧“水军”刷屏、广告泛滥、优质内容被淹没的困境，作者详细拆解了其技术治理思路。核心在于构建了一个动态、智能的“环境”系统，而非简单的关键词屏蔽。方案的关键在于多层次策略：首先是实时内容过滤与识别系统，针对恶意行为进行快速拦截；其次是建立用户信用体系，对行为异常账号进行降权与限制；更为巧妙的是引入了内容权重算法，主动识别并扶持高质量原创帖与讨论，让“好内容”能自然浮现。从实践来看，这套系统上线后，平台违规内容处理效率得到了显著提升，同时用户举报率呈现下降趋势，原创内容的占比有了可观的增长。作者通过具体数据和案例表明，解决社区环境问题不能只靠“堵”，更需要一套系统性的“疏导”与激励机制，最终实现流量与内容质量的平衡。这为同类内容平台的治理提供了一个颇具参考价值的技术样板。

IT 累计浏览 4,161

小心grep 的buffer

这篇文章分享了一个作者在Linux管道命令中遇到的典型坑：在实时监控MySQL查询次数时，一个由`mysql`、`grep`和`awk`组成的管道命令输出延迟严重。作者起初怀疑是`awk`的缓冲问题，但调整无效。通过`strace`追踪，他发现根源竟在`grep`。`grep`读取了数据，但默认是“行缓冲”还是“全缓冲”呢？文章的妙处就在这里。当管道下游是慢速设备或程序时，`grep`为了提高效率，会积累多行数据后才一次性输出。这导致`awk`长时间收不到输入，屏幕上自然一片空白。解决方法出奇地简单：在`grep`命令后加上`--line-buffered`选项，强制它每匹配一行就立刻输出。问题随之迎刃而解。这个案例生动地说明了，管道中每个工具的缓冲行为都可能成为性能陷阱，而`grep`的`--line-buffered`正是为解决这类实时处理需求而生的关键选项。

IT 累计浏览 2,560

开发效率与系统稳定性杂谈

这篇谈的是互联网开发中一对经典矛盾：效率与稳定。作者从团队执行力和产品后防线这两个角度切入，指出开发效率决定了产品能否快速响应市场竞争，而系统稳定性——涵盖安全、性能等维度——则是产品一旦上线后不可逾越的底线。文章并没有给出某个具体技术问题的答案，而是聚焦于理念层面：衡量一个互联网系统的开发成熟度，最终就看这两个指标能否达到平衡。作者进一步点明，片面追求速度而忽视稳定性，可能会给产品带来不可逆的伤害；反之，过度谨慎又会错失市场良机。这种“既要…又要…”的张力，正是技术负责人每天面对的真实挑战。对于一线开发者或团队管理者而言，这篇文章的价值在于它清晰地框定了一个思考框架，帮助我们在日常开发中更有意识地权衡短期交付与长期健康。

IT 累计浏览 3,300

Erlang虚拟机内存使用问题以及监控

这篇讲的是 Erlang 平台在实际运维中一个常见但容易被忽视的陷阱：内存使用过量导致的虚拟机崩溃。作者从“N个9”高稳定性宣称与线上真实 Crash 的落差切入，指出许多 Erlang VM 相关的崩溃，根源都指向内存问题。文章揭示了 Erlang 内存管理的核心机制：采用一种“集中批发，零售分配”的模式。VM 作为总仓，一次性从操作系统获取大块内存，再按需分配给用户进程、ETS 表等各个消费单元。这种设计的精妙之处在于高效，但也埋下了隐患——内存的增长曲线并非线性，而是近似斐波那契数列的方式攀升。作者特别警告，当内存消耗达到 GB 级别后，后续的分配速度会陡然加快，远超预期，很容易在短时间内耗尽资源。因此，对于使用 Erlang 构建高可用服务的团队而言，建立精细的内存监控体系至关重要。这篇内容提醒我们，不能只信赖语言本身的稳定性神话，而必须深入理解其资源管理特性，主动监控并预防内存的“雪崩式”增长。

IT 累计浏览 2,063

用syslog-ng实时收集每一行php报错

这篇讲的是一个电商创业团队如何用 syslog-ng 实时捕获 PHP 报错，来提升服务可用率。作者从电商服务不能中断、需要快速发现问题的现实需求出发，决定不再依赖人工查日志，而是要把每一行 PHP 报错都集中收集起来。具体方案是用 syslog-ng 这个高性能的日志管理工具，它像一个灵敏的哨兵，可以实时监听 PHP 产生的错误日志，并把它们统一汇总。这样做的好处是，报错信息能被即时看到和分析，而不是散落在各个服务器的角落里。对于争分夺秒的线上故障排查来说，这种实时性非常关键。最终，他们通过这样的架构实现了错误的快速发现和响应，为服务稳定性提供了坚实的基础。文章分享的这个从需求到落地的完整路径，对于同样追求高可用的中小团队来说，提供了一个清晰、可实施的参考范例。

IT 累计浏览 3,262

一个监测服务器swap并重启php的脚本

这篇讲的是如何用一个轻量脚本解决服务器因swap耗尽而无响应的棘手问题。作者的实际困扰是，一台服务器上运行着一个历史遗留的、效率低下的PHP扩展，它不断吞噬内存导致swap扇区被占满，进而引发服务中断。由于暂时无法替换该扩展，作者采取了务实的“止血”方案：编写一个监控脚本，通过`crontab`每两小时执行一次，自动检测swap使用情况。一旦发现异常，脚本会尝试重启`php5-fpm`服务（只需替换文中对应命令即可），从而释放内存、恢复系统响应。这个方案的核心在于，它巧妙地在应用层（PHP扩展）无法根治的情况下，于系统层找到了一个自动化的、及时的恢复机制，让服务器重获平静，也终结了恼人的报警短信。对于同样受困于类似问题且需要临时缓解方案的运维人员，这个思路提供了一个直接可用的实践参考。

IT 累计浏览 4,740

Facebook是如何开发软件的

这篇讲的是 Facebook 内部独特的软件开发文化与实践。作者从一个技术翻译者的视角，深入剖析了这家社交巨头如何“交付代码”。文章的核心观点在于，Facebook 的高效并非偶然，而是建立在一套鼓励大胆尝试、快速迭代并严控质量的系统性实践之上。文章详细介绍了几个关键环节：比如强制性的代码审查，不仅是为了找 bug，更是为了知识共享和质量文化；又如极度强调自动化测试和持续集成，确保每一次提交都不会拖垮整个系统。更特别的是，Facebook 将新功能首先以极小比例向内部员工开放（“吃自己的狗粮”），然后才逐步灰度发布到所有用户。这种“快速、粗犷、开放”的迭代哲学，与许多公司追求前期完美设计的路径形成了鲜明对比。其背后的核心，是一种“解决问题的勇气”被置于“避免犯错”之上的工程文化。这套看似激进的方法，建立在强大的基础设施和即时的监控反馈之上，从而实现了速度与稳定性的平衡。对于其他技术团队而言，其中关于文化塑造和工具链建设的洞察，比具体的技术选型更值得思考。

IT 累计浏览 5,102

通过『iostat -dx 1』命令监控IO性能

这篇讲的是如何用「iostat -dx 1」命令快速定位网站IO性能瓶颈。作者开篇点明，很多让人头疼的性能问题——比如响应变慢、请求堆积——其根源往往不在CPU或内存，而藏在磁盘IO里。文章没有停留在罗列命令参数，而是手把手带你读懂输出中的关键指标。比如，重点关注%util（磁盘利用率）和await（平均IO等待时间），能帮你立刻判断磁盘是否已经“忙不过来”。作者通过实际场景说明，当%util持续接近100%且await很高时，大概率就是IO瓶颈在作祟，这时再去优化代码或增加缓存才有的放矢。更重要的是，文中分享了实战经验：单纯看iostat的输出还不够，要结合业务时序（比如在流量高峰期观察）和不同磁盘（如SSD与HDD）的特性来综合判断。这让一个基础的监控命令，变成了能直接指导优化行动的诊断工具。

IT 累计浏览 8,001

查看 CPU, Memory, I/O and NetFlow

这篇讲的是如何用命令行工具快速掌握系统的核心性能指标。文章从运维工程师最关心的几个维度切入：CPU负载、内存使用、磁盘I/O以及网络流量。作者直接演示了如何使用 `iostat -d -x` 命令获取磁盘的扩展设备统计信息，输出中包含了每秒读写次数、吞吐量、平均队列长度等关键数据，能直观判断是否存在I/O瓶颈。同样，文章也涵盖了使用 `vmstat` 或 `free` 分析内存情况、利用 `top` 或 `mpstat` 查看CPU使用率细节，以及通过 `iftop` 或 `nethogs` 监控实时网络流量的方法。对于排查性能问题的工程师来说，这些工具是诊断的第一手信息来源。文章的价值在于将分散的命令串联起来，形成一个基础但实用的性能分析工具箱，帮助读者从不同角度“看见”系统负载的真实面貌，从而定位问题的潜在源头。

IT 累计浏览 14,764

批量添加主机到cacti+nagios的监控报警系统中

这篇讲的是作者团队从 cacti+nagios 向 zabbix 迁移的决策过程与思考。文章从一个实际运维场景出发：他们长期使用 cacti+nagios 组合来构建监控报警系统。在实践中，他们认识到监控系统的核心价值远不止故障发现，更能为各类项目提供基础数据，是“ALL IN ONE”的运维中枢。然而，随着监控的主机与应用项不断增加，这套经典组合的性能瓶颈日益凸显。具体表现为：指定时间内扫描率下降，导致 cacti 出现超时断图，历史数据不完整；nagios 的报警则被延迟甚至漏发，严重影响了故障响应的及时性。在经历了这些问题后，团队决定重新选型。文章分享了他们进行综合比较后得出的关键结论：将未来的主要精力投入到 zabbix 的研究和应用上，以应对大规模监控场景下的性能挑战。这为面临类似问题的团队提供了一个清晰的演进方向参考。

IT 累计浏览 1,820

DBA手记:Failed Login Count带来的性能问题

这篇讲的是《Oracle DBA手记II》中一个真实踩坑案例：一个看似无害的数据库参数 `Failed Login Count`，在高并发登录场景下，竟然导致了性能显著下降。作者从一个生产环境性能突降的排查出发，锁定了异常的数据库等待事件。追踪发现，罪魁祸首是用于记录登录失败次数的统计功能。每当有用户（尤其是程序客户端）因密码错误等原因登录失败时，Oracle 会频繁更新这个统计信息，产生了大量行级锁竞争。在批量、并发的连接尝试下，这成了严重的性能瓶颈。文章详细剖析了该问题的触发条件与根因，并给出了具体的解决方案——通过调整 `SEC_CASE_SENSITIVE_LOGON` 等参数或在特定时段调整统计策略，从而规避锁争用。这个案例生动地提醒 DBA 们，一些默认开启的、用于审计与监控的功能，在特定业务模式下可能悄然变为性能负担，需要结合实际负载仔细权衡其开关与粒度。