夜莺运维指南之基本部署
对于一套监控系统而言，核心就是采集数据并存储，然后做告警判定、数据展示分析，整个流程图如下：
1.夜莺服务端
前置说明:
各种环境的选型建议
- 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。另外，尽量不要把夜莺暴露在公网，防止其他安全隐患
1.1 夜莺的安装(n9e)
- github releases：更新会更频繁，国外地址，下载可能会慢一些
- flashcat 下载中心：更新会慢一些，国内地址，下载更快
1.安装相关依赖
# apt-get -y install curl wget vim
# apt-get -y install mariadb
# apt-get -y install redis
2.安装最新版本
# wget https://download.flashcat.cloud/n9e-v7.3.0-linux-amd64.tar.gz
# tar -xf n9e-v7.3.0-linux-amd64.tar.gz
3.修改夜莺配置文件etc/config.toml
修改数据库密码
4.使用systemd进行管理
# vim /lib/systemd/system/n9e.service
[Unit]
Description="n9e.service"
After=network.target
[Service]
Type=simple
ExecStart=/data/n9e/n9e server
WorkingDirectory=/data/n9e
Restart=on-failure
SuccessExitStatus=0
LimitNOFILE=65536
StandardOutput=syslog
StandardError=syslog
SyslogIdentifier=n9e.service
[Install]
WantedBy=multi-user.target
# systemctl daemon-reload
# systemctl enable --now n9e.service
5.访问夜莺
浏览器访问夜莺的端口，即 17000，默认用户是 root，密码是 root.2020
1.2 普罗米修斯的安装(prometheus)
- 普罗米修斯官网: Prometheus - Monitoring system & time series database
- 普罗米修斯Github下载: Release 2.54.1 / 2024-08-27 · prometheus/prometheus (github.com)
# 下载适合自己操作系统内核的版本并解压
# 使用Systemd进行管理
# vim /lib/systemd/system/prometheus.service
[Unit]
Description="prometheus"
Documentation=https://prometheus.io/
After=network.target
[Service]
Type=simple
ExecStart=/data/prometheus/prometheus --config.file=/data/prometheus/prometheus.yml --storage.tsdb.path=/data/prometheus/data --storage.tsdb.retention.time=7d --web.enable-lifecycle --enable-feature=remote-write-receiver --query.lookback-delta=2m
Restart=on-failure
SuccessExitStatus=0
LimitNOFILE=65536
StandardOutput=syslog
StandardError=syslog
SyslogIdentifier=prometheus
[Install]
WantedBy=multi-user.target
# systemctl daemon-reload
# systemctl enable --now prometheus.service
数据源管理:
集成中心 -> 数据源 -> 添加数据源 -> 选择普罗米修斯
2 夜莺客户端
如果之前没有做过监控数据收集，可以使用夜莺团队提供的采集器 categraf，这同样是一款开源的 telemetry 数据采集器，它内置了 OS、SNMP、IPMI、MySQL、Redis、MongoDB、Oracle、Kafka、ElasticSearch、cAdvisor 等多种采集插件。
2.1 采集器的安装与配置(categraf)
Categraf 是一个开源的监控采集 Agent，类似 Telegraf、Grafana-Agent、Datadog-Agent，希望对所有常见监控对象提供高质量的监控数据采集能力，采用了 All-in-one 的设计理念，可以同时支持指标、日志、链路追踪数据的采集.
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 语言编写，静态编译依赖少，容易分发，易于安装；
- 尽可能落地最佳实践，不需要采集的数据无需采集，针对可能会对时序库造成高基数的问题在采集侧做出规避处理；
- 针对常用的采集对象，在提供采集能力的同时，配套整理出监控大盘和告警规则模版，用户可以直接导入使用；
下载
国内用户可以直接去 下载中心下载，国外用户推荐去categraf releases 页面，下载编译好的二进制，也可自行编译，编译只需要一条命令：go build 当然，前提是机器上有 Go 环境
# wget https://download.flashcat.cloud/categraf-v0.3.77-linux-amd64.tar.gz
# tar -xf categraf-v0.3.77-linux-amd64.tar.gz
# mv categraf-v0.3.77-linux-amd64 categraf
部署
在目标机器部署，只需要 categraf 二进制、以及 conf 目录，conf 下有一个主配置文件：
- config.toml，定义机器名、全局采集频率、全局附加标签、remote write backend地址等；
- 另外就是各种采集插件的配置目录，以input.打头，categraf 会遍历这些文件下的插件配置执行采集任务，如果某个采集器 xx 不想启用，把 input.xx 改个其他前缀(或者删除这个目录)，比如 bak.input.xx，categraf 就会忽略这个采集器
管理
一般在Linux中使用Syetemd进行管理，有保活机制
# vim /etc/systemd/system/categraf.service
[Unit]
Description="Categraf"
After=network.target
[Service]
Type=simple
ExecStart=/opt/categraf/categraf # categraf 二进制文件所在路径
WorkingDirectory=/opt/categraf
Restart=on-failure
SuccessExitStatus=0
LimitNOFILE=65536
StandardOutput=syslog
StandardError=syslog
SyslogIdentifier=categraf
[Install]
WantedBy=multi-user.target
# systemctl daemon-reload ;systemctl enable --now categraf.service
2.2 Prometheus生态的Exporters
虽然部署了Categraf 采集器，但是也会有Categraf 涉及不到的领域。如 Nginx 的vts 模块，如果通过 Categraf 采集器是无法获取到 Nginx-vts的数据。这个时候就需要使用Prometheus生态的Exporters了。以下是配置和使用Nginx的vts采集Exports
Nginx_vts_export 的 网站: https://github.com/sysulq/nginx-vts-exporter
# Prometheus服务端配置
# 下载nginx-vtx-exporter_0.10.8_linux_amd64.tar.gz模块
# wget "https://github.com/sysulq/nginx-vts-exporter/releases/download/v0.10.8/nginx-vtx-exporter_0.10.8_linux_amd64.tar.gz"
# tar -xf nginx-vtx-exporter_0.10.8_linux_amd64.tar.gz
# 使用systemctl 管理nginx-vts-exporter进程，相关配置按实际使用业务进行修改
# vim /usr/lib/systemd/system/nginx_vts_exporter.service
[Unit]
Description=prometheus_nginx_vts
After=network.target
[Service]
Type=simple
ExecStart=/usr/local/nginx-vts-exporter/nginx-vts-exporter -nginx.scrape_uri http://admin:admin123@/vts/format/json
Restart=on-failure
[Install]
WantedBy=multi-user.target
# systemctl daemon-reload
# systemctl enable nginx_vts_exporter
# systemctl start nginx_vts_exporter
# systemctl status nginx_vts_exporter
注意，下载nginx-vtx-exporter_0.10.8_linux_amd64.tar.gz模块 需要适合自己的系统版本，否则会报错
编辑Prometheus配置文件
# vim /data/prometheus/prometheus.yml
# my global config
global:
scrape_interval: 15s # Set the scrape interval to every 15 seconds. Default is every 1 minute
evaluation_interval: 15s # Evaluate rules every 15 seconds. The default is every 1 minute.
# scrape_timeout is set to the global default (10s).
# Alertmanager configuration
alerting:
alertmanagers:
- static_configs:
- targets:
# - alertmanager:9093
# Load rules once and periodically evaluate them according to the global 'evaluation_interval'.
rule_files:
# - "first_rules.yml"
# - "second_rules.yml"
# A scrape configuration containing exactly one endpoint to scrape:
# Here it's Prometheus itself.
scrape_configs:
# The job name is added as a label `job=<job_name>` to any timeseries scraped from this config.
- job_name: "prometheus"
# metrics_path defaults to '/metrics'
# scheme defaults to 'http'.
static_configs:
- targets: ["localhost:9090"]
- job_name: "nginx_vts"
static_configs:
- targets: ["localhost:9913"]
# prometheus配置文件检测, 避免配置文件错误导致服务无法启动从而业务丢失
# ./promtool check config prometheus.yml
Checking prometheus.yml
SUCCESS: prometheus.yml is valid prometheus config file syntax
# 没问题的话直接重启Prometheus服务器, 有问题排查配置文件是否错误, 缩进是否有问题
# systemctl restart prometheus.service
补充说明:
Categraf 采集数据，然后通过 Prometheus remote write 协议推给夜莺，所以需要把夜莺的地址告诉 Categraf，在 Categraf 的配置文件中配置夜莺的地址就可以了。Categraf 的配置文件在 conf/config.toml，把配置文件中的 127.0.0.1:17000（老版本默认写的是 127.0.0.1:19000） 改成你的夜莺的 IP 和端口即可。
原文地址：https://blog.csdn.net/m0_60981735/article/details/144206292
免责声明：本站文章内容转载自网络资源，如本站内容侵犯了原著者的合法权益，可联系本站删除。更多内容请关注自学内容网（zxcms.com）！