前言 对于数据库、中间件的监控，目前社区里最为完善的就是Prometheus生态的各个Exporter，不过这些Exporter比较分散，不好管理，如果有很多目标实例需要监控，就要部署很多个Exporter，要是能有一个大一统的Exporter，具备所有这些Exporter的能力就好了。还真有，而且还不止一个，一个是 Grafana-agent，一个是 Cprobe，Grafana-agent整合这些Exporter相对比较生硬而且缺少了目标实例自动发现机制，好处是Grafana-agent不止是整合了常见的Exporter，还整合了Promtail和OTELCollect...

夜莺社区的朋友如果问时序库的选型，我一般都会推荐VictoriaMetrics，除了其性能、稳定性、集群扩展能力之外，VictoriaMetrics还扩展了PromQL，提供了MetricsQL，即增强了PromQL的能力。比如下面介绍的场景，就很适合用MetricsQL来解决。 需求 某个指标（假设指标名字是interface_status）每分钟上报一次，如果5分钟内有3次大于x的值，就报警。 解法 如果使用PromQL，就比较难写了，而MetricsQL就很简单，如下： count_gt_over_time(interface_status[5m],x)>=3 看到这个写法，基...

一背景 商业客户反馈用categraf的net_response插件配置了udp探测,遇到报错了，如图  udp是无连接的，无法用建立连接的形式判断端口。插件最初的设计是需要配置udp的发送字符，并且配置期望返回的字符串， [[instances]] targets=[ "127.0.0.1:161", ] protocol="udp" stringsenttotheserver send="hello" expectedstringinanswer expect="hello" 通过返回字符与期望字符是否相等，来判断端口是否连通。用户随即发了另一张图，用ncat来探测端口是...

在夜莺新版本中，告警规则直接使用promql来配置，阈值就包含在promql里面，所以恢复时是无法拿到当前值的，因为恢复时监控数据不达阈值，不达阈值就不会返回数据，所以也就无法拿到当前值。Prometheus也是类似的问题，不过可以通过gotemplate中的query函数曲线救国，但是不够直观，学习曲线较高。今天给大家介绍两种实现思路来解决这个问题。 思路一：查询的promql中不包含阈值，只包含过滤条件，直接去查询原始数据，告警引擎查到原始数据之后做阈值判定，不管是否触发阈值，都可以拿到当前值。 思路二：查询的promql中包含阈值，恢复时拿着相关标签去做二次查询，这样也可以拿到当前...

笔者去年在极客时间发布了一个专栏《运维监控系统实战笔记》，很多朋友借此梳理了较为体系化的运维监控系统知识，但是限于专栏篇幅，有些手把手实操类的内容没有办法展开，另外时隔一年，监控系统的技术栈也有了一些变化，所以笔者决定在这里把这些内容补充完整。 监控系统的典型架构 对于一些前置背景知识、名词解释、行业黑话，请大家自行阅读之前的专栏，这里不再赘述。这个新的专栏更多是偏向实操，不过在开始之前，还是要先回顾一下监控系统的典型架构，如下图： 对于上图中的每个模块，都有开源和商业的解决方案，具体如何选型，可以参考之前的专栏，在当下时点，2024.1.1，笔者的建议是： 采集器：如果仅限于开源，那...

熟悉夜莺的小伙伴都知道夜莺分为开源版、专业版、企业版，三个版本良性发展。近期夜莺团队发布了v6.7版本，把机器Metadata管理功能推送到了开源版，下面是该功能的简单介绍。 如上图，机器列表页面的机器标识部分，加了超链接支持点击，点击之后会弹出一个侧拉板，展示机器的metadata信息，如下图： 比如机器的Kernel信息、CPU型号、机器的IP地址、Mac地址等等，如果机器有多块网卡，每一块的信息都会被采集展示。这个功能一定程度上可以提供部分CMDB的能力，而且，因为是通过 Categraf（v0.3.42以上版本）自动采集的数据，所以数据是准实时的、准确的，不需要人工维护，...

通过深入分析和解决企业在可观测性和稳定性保障方面的挑战，Flashcat提出了“灭火图”这一关键概念。 灭火图以服务/模块/基础组件/基础设施等为维度，以聚合的视角实时度量某个特定维度的可用性（典型指标包括时延、流量、错误、饱和度），并为该可用性指标自动设定合理的阈值，可以回溯历史上的指定时间点的可用性状态（典型的跨度为24小时）。 灭火图是发现服务健康与否的入口，也是整个故障定位信息系统的核心，从灭火图开始，可以下钻到具体的接口/基础设施/链路分析数据/问题特征/相关事件等关键维度，引导技术团队高效、精准的定位故障。 今天详细为大家介绍服务故障定位的入口工具：Flashcat-灭火图...

