夜莺 v7 最终版来了,可以上车了
夜莺 v7.7 是 v7 系列的最后一个版本,保守主义者可以上车了,v7.7 主要是做了一些小修小改,增强了使用体验,下周开始,启动 v8 版本的开发
汇总 Flashcat 博客中归属于 夜莺 分类的文章,方便按内容类型连续阅读产品实践、客户案例和可观测性方法。
夜莺 v7.7 是 v7 系列的最后一个版本,保守主义者可以上车了,v7.7 主要是做了一些小修小改,增强了使用体验,下周开始,启动 v8 版本的开发
夜莺 v7.5 发版,优化了一波小功能。首先是告警规则页面的优化,其次是仪表盘的跳转链接的优化。再有一两个小版本,v7 就差不多了,后面的大功能会放到 v8 版本,敬请期待
Nightingale 和 Flashcat 是两个不同的监控系统,本文将介绍它们的区别。简单来讲 Nightingale 是一款开源监控系统,Flashcat 是 Nightingale 的商业版本,主导这两个项目的是一波人
在技术领域,特别是云原生监控领域,夜莺(Nightingale)监控系统以强大的功能逐渐崭露头角。作为一款国产、开源的云原生监控分析系统,夜莺自诞生以来便受到了广泛的关注和应用。本文将详细探讨夜莺监控系统的起源、发展、功能特点、系统架构以及其在企业中的应用。
夜莺监控(Nightingale)应该算是国产监控当中 star 数量最高的开源项目了,目前已经 9000 多,如果你是从事运维、运维开发、基础设施相关的工作,可以了解看看
夜莺 v7.2.1 发版,告警详情页面支持查看告警事件通知记录
经过一年的迭代,夜莺 v7 于 2024.7.26 在第二届 CCF·夜莺 开发者创新论坛上正式发版
告警事件中一大堆标签不胜其扰?尤其是 Kubernetes 的告警事件,夜莺 v7.beta14 发版,支持灵活定义告警事件标签,用最简单的方式干掉没用的标签
夜莺 v7.beta13 发版,继续优化细节,主要变更是提供日志的 KQL 查询模式、Prometheus 类型的数据源在即时查询时提供历史查询记录功能、记录规则提供 CRON 方式控制执行频率,可以借此指定固定时刻执行
夜莺擅长处理多 Prometheus 集群的告警管理,在仪表盘这块,提供了一些内置仪表盘,但从完善度来讲,是没法和 Grafana 生态相比的,从 v7.beta12.1 版本开始,夜莺支持了内置 Grafana 仪表盘,省得大家在系统之间跳来跳去了,对于已经习惯使用 Grafana 的用户,可以考虑升级到此版本
夜莺之前的版本也支持钉钉、企微、飞书通知,不过整体逻辑设计的比较绕,这个版本提供了一个更直观的配置方式,顺带优化了 at 人的功能
这个版本建立了集成中心的框架,并且修复了边缘机房机器失联告警的Bug,建议升级
Prometheus 生态的原生做法,由于阈值是放在 promql 中的,恢复时的消息中难以拿到恢复时的值,夜莺 v7.0.0.beta10 版本开始,提供了一种较为简单的内置方式,解决这个问题
介绍 GPU 服务器与 InfiniBand 的监控方案,对比 nvidia-smi 和 DCGM,并演示如何结合 Categraf 与 Exporter 接入夜莺。
仪表盘中的变量获取来源通常来自时序库,如果要查看机器相关的仪表盘数据,并做到方便的筛选,需要机器相关的指标提前打上各类标签,这个版本开始,仪表盘变量提供了一个新的筛选方式,可以和仪表盘所在业务组联动,自动获取业务组下的机器了
Prometheus 生态里如果要查询数据,需要编写 promql,对于普通用户来说,门槛有点高。通常有两种解法,一个是通过 AI 的手段做翻译,你用大白话跟 AI 提出你的诉求,让 AI 帮你写 promql,另一种是平台里内置现成的 promql,覆盖常用场景开箱即用。夜莺监控(Nightingale)最近上线了内置指标功能,即采用方案二,效果很棒值得尝试。
Prometheus 和 Nightingale 都被看做是监控系统,这俩是什么关系?相互替代还是相互协同?
虽说监控系统最侧重的功能是指标采集、存储、分析、告警,为了能够快速恢复故障,告警自愈机制也是需要重点投入建设的,所有可以固化为脚本的应急预案都可以使用告警自愈机制来快速驱动
夜莺监控 V5 和 V6 版本都支持故障自愈功能,但是均需要单独部署 ibex 模块,从 V7 beta2 版本开始,夜莺内置集成了 ibex 模块,无需单独部署 ibex,大大简化了部署流程。
熟悉夜莺的小伙伴都知道夜莺分为开源版、专业版、企业版,三个版本良性发展。近期夜莺团队发布了 v6.7 版本,把机器Metadata管理功能推送到了开源版。