夜莺-Nightingale
夜莺V7
夜莺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
参考资料
部署说明
前置说明
各种环境的选型建议
- Docker compose 方式:可用于快速测试,不建议上生产,如果要生产环境使用 Docker compose,需要对 Docker compose 真的很熟,社区很多朋友遇到问题其实是因为对 Docker compose 不熟悉导致踩坑
- 二进制部署:这是最推荐的方式,systemd 托管,开机自启动,挂了自动拉起,也可以方便配置 CPU 限制,使用 journalctl 看日志,日志自动有滚动处理,稳,升级也方便,老运维应该深有同感
- Helm 方式:公司大规模使用了 Kubernetes,可以选择 Helm 方式,前提是贵司对 Helm 这套能 hold 住,通常情况下,我们不推荐把夜莺服务端部署到 Kubernetes 中,因为 Kubernetes 一旦挂了监控就挂了,而监控系统作为 P0 级服务,最好是尽量少的依赖其他组件。如果真的因为 Kubernetes 挂了导致监控挂,其他团队的人就容易来怼你当初为啥选择这样的部署方案
- 存储选型:如果之前没有部署过,是个新环境,时序库选型建议使用 VictoriaMetrics,单机版 VictoriaMetrics 就可以抗住每秒上百万数据点,性能很好,CPU、内存的占用都比 Prometheus 少,而且,完全兼容 Prometheus 的查询接口。社区也有人用 Thanos,Thanos 的架构明显比 VictoriaMetrics 要复杂,简单的东西不容易出问题
- 时间校准:社区反馈的很多问题都是因为机器时间没有校准,监控系统对时间很敏感,请各位先把机器时间校准一致,让服务端的机器、时序库的机器、要监控的目标机器、浏览器所在的机器(通常是你的笔记本电脑或台式机)时间,都保持一致
用户名密码
夜莺安装完成之后,默认用户是 root
,密码是 root.2020
。部署完成之后,建议立即修改密码。另外修改 etc/config.toml
中的 SigningKey 为随机字符串,用于加密 jwt token,当然,如果是 v7.0.0.beta5 以上版本,系统会自动生成一个随机字符串,不需要手动修改 SigningKey。另外,尽量不要把夜莺暴露在公网,防止其他安全隐患。
之前看扫描网站,有上千个夜莺公网站点,好消息是夜莺的用户挺多的,坏消息是很多暴露在公网的夜莺都没有修改默认的用户名和密码,实在是太危险了。尽量、尽量不要把夜莺暴露在公网。
执行部署
- 视频教程:夜莺监控系统部署视频教程,一定看一下
- Docker compose 方式部署
- 二进制方式部署,即便使用 Docker 方式部署,这个章节也要读!
- Helm 方式部署
以上方式部署完成,就完成了夜莺中心端的部署,适用于单机房的场景,或者是多机房但是相互之间有良好专线的公司。
如果贵司是多机房架构,且担心机房网络割裂问题(比如某个机房和其他机房之间专线中断),则可以采用边缘机房部署架构,除了中心端部署 n9e 进程,还需要在边缘机房部署 n9e-edge 进程。边缘机房部署架构参考《附:边缘机房部署》
部署采集器
服务端部署完了,要采集监控数据需要部署 agent,参考《附:部署采集器》