在GoogleSRE的著作《Google运维解密》(原作名：SiteReliabilityEngineering:HowGoogleRunsProductionSystems)中，GoogleSRE的关键成员们几乎不惜用了三个章节的篇幅描述了在Google他们是如何OnCall的。 GoogleSRE实践中，有一个广为人知的理念：减少琐事，用软件工程的方式解决运维问题。具体到实际操作层面，GoogleSRE设定了一个重要的、公开的目标：保持每个SRE的工作时间中琐事比例低于50%，SRE至少花50%的时间在工程项目上，以减少未来的琐事或为服务增加新功能。 GoogleSRE团队认为，琐事过多，...

Oracle数据库在行业内应用广泛，通常存放的非常重要的数据，监控是必不可少的，本文使用Cprobe采集Oracle监控数据，极致简单，分享给大家。 安装配置Oracle 简单起见，我使用Docker启动Oracle，命令如下： dockerrun-d--nameoracle-p1022:22-p18080:8080-p1521:1521wnameless/oracle-xe-11g-r2 如上命令启动之后，Oracle的监听端口是1521，用户名/密码是system/oracle，数据库SID是xe，要监控Oracle，首先得有账号连上去执行SQL，所以这些连接信息得记住喽，待会要用...

FlashDuty：一站式告警响应平台，前往此地址免费体验！ 值班管理 UI交互优化 【个人日程】从头像下拉菜单调整到值班列表页面，快速查看个人值班日程 【值班列表】支持原地预览最近一周值班情况，包括当前和下一阶段值班人 【值班详情】支持日历模式与时间线模式切换，查看月度计划更方便 【规则调整】支持直接点击日历进行规则编辑或调班，提升调班效率 【规则添加】批量选人自动分组，可拖动调整人员顺序 轮换能力增强 【轮换周期】：从 每天/每周 扩展为 N小时/N天/N周/N月，轮换起止时间从 半小时 精度提升到 分钟 ...

什么是可观测性？ 可观测性（Observability）是一种软件开发和系统构建的哲学，是对系统内部状态及行为的度量和推断能力，通常包括日志、指标、链路追踪等多个度量维度。也就是说，在软件开发和运维领域中，可观测性是指对于一个复杂的系统，能够通过监控、日志、指标、追踪等手段，快速地发现、诊断、解决问题的能力。 Observability最早是起源于控制论的一个概念： In1960,Kálmánintroducedacharacterizationhecalledobservabilitytodescribemathematicalcontrolsystemsinhispaper.Incont...

需求背景 监控数据采集领域，比如Prometheus生态有非常多的Exporter，虽然生态繁荣，但是无法达到开箱即用的大一统体验，Exporter体系的核心问题有： 良莠不齐：有的Exporter写的非常棒，有的则并不完善，有些监控类别甚至有多个Exporter，选择困难 写法各异：Exporter所用的日志库、配置文件管理方式、命令行传参方式各异，体验不一 倚重边车模式：有些Exporter和采集目标之间是一对一的关系，有几个采集目标就需要部署几个Exporter，在Kubernetes环境下相对容易管理，在物理机虚拟机环境下管理起来就比较复杂了，而且多个Exporter还会带来资源成本...

author：longzhuquan 背景 随着公司XC改造步伐的前进，越来越多的业务选择TiDB，由于各个业务之间需要物理隔离，避免不了的TiDB集群数量越来越多。虽然每套TiDB集群均有两个详细的监控Dashboard、Grafana，但对于运维来说几十套集群的监控、告警、巡检均需消耗巨大的精力。上篇介绍了监控工具的安装，以及业务组如何规范的设置。本章着重介绍如何将多套集群Grafana数据统一管理。 监控大盘介绍 在夜莺仪表盘-监控仪表盘界面，通过预先配置好想要查看的图表，用户在未来查看时只需点击即可直接浏览一系列图表，无需逐一选择。例如，在MySQL监控中，资深DBA可以事先将重...

Flashduty 作为功能完备的事件OnCall中心，可以接入云上、云下不同监控系统，统一做告警降噪分派、认领升级、排班协同，已经得到众多先进企业的认可。我们采访了一些典型客户代表，了解他们的痛点、选型考虑和未来展望，集成本系列文章，以飨读者。 本次有幸在邹老板支持下访谈到途游资深运维工程师高工，聊一下“途游游戏”在Flashduty的实践经验。另外，也欢迎大家下载途游的游戏放松一下，哈哈。 除了途游，莉莉丝、悠星等游戏用户也是Flashduty的用户，场景大抵是类似的，废话不多说，让我们一起来揭开游戏公司OnCall的面纱。 1.辛苦高工先简要介绍一下您所在的团队以及贵司...

