夜莺-Nightingale
夜莺V7
项目介绍 功能概览
部署升级 部署升级
数据接入 数据接入
告警管理 告警管理
数据查看 数据查看
功能介绍 功能介绍
API FAQ
夜莺V6
项目介绍 架构介绍
快速开始 快速开始
黄埔营
安装部署 安装部署
升级
采集器 采集器
使用手册 使用手册
API API
数据库表结构 数据库表结构
FAQ FAQ
开源生态
Prometheus
版权声明
第1章:天降奇兵 第1章:天降奇兵
第2章:探索PromQL 第2章:探索PromQL
第3章:Prometheus告警处理 第3章:Prometheus告警处理
第4章:Exporter详解 第4章:Exporter详解
第5章:数据与可视化 第5章:数据与可视化
第6章:集群与高可用 第6章:集群与高可用
第7章:Prometheus服务发现 第7章:Prometheus服务发现
第8章:监控Kubernetes 第8章:监控Kubernetes
第9章:Prometheus Operator 第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。另外,尽量不要把夜莺暴露在公网,防止其他安全隐患。

之前看扫描网站,有上千个夜莺公网站点,好消息是夜莺的用户挺多的,坏消息是很多暴露在公网的夜莺都没有修改默认的用户名和密码,实在是太危险了。尽量、尽量不要把夜莺暴露在公网。

执行部署

以上方式部署完成,就完成了夜莺中心端的部署,适用于单机房的场景,或者是多机房但是相互之间有良好专线的公司。

如果贵司是多机房架构,且担心机房网络割裂问题(比如某个机房和其他机房之间专线中断),则可以采用边缘机房部署架构,除了中心端部署 n9e 进程,还需要在边缘机房部署 n9e-edge 进程。边缘机房部署架构参考《附:边缘机房部署

部署采集器

服务端部署完了,要采集监控数据需要部署 agent,参考《附:部署采集器

快猫星云 联系方式 快猫星云 联系方式
快猫星云 联系方式
快猫星云 联系方式
快猫星云 联系方式
快猫星云
OpenSource
开源版
Flashcat
Flashcat