夜莺-Nightingale
夜莺V6
项目介绍
架构介绍
快速开始
黄埔营
安装部署
升级
采集器
使用手册
API
数据库表结构
users
target
user_group
user_group_member
task_tpl
task_tpl_host
task_record
sso_config
role
role_operation
recording_rule
notify_tpl
metric_view
datasource
configs
chart_share
busi_group
busi_group_member
builtin_cate
board
board_payload
alerting_engines
alert_subscribe
alert_rule
alert_mute
alert_his_event
alert_cur_event
alert_aggr_view
FAQ
转发数据给多个时序库
机器列表数据异常
数据流图
监控数据时有时无
查询原始监控数据
快捷视图详解
告警自愈模块使用
仪表盘里只展示我的机器
仪表盘里图表数据缺失
设置自定义告警通知方式
target_up指标的问题
夜莺可以监控 x 么
告警和恢复的判断逻辑
容量规划问题
connection refused
登录与认证
数据采集器Categraf
日志写到`/var/log/messages`
告警规则&告警模板如何引用变量
采集到的数据是字符串怎么处理
管理员密码忘记了
制作大盘如何添加图片
添加loki数据源报错
v6小版本升级有什么 sql 要执行吗
机器列表有展示,但采集数据查询不到
n9e 启动异常报错
n9e集群部署配置修改
推送 Promethus 报错 OOO
机器列表怎么忽略云资源
告警规则仅在本业务组生效失败
categraf 启动 oracle 插件报错
告警自愈不生效
n9e查询时序库EOF报错
手动编译项目报错
promQL 使用函数标签信息丢失
内存使用率+可用率不等于100
夜莺仪表盘有哪些内置变量
categraf配置文件支持热加载吗
导入 Grafana 仪表盘无效数据源
如何查看报错消息
采集器-Categraf
开源生态
Telegraf
Prometheus
版权声明
第1章:天降奇兵
第2章:探索PromQL
开篇
理解时间序列
Metrics类型
初识PromQL
PromQL操作符
PromQL聚合操作
PromQL内置函数
在HTTP API中使用PromQL
最佳实践:4个黄金指标和USE方法
小结
第3章:Prometheus告警处理
开篇
Prometheus告警简介
自定义Prometheus告警规则
部署Alertmanager
Alertmanager配置概述
基于标签的告警处理路由
使用Receiver接收告警信息
告警模板详解
屏蔽告警通知
使用Recoding Rules优化性能
小结
第4章:Exporter详解
第5章:数据与可视化
第6章:集群与高可用
第7章:Prometheus服务发现
第8章:监控Kubernetes
开篇
初识Kubernetes
在Kubernetes下部署Prometheus
Kubernetes下的服务发现
使用Prometheus监控Kubernetes集群
基于Prometheus的弹性伸缩
小结
第9章:Prometheus Operator
参考资料
Categraf 总体介绍
Categraf 是一个开源的监控采集 Agent,类似 Telegraf、Grafana-Agent、Datadog-Agent,希望对所有常见监控对象提供高质量的监控数据采集能力,采用了 All-in-one 的设计理念,可以同时支持指标、日志、链路追踪数据的采集。Categraf 由快猫星云技术团队研发并开源,快猫星云技术团队同时也是 Open-Falcon 和 Nightingale 创始研发团队。
Categraf 的代码托管在 GitHub:https://github.com/flashcatcloud/categraf
对比
Categraf 和 Telegraf、Exporters、Grafana-Agent、Datadog-Agent 等的关系是什么?
- Telegraf 是 InfluxDB 生态的产品,因为 InfluxDB 是支持存储字符串类型的 value,所以 Telegraf 采集的很多 field 是字符串类型,另外 InfluxDB 的设计,允许 labels 是非稳态结构,比如
result_code
标签,有时其value
是0
,有时其value
是1
,在 InfluxDB 中都可以接受。但是上面两点,在以 Prometheus 为代表的、符合 OpenMetrics 标准的时序库中,处理起来就很麻烦。 - Prometheus 生态有各种 Exporters,但是设计逻辑都是一个监控类型一个 Exporter,甚至一个实例一个 Exporter,生产环境就可能会部署特别多的 Exporters,管理起不方便。
- Grafana-Agent import 了大量 Exporters 的代码,没有裁剪,没有优化,没有最佳实践在产品上的落地,有些中间件,仍然采取的是一个 Grafana-Agent 一个目标实例,导致会有很多的 Grafana-Agent 进程在运行,管理起来也很不方便。
- Datadog-Agent 确实是集大成者,但是大量代码是 Python 的,整个发布包也比较大,有不少历史包袱,而且生态上是自成一派,和云原生生态、开源社区相对割裂。
所以,Categraf 确实又是一个轮子,期望解决和规避上面分析提到的一些弊端,Categraf的设计目标:
- 开源、开放、遵循 OpenTelemetry 标准;
- 拥抱 Prometheus 开源生态,支持
remote_write
写入协议,支持将数据写到类似于 Promethues、M3DB、VictoriaMetrics、InfluxDB、Open-Falcon、TDengine等时序数据库; - 指标数据只采集数值,不采集字符串,标签维持稳态结构;
- 采用 All-in-One 的设计理念,所有的采集工作用一个 Agent 搞定;
- 采用 Go 语言编写,静态编译依赖少,容易分发,易于安装;
- 尽可能落地最佳实践,不需要采集的数据无需采集,针对可能会对时序库造成高基数的问题在采集侧做出规避处理;
- 针对常用的采集对象,在提供采集能力的同时,配套整理出监控大盘和告警规则模版,用户可以直接导入使用;