夜莺官方文档优化第一弹：手把手教你部署和架构讲解，消灭所有部署失败的 case！干！

Posted 2023-05-18 龙渊秦五

夜莺（ Nightingale ）安装方式，不同的场景使用不用的安装方式

前置说明

各种环境的选型建议

• Docker compose 方式：仅仅用于简单测试，不推荐在生产环境使用 Docker compose，升级起来挺麻烦的，除非你对 Docker compose 真的很熟
• 二进制部署：最推荐的方式，稳，升级也方便
• Helm 方式：公司大规模使用了 Kubernetes，可以选择 Helm 方式，前提是贵司对 Helm 这套真的很熟
• 存储选型：如果之前没有部署过，是个新环境，时序库选型建议使用 VictoriaMetrics，单机版 VictoriaMetrics 就可以抗住每秒上百万数据点，性能很好，CPU、内存的占用都比 Prometheus 少，而且，完全兼容 Prometheus 的查询接口
• 时间校准：社区反馈的很多问题都是因为机器时间没有校准，监控系统对时间很敏感，请各位先把机器时间校准一致，让服务端的机器、时序库的机器、要监控的目标机器、浏览器所在的 PC 时间，都保持一致

用户名密码

默认用户是 root，密码是 root.2020。

使用 Docker compose 快速体验

具体可以参考这个文档。不推荐使用，除非你对 Docker compose 真的很熟！

安装前置依赖

我们更推荐二进制的方式来部署，后文都是以二进制的方式来说明部署方式以及架构。夜莺依赖 mysql 存储用户配置类数据，依赖 redis 存储 jwt token 和机器心跳上报的 metadata，所以，先准备 mysql 和 redis。这俩组件请大家自行安装，这里也提供一个小脚本来安装这两个组件，大家可以参考：

# install mysql
yum -y install mariadb*
systemctl enable mariadb
systemctl restart mariadb
mysql -e "SET PASSWORD FOR \'root\'@\'localhost\' = PASSWORD(\'1234\');"

# install redis
yum install -y redis
systemctl enable redis
systemctl restart redis

上例中 mysql 的 root 密码设置为了 1234，建议维持这个不变，后续就省去了修改配置文件的麻烦。如果你想修改默认用户名和密码，就要对应的修改配置文件中的 mysql 连接信息，配置文件的哪个地方配置了 mysql 的密码呢？通过下面的命令可以找到：

# 夜莺的主配置文件是 etc/config.toml
grep "1234" etc/config.toml

安装夜莺

可以去 https://flashcat.cloud/download/nightingale/ 找最新版本的包，文档里的包地址可能已经不是最新的了

# 创建个 n9e 的目录，后面把 n9e 相关的文件解压到这里
mkdir -p /opt/n9e && cd /opt/n9e

# 下载 n9e 发布包，amd64 是 x84 的包，下载站点也提供 arm64 的包，如果需要其他平台的包则要自行编译了
tarball=n9e-v6.0.0-ga.7.0.2-linux-amd64.tar.gz
urlpath=https://download.flashcat.cloud/$tarball
wget -q $urlpath || exit 1

# 解压缩发布包
tar zxvf $tarball

# 解压缩之后，可以看到 n9e.sql 是建表语句，导入数据库
mysql -uroot -p1234 < n9e.sql

# 启动 n9e，先使用 nohup 简单测试，如果需要 systemd 托管，请自行准备 service 文件
nohup ./n9e &> n9e.log &

# 检查 n9e.log 是否有异常日志，检查端口是否在监听，正常应该监听在 17000
ss -tlnp|grep 17000

如果日志和端口都没啥问题，恭喜，你完成了夜莺的安装！通过浏览器访问这个机器的 17000，理论上就可以看到登录页面了。

玩法1：仅使用夜莺做告警管理

如果您之前已经部署了 Prometheus、Thanos、VictoriaMetrics、M3DB、Mimir 等某个时序库，只是想使用夜莺的告警管理功能，没问题，架构如下：

假设你之前有个 Prometheus，只需要把 Prometheus 作为数据源配置进来就可以了，入口在：

具体配置样例如下：

这里一些配置项的含义解释如下：

