Categraf TCP/UDP 网络探测实战：端口连通性、响应时间和告警
本文介绍如何使用 Categraf net_response 插件做 TCP/UDP 网络探测，包括端口连通性、响应匹配、结果码、响应时间、Dashboard 和告警建议。
Flashcat 博客
围绕可观测性、AI SRE、告警治理、On-call、Nightingale、Categraf、Prometheus、Kubernetes、Zabbix、用户案例和产品更新，沉淀一线工程实践、选型参考和稳定性治理方法。
精选内容
最新文章
连锁零售总部如何在门店上报前发现门店故障
连锁零售总部要提前发现门店故障，不能只看服务器和网络是否在线。本文介绍如何把门店、区域、支付通道、POS、会员、库存、订单和云服务建模为可观测业务对象，并用 Flashcat 与 Flashduty 做统一视图、告警归并和事件响应。
制造业 IT/OT 可观测性：从工厂网络和 MES 到云原生应用
制造业可靠性已经是 IT/OT 共同问题。本文介绍如何把工厂网络、MES、数据库、云原生应用、告警响应和 AI SRE 连接成可观测对象模型，从关键产线试点开始提升故障诊断和响应效率。
Categraf Grafana Dashboard 使用指南
本文介绍如何使用 Categraf 仓库中的 Grafana Dashboard，包括 Dashboard 文件选择、数据源配置、变量选择、导入验证和常见无数据问题排查。
Categraf MySQL 监控实战：配置、指标、大盘和告警
本文介绍如何使用 Categraf 采集 MySQL 指标，包括账号权限、实例配置、核心指标、Grafana Dashboard、告警规则和常见问题排查。
Categraf Redis 监控实战：配置、指标、大盘和告警
本文介绍如何使用 Categraf 采集 Redis 指标，包括实例配置、INFO 指标、慢查询、自定义命令、Grafana Dashboard、告警规则和常见问题排查。
Flashcat 和开源夜莺有什么区别？
Flashcat 继承开源夜莺的告警治理和指标可观测地基，在数据、平台、场景和智能四层继续增强，帮助企业从有数据、有告警走向业务健康感知、故障定位、故障修复和 AI 驱动运维。
10 分钟跑起 Categraf + 夜莺 + VictoriaMetrics
本文介绍如何使用 Docker Compose 快速启动 Categraf、夜莺和 VictoriaMetrics，完成从主机指标采集、remote write 写入、PromQL 查询到 Dashboard 展示的最小监控闭环。
Categraf Linux 主机监控实战：配置、指标和大盘
本文介绍如何使用 Categraf 采集 Linux 主机基础监控指标，包括 CPU、内存、磁盘、磁盘 IO、网络、系统负载和进程数，并导入夜莺或 Grafana Dashboard 完成主机监控闭环。
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 的采集、告警治理与门店健康视图。