Flashduty 作为功能完备的事件OnCall中心，可以接入云上、云下不同监控系统，统一做告警降噪分派、认领升级、排班协同，已经得到众多先进企业的认可。我们采访了一些典型客户代表，了解他们的痛点、选型考虑和未来展望，集成本系列文章，以飨读者。 本次采访的是来自益丰大药房的高级运维工程师张望。益丰大药房是一家连锁零售药房企业，有上万家门店，官网是https://www.yfdyf.com/，已于主板上市，股票代码：603939，颇具规模。 Question：张望老师您好，请问在选择Flashduty之前，贵司是如何做告警事件管理和触达的呢？ Answer：我们内部有多套不同的...

这是2017年的promcon的分享，原文地址在这里，作者JuliusVolz，今天偶然看到，虽然已经过去6年，有些实践经验还是非常值得学习。做个意译，加入一些自己的理解，分享给大家。 埋点方面 1.所有模块都要埋点 我印象中Google有个规范，所有的服务模块，都需要通过HTTP /varz 接口暴露监控指标，即便是一个纯后端的RPC服务，也要暴露一个这样的HTTP接口。当然，实操的话，应该是通过框架来统一埋点，但是统一埋点只能埋入一些通用的指标，如果涉及一些自身业务逻辑相关的，还是需要自行埋点。 2.借鉴USE方法论 USE方法论，即Utilization、Satura...

大家好，夜莺项目发布v6.5.0版本，启用新logo，菜单支持换肤，支持了暗黑版本的菜单，下一步会支持全站暗黑主题，敬请期待，下面是新logo。 暗黑菜单 页面右上角点击用户名，在下拉框里会有主题设置，可以选择暗黑主题菜单，效果如下： 监控大盘详情页面右上角也多了一个主题设置，可以选择dark模式，效果如下： 现在只是仪表盘支持这个模式，后面会让全站支持暗黑模式。另外，子菜单的呼出放到了下面，不是浮在右侧的方式，可以用更少的点击次数找到想要的菜单，个人非常喜欢这个交互调整，大家可以尝试一下。 团队和业务组支持多层级树 从v5正式版开始，取消了机器的树状管理，核心是因为在Prometh...

编者荐语： 真正搞监控的人肯定知道SNMP水有多深，有时我甚至腹黑猜测，这些厂商是故意的吧，，，指标不标准，格式各异，只能靠一款灵活的采集器了，本文是夜莺社区用户写的文章，转给大家参考。 author:网络小斐 关于夜莺SNMP插件 前文说明了利用夜莺开源版如何监控H3C交换机的，算是抛砖引玉；秉持着授人与鱼不如授人与渔，今天我们就来具体谈谈夜莺SNMP插件的使用，能自己自定义自身需求的监控指标才是真正学会如何利用夜莺去监控SNMP协议设备，今天将以H3C无线作为案例，具体讲解下SNMP插件配置。 场景介绍 企业华三无线AP和AC的设备信息监控，需要通过SNMP协议拿到指标数据，并把数...

笔者从14年开始做监控，从Open-Falcon到后来的Nightingale，到现在接近10年，认知在持续迭代，最近又有一些新想法，跟大家分享一下我眼中的理想的监控系统到底是什么样的。 关于采集器 市面上有众多采集器，比如telegraf、categraf、grafana-agent、datadog-agent以及Prometheus生态的各类Exporter，但没有一个是完美的。采集器的理想形态应该是做成两个进程组件，一个部署到所有OS上，以Daemonset方式来跑，采集机器上的OS指标、日志、eBPF等数据，因为这些数据必须要和操作系统、文件系统交互，所以一个部署到所有机器上的ag...

该知名火锅连锁企业是中国领先的餐饮企业，上千家门店遍布全球，由于门店餐饮行业的特殊性，需要靠前部署服务，所以在每家餐厅中，会部署相应的服务器，及相应IT设备，本地会运行POS、会员、下单等业务。公司有众多的餐厅门店，各个门店业务流量不同，门店的IT设备由于城市、开业时间等因素，其型号也不相同，服务器、应用程序分散式部署，给应用管理、IT运维、以及先于门店发现问题，带来了极大的挑战。 所以迫切需要一个针对连锁餐饮门店的监控解决方案，以便完善监控覆盖度，及时发现并治理IT有隐患门店，提升门店IT的整体稳定性。 核心痛点 如何高效的集中监控所有的门店？ 如何度量、发现、治理有IT隐患的门店？ 如...