• 名称：随意取名，就是个标识，使用英文命名
• URL：Prometheus 的访问地址，如果是其他时序库，这个地址就不同喽，比如集群版本的 VictoriaMetrics，可能是类似这么个地址：http://127.0.0.1:8481/select/0/prometheus
• 超时时间：单位是毫秒，建议最小设置为10000，即10s，如果一些大的查询，就会比较耗时
• 授权：如果时序库启用了 Basic auth，这里就配置对应的 Basic auth username 和 password 即可
• 跳过 SSL 验证：如果证书不是正儿八经的证书想要跳过校验，就勾选这个项
• 自定义 HTTP 头：访问时序库的时候可以附加一些 HTTP Header
• write_addr：这个是时序库的 remote write 地址，我的例子中是 Prometheus，所以 url path 是 /api/v1/write，如果是其他时序库可能不同，比如集群版本的 VictoriaMetrics，remote write 地址可能是类似这个样子：http://127.0.0.1:8480/insert/0/prometheus/api/v1/write。这个信息用在哪里呢？平时都用不到，除非你在夜莺里使用了记录规则（recording rule），记录规则会生成新指标，新指标要回写时序库，所以要求时序库提供 remote write 地址。如果你不知道啥是 recording rule，可以 google 一下，google 关键字：“Prometheus recording rule”，或者跳过以后再说
• 关联告警引擎集群：这个说起来有点复杂了，选中默认的 default 即可，如果需要在边缘机房单独部署 n9e-alert 的时候，才需要详细了解这个信息

以上配置完成之后，我们去即时查询验证一下，看看能否查询到这个 Prometheus 的数据：

如上就表示正常的，如果有些数据确定时序库里是有的，但是在即时查询里查不到，有可能是时间没有校准，请自行检查时间。之后，就可以在夜莺里配置告警规则了，具体可以参考后续告警相关的文档。

玩法2：使用 categraf 采集数据，使用夜莺接收数据

社区里经常有小伙伴咨询，问夜莺可以监控xx么？

其实，夜莺啥都可以监控，又啥都监控不了。夜莺是一个服务端组件，类似 Grafana，可以接入不同的数据源，比如 Prometheus、VictoriaMetrics、Thanos 等等，只要数据进到这些库里了，夜莺就可以对数据源的数据进行分析、告警、可视化，以及后续的事件处理、告警自愈。

当然，夜莺也有端口接收监控数据，可以跟开源社区常见的各种监控采集器打通，比如 Telegraf、Categraf、Grafana-agent、Datadog-agent、Prometheus 生态的各类 Exporter 等等。这些 agent 采集了数据推给夜莺，夜莺适配了这些 agent 的数据传输协议，所以可以接收这些 agent 上报的监控数据，转存到后端对接的数据源，之后就可以对这些数据做告警分析、可视化。

所以夜莺本身不做监控数据采集，啥都不能监控，但是夜莺可以对接数据源，又啥都可以监控。

这一小节，我们介绍使用 Categraf 作采集器，然后推数据给夜莺，夜莺转存到时序库，并且后续对这些数据做可视化、告警等，整个架构如下图所示：

图上画了三个 agent：datadog-agent、telegraf、categraf，都可以和夜莺对接，我们推荐的是 categraf，所以本节主要以 categraf 举例。夜莺默认监听的端口是 17000，通过 api：/prometheus/v1/write 接收 remote write 协议的监控数据，categraf 恰好可以以 remote write 协议上报监控数据，所以二者可以对接，telegraf、grafana-agent 其实也可以以 remote write 协议上报监控数据，所以也可以和夜莺对接。

夜莺收到监控数据之后，夜莺自身不存储这些时序数据，直接转存到后端时序库，在这里，夜莺的角色只是一个 Pushgateway 的角色。我们推荐的时序库是单机版本的 VictoriaMetrics，后文就以此演示。当然了，夜莺可以同时并行转发数据给后端多个时序库，就像上图画的，把一份数据同时存储在 VictoriaMetrics 和 Prometheus，也是可以通过配置实现的。

安装单机版本的 VictoriaMetrics

