夜莺的机器支持挂载到多个业务组了
夜莺 v7.4.1 发布:机器支持绑定多个业务组,左侧业务组 UI 重新设计,机器标签拆分为机器标签和用户标签,并支持通过 iframe 导入 Grafana 仪表盘链接。
围绕可观测性、AI SRE、告警治理、On-call、Nightingale、Categraf、Prometheus、Kubernetes、Zabbix、用户案例和产品更新,沉淀一线工程实践、选型参考和稳定性治理方法。
夜莺 v7.4.1 发布:机器支持绑定多个业务组,左侧业务组 UI 重新设计,机器标签拆分为机器标签和用户标签,并支持通过 iframe 导入 Grafana 仪表盘链接。
解释运维监控系统的定义、核心功能、实际应用、建设挑战,以及 Flashcat 在指标、日志、链路追踪、告警和可视化方面的支持。
本文演示如何在 CentOS 8.2 上开启 Apache httpd stub status,并使用 Categraf apache 插件采集 CPU、Worker、连接数等 Apache Web Server 监控指标。
在服务器运维领域,Oncall工程师是系统稳定运行的重要守护者,他们负责在系统出现问题时第一时间介入,确保服务的可靠性和可用性。
On-Call 是企业为快速响应生产故障或重大事件而建立的值班待命机制,通常结合监控告警、排班策略、通知渠道、事件记录和升级机制,保障服务稳定性和业务连续性。
介绍夜莺 Nightingale 监控系统的定义、发展历程、功能特点、架构组件、部署方案和典型应用场景。
夜莺 v7.3.2 起告警事件支持 Target 字段,通知模板可以展示机器名、CPU 使用率、内存使用率、IP、采集器版本等机器信息,帮助值班人员更快定位告警对象。
解释 ibex 告警自愈任务 stdout、stderr 上报时为什么会被截断,说明 meta 目录与上报结果不一致的原因,并给出使用建议。
本文是 VictoriaMetrics 公司创始人所著,探讨了开源时序库的兴起历史、值得关注的项目以及未来的发展方向。时序库是监控、可观测性领域的基础设施,如果您是基础设施方向的工程师,尤其值得关注。
本文整理 Datadog 高效监控系列中的故障调查方法:从最高层工作指标开始,逐层检查资源指标和事件,并用预先设计的仪表盘加快性能问题定位。
本文整理 Datadog 高效监控系列中的告警方法:如何区分 record、notification、page,为什么应优先针对用户可感知的症状告警,而不是针对内部原因制造告警噪声。
本文整理 Datadog 高效监控系列中的数据采集框架:如何区分工作指标、资源指标和事件,为什么应尽可能收集有用数据,并把数据用于告警和故障诊断。
企业常有多套监控系统,告警事件分散、降噪困难、排班和升级缺失。Flashduty 作为一站式告警 OnCall 平台,统一处理告警集成、标签增强、聚合降噪、分派升级、协同通知和统计分析。
告警降噪通过聚合、抑制、静默、收敛和标签增强等策略减少重复通知和无效打扰。本文结合 Flashduty 实践说明告警风暴、告警抑制、预期内告警的处理方式和降噪效果。
益丰大药房监控升级案例:从 Zabbix、多套 Prometheus、云监控和脚本分散建设,演进到夜莺统一监控与 Flashduty 告警响应,并规划全局驾驶舱和下钻分析。
夜莺数据源离线不能只依赖该数据源自身告警。本文介绍用 Categraf http_response、Telegraf 或 blackbox_exporter 做跨数据源探测,并用 PromQL 及时发现 Prometheus 等数据源不可用。
市面上已经有很多开源、商业的可观测性类产品,比如 Zabbix、Prometheus、Nightingale、SigNoz、SkyWalking、ELK 等等,而且各类云厂商也会提供自己的可观测性套件,有些规划混乱的云厂商甚至会提供功能重叠的多套产品,这加剧了企业数据孤岛的现状。怎么解?
海大集团在 600+ 分子公司、容器/K8s、物理机、虚拟机、公有云和多套监控工具并存的环境下,建设统一可观测平台。本文梳理其从需求挑战、Flashcat 方案选择到北极星、灭火图、多维分析和统一告警落地的实践路径。
Prometheus 告警恢复事件中的 `$value` 往往仍是最后一次告警触发值,而不是恢复时的最新值。原因在于 Prometheus 规则表达式带阈值时正常状态不返回数据,Alertmanager 生成 Resolved 事件时也不会反查 Prometheus。本文解释原理和两类解决方式。
告警集成、标签增强、聚合降噪、告警抑制、值班排班、认领升级转派、系统、通知、数据统计