Categraf Linux 主机监控实战：配置、指标和大盘
本文介绍如何使用 Categraf 采集 Linux 主机基础监控指标，包括 CPU、内存、磁盘、磁盘 IO、网络、系统负载和进程数，并导入夜莺或 Grafana Dashboard 完成主机监控闭环。
Flashcat 博客
围绕可观测性、AI SRE、告警治理、On-call、Nightingale、Categraf、Prometheus、Kubernetes、Zabbix、用户案例和产品更新，沉淀一线工程实践、选型参考和稳定性治理方法。
精选内容
最新文章
Categraf 是什么：一篇文章讲清楚它适合什么场景
Categraf 是一款开源的 All-in-One 监控数据采集器，支持主机、中间件、数据库、Kubernetes、网络设备等多种监控对象，兼容 Prometheus 生态，并提供夜莺和 Grafana Dashboard。
LogicMonitor Edwin AI：传统 IT 运维里的 AI SRE 应该怎么落地
本文基于 LogicMonitor Edwin AI 的公开产品能力，拆解传统企业 IT 场景下 AI SRE 如何围绕告警降噪、事件关联、日志证据、变更单、历史事故、知识库、受控自动化和权限边界落地。
MTTR 降不下来，真的是工具问题吗？
MTTR 降不下来，不能只归因于工具。更有效的做法是把故障响应拆成发现、分派、定位、修复、验证和复盘，逐段找到拖慢恢复的真正原因。
为什么监控越来越多，故障定位反而越来越慢？
监控工具和告警越来越多，故障定位却越来越慢。根因通常不是监控不够，而是告警、指标、日志、变更、拓扑、业务影响和响应流程没有统一到同一个稳定性工作台。
连锁门店 IT 稳定性自查表：总部真的看得见每家门店吗？
一份面向连锁零售总部 IT、数字化和运维团队的门店稳定性自查表，帮助识别总部可见性、业务链路监控、告警响应和复盘治理盲区。
连锁企业门店健康度指标参考表：从设备在线到业务可用
从网络、设备、应用、业务和响应五层拆解连锁企业门店健康度指标，说明健康度分数如何服务门店稳定性治理，而不是停留在大屏展示。
门店故障发现与响应复盘模板：一次故障，应该追问什么？
面向连锁门店故障的复盘模板，围绕发现、影响、响应、根因和改进项追问，帮助团队把一次故障转成更早发现、更快响应和可验收改进。
为什么有 Zabbix，门店故障还是靠人反馈？
面向已有 Zabbix 的连锁企业，分析门店故障仍靠人工反馈的五类原因：监控对象与业务对象脱节、指标远离顾客体验、告警疲劳、响应流程缺失和多系统上下文不足，并给出保留 Zabbix、补齐业务链路和告警治理的升级框架。
总部如何先于门店发现故障：9 类早期信号
梳理连锁零售总部先于门店发现故障的 9 类早期信号，包括网络质量、设备状态、接口延迟、交易量、支付失败率和告警风暴。
便利店/商超总部如何先于门店发现故障
便利店、商超等门店型企业的 IT 故障往往直接影响收银、支付、库存和顾客体验。本文讨论总部如何通过统一可观测和告警响应机制，在门店反馈之前发现并处理故障。
Zabbix 门店监控如何平滑升级到统一可观测
面向已有 Zabbix 的连锁门店监控体系，给出平滑升级到统一可观测的方法：先统一告警入口，再补齐应用和业务可观测，最后扩展 Categraf、Nightingale、Flashcat 和 Flashduty 的采集、告警治理与门店健康视图。
每天几千条告警，如何收敛成有效故障
连锁门店环境下，告警数量很容易失控。本文讨论如何通过告警分级、降噪、关联、路由和复盘，把告警从消息轰炸收敛成真正可响应的故障事件。
门店 IT 健康度怎么建：从经验运维到量化治理
连锁门店 IT 系统复杂、分散、故障影响直接。本文讨论如何用统一监控、健康度模型和告警响应机制，把门店运维从靠经验救火推进到可量化治理。
AI SRE 不应该是聊天机器人，而应该是带工具的调查员
AI SRE 的价值不是生成通用建议，而是带着 Incident 上下文调用指标、日志、Trace、事件、runbook 和知识库，输出有证据、有边界、可审计的故障调查结论。
AI 根因分析为什么经常不准：缺的不是模型，而是上下文
AI RCA 要可靠，关键不是只换更强模型，而是把拓扑、服务目录、指标、日志、Trace、变更事件、runbook 和响应上下文组织成可调查证据链。
故障复盘报告怎么写：AI 可以生成初稿，但不能替你承担改进责任
说明故障复盘报告的正确写法：AI 可以整理时间线、告警上下文、战情室讨论和初稿，但根因确认、影响判断、行动项承诺和验收责任必须由团队承担。
OpenTelemetry 解决了数据标准，但没有自动解决排障路径
OpenTelemetry 让指标、日志和链路具备统一上下文，但要真正降低 MTTR，还需要对象模型、下钻规则、事件上下文和责任边界。
事件墙为什么重要：根因定位经常不是查指标，而是找到“刚才变了什么”
事件墙把发布、配置、运行时、告警和运营事件放回同一时间窗口，帮助团队从指标异常快速追到变化证据。
为什么全栈可观测已经建设了，故障时还是不知道先看哪里
全栈可观测不等于排障路径清晰。真正有价值的平台要把入口、对象、上下文和下钻路径组织起来，减少事故现场翻页面和手工拼线索。