如果选用集群版本的 VictoriaMetrics，可以参考 这里。当然，单机版本对绝大部分公司，够用了，配合云盘保障数据可靠性，稳。所以这里，我就演示单机版本的部署。

安装 VictoriaMetrics

VictoriaMetrics 下载地址在 github releases 上，作为技术人员，我想，你应该可以下载的到。我的环境是 x86_64 的 linux，所以选择下载：victoria-metrics-linux-amd64-v1.90.0.tar.gz （撰写这个文档的时候，最新版本是 v1.90.0）。

VictoriaMetrics 解压缩之后，里边就一个二进制：

[root@vm-159 tarball]# ll vic*
-rw-r--r--. 1 root root 10370599 5月  17 18:43 victoria-metrics-linux-amd64-v1.90.0.tar.gz
-rwxr-xr-x. 1 1000 1000 20191152 4月   7 09:00 victoria-metrics-prod

启动它：

[root@vm-159 tarball]# nohup ./victoria-metrics-prod &> stdout.log &
[1] 12632
[root@vm-159 tarball]# ss -tlnp|grep 12632
LISTEN     0      128          *:8428                     *:*                   users:(("victoria-metric",pid=12632,fd=10))

通过上面的命令可以看出，单机版本的 VictoriaMetrics 监听在 8428 端口。通过浏览器访问 VictoriaMetrics 的 8428，理论上可以看到下面的页面：

如上，就表示 VictoriaMetrics 安装成功，当然，我仅仅使用 nohup 简单启动的，如果生产环境，建议使用 systemd 托管并设置开机自启动。

打通夜莺和 VictoriaMetrics

分两个步骤，首先就类似上面配置 Prometheus 数据源那种方式，在夜莺里配置一个 VictoriaMetrics 的数据源，比如我的配置：

其次，就需要修改配置文件了。打开夜莺的 etc/config.toml 配置，找到 HTTP.Pushgw 部分，默认配置如下：

[HTTP.Pushgw]
Enable = true
# [HTTP.Pushgw.BasicAuth]
# user001 = "ccc26da7b9aba533cbb263a36c07dcc5"

这个表示：开启夜莺的监控数据接收类的 API，默认就是开启的，所以，默认配置就够了，不用动。那个 HTTP.Pushgw.BasicAuth 表示 BasicAuth（不懂啥是 BasicAuth 请自行 Google 哈） 的配置，如果是内网环境就维持注释就可以了，不用开启 BasicAuth，如果要把夜莺接收数据的接口暴露到公网，为了安全考虑，就需要 HTTPS + BasicAuth 双重保障了，这里的 HTTP.Pushgw.BasicAuth 相关的配置在公网环境下就应该打开，而且，应该修改这个 password：ccc26da7b9aba533cbb263a36c07dcc5，不要使用默认的 password。

另一个要修改的配置是 Pushgw.Writers 部分，把 VictoriaMetrics 的 remote write 地址配置上，我的环境的例子如下：

[Pushgw]
LabelRewrite = true
[[Pushgw.Writers]]
Url = "http://127.0.0.1:8428/api/v1/write"

这里的 [[Pushgw.Writers]] 是双中括号扩起来的，这在 toml 配置中表示数组，如果你想把数据转发给后端多个时序库，就可以配置多个 [[Pushgw.Writers]]，比如：

[Pushgw]
LabelRewrite = true
[[Pushgw.Writers]]
Url = "http://127.0.0.1:8428/api/v1/write"
[[Pushgw.Writers]]
Url = "http://127.0.0.1:9090/api/v1/write"

OK，这样一来，夜莺接收到 categraf、telegraf、grafana-agent 等各类 agent 上报上来的监控数据，都会转发给后端的 VictoriaMetrics，完活。

部署 categraf 上报监控数据

Categraf 的安装请 参考文档，这个文档已经很详细了就不再赘述了。重点关注配置文件 config.toml，一个是 heartbeat 的配置：

[heartbeat]
enable = true
url = "http://127.0.0.1:17000/v1/n9e/heartbeat"

这个配置是 Categraf 向夜莺心跳的地址，夜莺 v5 的话没有这个机制，需要把 Categraf heartbeat 的 enable 关掉。我这里演示的夜莺 v6，所以 heartbeat 的 enable 要设置为 true，建议大家用高版本的 Categraf，我这里用的是 v0.3.4。

另一个配置是 writers 部分：

[[writers]]
url = "http://127.0.0.1:17000/prometheus/v1/write"

这表示：把数据推给夜莺的 17000 端口，url path 是 /prometheus/v1/write 这是夜莺的 remote write 协议的数据接收地址。

上面我的例子中，夜莺的地址都是：127.0.0.1:17000，因为我的 Categraf 和 夜莺 在一台机器上，如果你的 Categraf 和夜莺在不同的机器，注意改成合适的 IP。

按照 文档 中介绍的方法启动 Categraf，我这只是临时测试，所以，直接 nohup 启动得了：

nohup ./categraf &> categraf.log &

验证结果

如果一切正常，Categraf 就会推数据给夜莺，夜莺转发给 VictoriaMetrics，而 VictoriaMetrics 又是夜莺的数据源，所以在夜莺的即时查询页面，理论上可以查询到 VictoriaMetrics 的数据，验证一下：

cpu_usage_active 这个指标就是 Categraf 采集上报的，看起来一切正常。欧耶！

夜莺高可用方案

这里服务端总共涉及到4个组件：时序库、mysql、redis、夜莺，其中时序库、mysql、redis 的高可用，大家 Google 一下网上大堆资料，这里不展开。关键是夜莺如何做高可用？

其实，很简单，多部署几个 n9e 实例就可以了。多个 n9e 实例会自动组成集群，分担压力。n9e 前面可以架设负载均衡，四层、七层都可以，某个 n9e 实例挂掉，负载均衡会自动剔除，用户通过浏览器访问夜莺的时候，访问负载均衡的地址，Categraf 的 writer 和 heartbeat 也配置成负载均衡的地址，就可以了。

如果夜莺里配置了3千条告警规则，部署了3个n9e实例，这三个n9e实例就会自动分配（通过一致性哈希算法）要处理的告警规则，确保每个n9e实例只处理大概1千条告警规则，分担告警引擎处理压力。如果某个n9e实例挂掉，其他实例会自动感知（利用mysql做了一些心跳机制）自动接管未被处理的告警规则，这也是把n9e集群化部署的好处。

高级玩法

如果，夜莺部署在北京机房，某些机房和北京机房网络链路较差，此时，应该把时序库、告警引擎下沉部署，具体应该如何做呢？看这里

转载自：https://flashcat.cloud/docs/content/flashcat-monitor/nightingale-v6/install/intro/ 

2018年最新手把手教你搭建中小型互联网公司后台服务架构与运维架构

本课程主要是针对如何从无到有搭建中小型互联网公司后台服务架构和运维架构的课程，课程所涉及的内容均是当前应用最广泛的技术和工具。本课程所讲解的技术体系已经在多个中小型互联网公司中实战运行使用，目前运行已经非常稳定，数据量也是在不断持续增加。并且，这个技术体系也正在被其他很多互联网公司应用，希望通过此课程，让大家能快速熟练掌握各个技术，并且能实际应用到项目中。课程将会通过实际案例讲解，并且会提供完整的视频案例源码供学员学习使用，同时有需要的企业或学员可以直接拿本套教学案例代码来使用或者二次开发。

本课程设计的技术及工具如下：
后台服务架构：dubbo、spring-boot、spring mvc、spring-security-oauth2、spring-ldap、spring-data-jpa等
项目管理工具：maven、nexus
版本管理工具：gitlab、git
数据库：mysql、mongodb
运维监控工具：Open-Falcon
日志管理工具：ELK
持续集成工具：Jenkins
协作工具：confluence
缓存：redis
消息中间件：kafka、rocketmq
web服务器：tomcat、nginx
容器引擎：docker

本课程讲解的流程：
1、 首先讲解大家都已经熟悉的dubbo技术体系，结合dubbo搭建出一个完整的基于restful的技术框架
2、 结合dubbo的restful框架，加上基于oauth2的token验证，并实现统一用户中心的设计
3、 重点讲解spring boot，然后结合之前的dubbo技术框架进行改造，实现spring boot和dubbo的相融合
4、 作为一个技术架构肯定涉及java性能调优，所以之后会根据图示讲解jvm里的一系列东西，帮助大家充分了解jvm
5、 讲解消息中间件redis，以及高可用集群搭建，以及里面的数据类型，分布式以及一致性问题的讲解
6、 git、elk、jenkins、confluence、kafak、rocketmq工具安装讲解
7、 讲解运维监控工具Open-Falcon，如何保证及时通知运维及开发人员服务器的问题，保证服务器以及服务正常运行
8、 讲解docker系列课程，结合docker进行部署

架构讲解设计的目标:
1、 低成本:任何公司存在的价值都是为了获取商业利益。在可能的情况下，希望一切都是低成本的。
2、 高性能:网站性能是客观的指标，可以具体体现到响应时间、吞吐量等技术指标。系统的响应延迟，指系统完成某一功能需要使用的时间；系统的吞吐量，指系统在某一时间可以处理的数据总量，通常可以用系统每秒处理的总的数据量来衡量；系统的并发能力，指系统可以同时完成某一功能的能力，通常也用 QPS(query per second)来衡量。
3、 高可用：系统的可用性(availability)指系统在面对各种异常时可以正确提供服务的能力。系统的可用性可
以用系统停服务的时间与正常服务的时间的比例来衡量，也可以用某功能的失败次数与成功次数的比例来衡量。
4、 易伸缩：注重线性扩展，是否可以容易通过加入机器来处理不断上升的用户访问压力。系统的伸缩性(scalability)指分布式系统通过扩展集群机器规模提高系统性能（吞吐、延迟、并发）、存储容量、计算能力的特性。
5、 高安全：现在商业环境中，经常出现被网站被拖库，用户账户被盗等现象。网站的安全性不言而喻。

课程大纲

第1节课程内容介绍 [免费观看] 00:11:08分钟 |
第2节服务器统一规划配置安装 [免费观看] 00:07:18分钟 |
第3节后台服务工具maven：maven安装配置 [免费观看] 00:05:10分钟 |
第4节后台服务工具maven：maven本地资源库设置 [免费观看] 00:09:45分钟 |
第5节后台服务工具maven：使用Nexus配置Maven私有仓库 [免费观看] 00:16:29分钟 |
第6节后台服务工具Eclipse: Eclipse导入jdk1.800:03:27分钟 |
第7节后台服务数据库工具mysql：mysql安装00:05:21分钟 |
第8节后台服务nosql数据库mongodb：高可用讲解以及安装00:17:04分钟 |
第9节后台服务代码架构：早期基于spring mvc后台服务搭建及演示00:19:15分钟 |
第10节后台服务代码架构：基于spring的mybatis代码结构配置使用00:09:39分钟 |
第11节后台服务代码架构：利用mybatis生成器自动生成实体类、DAO接口和Mapping映射文件00:16:40分钟 |
第12节后台服务代码架构：基于spring的后台代码结构设计及搭建00:17:08分钟 |
第13节后台服务代码架构：log4j详细配置及解释00:13:28分钟 |
第14节后台服务代码架构：duboo集群部署安装00:08:41分钟 |
第15节后台服务代码架构：dubbo控制台及监控台安装部署00:11:41分钟 |
第16节后台服务代码架构：dubbo+spring XML配置及属性设置00:23:33分钟 |
第17节后台服务代码架构：dubbo集成restful协议实现post、delete、get请求00:28:39分钟 |
第18节后台服务代码架构：dubbo启动时检查、集群容错、负载均衡、线程模型的设置以及选择00:10:49分钟 |
第19节后台服务代码架构：duboo直连、只订阅、只注册设置00:04:13分钟 |
第20节后台服务代码架构：dubbo协议讲解以及选择00:03:28分钟 |
第21节后台服务代码架构：实现开发、测试、生产环境区分运行配置00:06:05分钟 |
第22节后台服务工具postman：postman介绍以及使用00:04:06分钟 |
第23节后台服务代码架构：基于restful实现接口json数据解析00:09:14分钟 |
第24节后台服务代码架构：基于assembly结合maven插件实现代码压缩打包00:10:22分钟 |
第25节后台服务工具ldap：统一用户中心ldap工具使用以及安装00:10:09分钟 |
第26节后台服务代码架构：基于spring-ladp的统一用户中心结构设计以及代码结构设计00:15:14分钟 |
第27节后台服务代码架构：基于spring-data的mongodb连接以及配置00:23:16分钟 |
第28节后台服务代码架构：基于spring-security-oauth2的mysql数据表设计00:02:40分钟 |
第29节后台服务代码架构：基于spring-security-oauth2实现接口token访问验证00:18:26分钟 |
第30节后代服务代码架构：spring-boot简单介绍以及基于restful的web服务快速搭建00:21:08分钟 |
第31节后代服务代码架构：spring-boot结合Swagger2构建RESTful API测试体系00:14:32分钟 |
第32节后代服务代码架构：结合spring-boot实现多环境配置以及解决读取配置文件中文乱码问题00:14:42分钟 |
第33节后代服务代码架构：spring-boot实现统一异常处理00:16:56分钟 |
第34节后代服务代码架构：Spring Boot中使用JdbcTemplate访问数据库00:19:55分钟 |
第35节后代服务代码架构：Spring Boot中使用Spring-data-jpa访问数据库00:27:21分钟 |
第36节后代服务代码架构：Spring Boot中多数据源配置100:13:51分钟 |
第37节后代服务代码架构：Spring Boot中多数据源配置200:19:13分钟 |
第38节后代服务代码架构：Spring Boot中使用Spring-data-jpa访问数据库实现分页00:15:45分钟 |
第39节后代服务代码架构：项目应用中spring-boot整合mybatis00:12:30分钟 |
第40节后代服务代码架构：项目应用中spring-boot-MyBatis注解配置详解增删改查00:14:30分钟 |
第41节后代服务代码架构：项目应用中spring-boot整合Redis00:18:34分钟 |
第42节后代服务代码架构：项目应用中spring-boot整合mongodb00:26:09分钟 |
第43节后代服务代码架构：spring-boot使用事务管理00:11:54分钟 |
第44节后代服务代码架构：spring-boot创建定时任务00:07:56分钟 |
第45节后代服务代码架构：spring-boot实现异步调用00:12:03分钟 |
第46节后代服务代码架构：spring-boot日志配置详解00:22:13分钟 |
第47节后代服务代码架构：spring-boot中将日志记录到mongodb中00:06:01分钟 |
第48节后代服务代码架构：spring-boot整合spring-security00:14:46分钟 |
第49节后代服务代码架构：spring-boot使用EhCache做集中式缓存00:26:48分钟 |
第50节后代服务代码架构：spring-boot使用Redis做集中式缓存00:09:35分钟 |
第51节后代服务代码架构：spring-boot实现邮件发送00:17:53分钟 |
第52节后台服务于工具消息中间件：rabbitmq安装00:05:09分钟 |
第53节后代服务代码架构：spring-boot使用消息中间件00:09:53分钟 |
第54节后代服务代码架构：spring-boot+dubbo生产者与消费者配置00:10:15分钟 |
第55节java虚拟机介绍：一张图详解虚拟机类加载机制00:15:44分钟 |
第56节java虚拟机介绍：一张图详解jvm内存运行机制以及参数配置00:11:27分钟 |
第57节java虚拟机介绍：一张图详解GC00:15:08分钟 |
第58节java虚拟机介绍：java程序启动参数设置优化00:16:45分钟 |
第59节基于ThreadPoolTaskExecutor类的线程池讲解以及代码中配置使用详解00:09:00分钟 |
第60节使用线程池与CountDownLatch多线程提升系统性能00:05:05分钟 |
第61节后台服务工具redis：高可用redis集群搭建及原理详解00:11:27分钟 |
第62节后台服务工具redis：AOF与RDB持久化存储以及备份和恢复00:11:01分钟 |
第63节后台服务工具redis：详解redis操作命令00:11:53分钟 |
第64节后台服务工具redis：redis之管道模式00:08:08分钟 |
第65节后台服务代码架构：基于jedis连接redis集群00:10:39分钟 |
第66节后台服务代码架构：项目实际应用中redis缓存与数据库一致性问题解决00:08:26分钟 |
第67节后台服务代码架构：项目实际应用中redis实现分布式操作锁00:09:01分钟 |
第68节后台服务工具gitlab：版本管理工具gitlab安装以及配置介绍00:11:53分钟 |
第69节后台服务工具git：git安装及本地仓库对应gitlab仓库00:09:23分钟 |
第70节后台服务工具git：git介绍以及各种命令操作演示00:26:27分钟 |
第71节后台服务工具tomcat：安装以及使用，同服务器多tomcat端口配置00:02:02分钟 |
第72节后台服务工具nginx：安装以及反向代理设置及参数设置优化00:16:04分钟 |
第73节运维架构持续集成jenkins：安装以及相关插件安装00:10:16分钟 |
第74节运维架构持续集成jenkins：权限控制管理00:11:11分钟 |
第75节运维架构持续集成jenkins：代码持续集成部署00:06:03分钟 |
第76节后台服务于工具消息中间件kafka：架构介绍00:12:28分钟 |
第77节后台服务于工具消息中间件kafka：高可用集群安装00:14:29分钟 |
第78节后台服务于工具消息中间件kafka：发送与接收代码00:31:28分钟 |
第79节运维架构日志管理ELK：ElasticSearch 、 Logstash 和 Kibana 介绍，结合redis安装配置及展示00:19:24分钟 |
第80节运维架构服务监控Open-Falcon：介绍以及安装00:07:33分钟 |
第81节运维架构服务监控Open-Falcon：环境准备00:06:17分钟 |
第82节运维架构服务监控Open-Falcon：单机安装和分布式安装说明00:02:07分钟 |
第83节运维架构服务监控Open-Falcon：后端服务安装并启动00:05:58分钟 |
第84节运维架构服务监控Open-Falcon：前端安装00:07:45分钟 |
第85节运维架构服务监控Open-Falcon：安装客户端数据采集插件-Agent00:06:51分钟 |
第86节运维架构服务监控Open-Falcon：安装数据转发服务-Transfer00:05:33分钟 |
第87节运维架构服务监控Open-Falcon：安装绘图数据的组件- Graph00:05:28分钟 |
第88节运维架构服务监控Open-Falcon：安装查询组件-API00:03:36分钟 |
第89节运维架构服务监控Open-Falcon：心跳服务- HBS00:06:36分钟 |
第90节运维架构服务监控Open-Falcon：告警判断-Judge00:03:38分钟 |
第91节运维架构服务监控Open-Falcon：告警处理-Alarm00:04:03分钟 |
第92节运维架构服务监控Open-Falcon：邮件、短信、电话发送接口00:11:26分钟 |
第93节运维架构服务监控Open-Falcon：检测监控数据上报异常- Nodata00:03:32分钟 |
第94节运维架构服务监控Open-Falcon：集群聚合模块- Aggregator00:04:24分钟 |
第95节运维架构服务监控Open-Falcon：快速使用介绍00:11:08分钟 |
第96节运维架构服务监控Open-Falcon：Nodata配置00:04:13分钟 |
第97节运维架构服务监控Open-Falcon：集群监控00:03:52分钟 |
第98节运维架构服务监控Open-Falcon：进程端口监控00:06:55分钟 |
第99节运维架构服务监控Open-Falcon：Mysql监控00:08:07分钟 |
第100节运维架构服务监控Open-Falcon：Redis监控00:04:19分钟 |
第101节运维架构服务监控Open-Falcon：Mongodb监控00:04:00分钟 |
第102节运维架构服务监控Open-Falcon：Rabbitmq监控00:02:13分钟 |
第103节运维架构服务监控Open-Falcon：Nginx监控00:03:34分钟 |
第104节运维架构服务监控Open-Falcon：总结00:01:40分钟 |
第105节运维架构服务docker：docker简介00:08:43分钟 |
第106节运维架构服务docker：docker安装00:04:40分钟 |
第107节运维架构服务docker：docker入门00:22:55分钟 |
第108节运维架构服务docker：docker镜像和仓库00:23:35分钟 |

需要资料联系Q 86723638