服务器状态查询文章列表:

• 1、如何查看linux server链接有积压？
• 2、APP数据泄露接到境外电话 该怎么查服务器
• 3、Kubernetes 日志查询分析实践
• 4、知了堂｜11 个步骤排查linux服务器 是否已经被入侵
• 5、一步到位，服务器监控就是这么简单

如何查看linux server链接有积压？

tcp三次握手：

位码即tcp标志位，有6种标示：

① SYN(synchronous建立联机)；

② ACK(acknowledgement 确认)

③ PSH(push传送)

④ FIN(finish结束)

⑤ RST(reset重置)

⑥ URG(urgent紧急)

查看syc积压

查找积压链接

Sequence number(顺序号码) //Acknowledge number(确认号码)

第一次握手：主机A发送位码为SYN=1，随机产生seq number=1234567的数据包到服务器，主机B由SYN=1知道，A要求建立联机；

第二次握手，主机B收到请求后要确认联机信息，向A发送ack number=(主机A的seq 1)，SYN=1,ACK=1，随机产生seq number=7654321的包；

第三次握手：主机A收到后检查ack number是否正确，即第一次发送的seq number 1，以及位码ACK是否为1，若正确，主机A会再发送ack number=（主机B的seq 1）,ACK=1，主机B收到后确认seq值与ACK=1则连接建立成功。

sequence number：表示的是我方（发送方）这边，这个packet的数据部分的第一位应该在整个data stream中所在的位置。（注意这里使用的是“应该”。因为对于没有数据的传输，如ACK，虽然它有一个seq，但是这次传输在整个data stream中是不占位置的。所以下一个实际有数据的传输，会依旧从上一次发送ACK的数据包的seq开始）

acknowledge number：表示的是期望的对方（接收方）的下一次sequence number是多少。注意，SYN/FIN的传输，虽然没有data，但是会让下一次传输的packet seq增加一，但是， ACK 的传输，不会让下一次的传输 packet seq 加一。

APP数据泄露接到境外电话 该怎么查服务器

上海经济7月份开始陆续恢复，一些在上海做APP项目的客户开始了一系列的营销推广和发展，在众多渠道推广下，用户下载安装APP的同时，一些安全上的漏洞频发，并被高级黑客给盯上，具体的数据泄露攻击的症状为：用户刚注册好的手机号、姓名、身份证号等信息就被泄露，不一会就会收到境外香港的电话推广和网络诈骗，并且有些用户的数据被恶意篡改，导致APP运营平台损失较大，比如一些用户借贷额度被篡改成20w的额度，APP项目方发现问题后立即找了APP安全应急响应服务团队Sinesafe进行了全面的安全应急响应服务，要求尽快找出漏洞问题的原因以及攻击进行溯源。

了解到上述情况后，我们SINE安全立即安排了技术团队对APP项目方的整体运维关联的服务器以及数据库、API接口服务器和落地推广服务器、H5域名进行了信息整理和搜集，并仔细询问了最早发生这种数据被盗取泄露和被篡改的时间，以及带来的损失和管理员人员的第三方安全排查和记录，通过此项目的运维人员的了解，发现服务器都使用的是Linux系统，项目App的架构语言是用Java Vue开发的，API接口使用的也是java开发的，而且运维人员告知程序员，所有的代码修改和调试都要在正式服务器里的测试环境中进行，简单来理解的话，就是说代码开发人员在使用项目中的服务器，去调试和修改代码，通过我们SINE的安全工程师人工审计扫描发现，服务器开放了8099,22,3306,21,80,443,8080等端口，看了下8099端口是用于gitlab系统，此系统是程序员用于修改App代码和同步代码用的，22端口是运维技术和开发人员登录服务器的SSH端口用的，3306是一些Mysql测试数据库和正式数据库用的端口，21端口是程序员上传文件用的Ftp服务端口，80和443是API接口和App项目所用到的对外用户访问的服务，8080是程序员调试app接口用的。

通过我们的前期信息搜集，有些细节一定不能落下，一个小的问题点就会导致出现漏洞，我们尝试了gitlab的默认账户root的项目共享网址，发现root共享的项目中包含了App源代码，我们SINESAFE技术立即打包下载下来到我们自己电脑，深入的分析了java代码里的一些配置文件，发现存在一些阿里云oss的key和密钥信息，我们尝试利用阿里云的oss key和密钥发现,该密钥的权限特别大，可以直接获取到当前阿里云账户下的所有服务器信息，以及所有阿里云服务管理权限。

此时此刻，这个漏洞的危害性实在太大了，可以操控阿里云账户下的所有服务器，正因为这个漏洞，才发生了一开始我们介绍的客户被攻击的症状，为何用户刚注册的信息，立马就被泄露，根源就是这个阿里云oss key和密钥泄露问题，导致黑客可以直接登录服务器去查看数据库，并实时的从数据库中提取用户的手机号和姓名以及身份证号卖给第三方，第三方使用境外香港的电话进行营销推广和网络诈骗，目前已形成了一个产业链，针对这个漏洞我们让客户确认了下上述图片中的服务器是否是客户账户下的，经项目方运维技术确认，的确是他们阿里云账户下的所有服务器，由于运维技术可能对我们SINESAFE的技术势力有点不相信，在进行渗透测试安全服务的一开始就对我们说，知道服务器IP是没用的，你得真正拿到服务器管理员权限才行，经过客户的授权允许后，在不影响正式业务的运行下，我们利用阿里云的key和密钥执行了SHELL命令，并直接进入了服务器使用的是root权限，发现数据库部署在172.18.17.165内网，通过history获取到了用户的一些历史操作命令，其中包括Mysql的数据库账户和密码，本身一开始的时候，我们就发现服务器对外开放了3306端口，我们获得这些数据库账户信息后，立即远程连接了mysql查看到，的确是App的所有数据库内容,截图如下：

此时客户的运维技术，看到我们发的这个截图后，立马改口说：服了，真牛，不愧是专业的网站安全服务商，至此整个溯源以及漏洞发生的问题都已找到，后续客户直接签订了长期的APP渗透测试服务和安全加固服务，通过后续的服务，我们SINE安全技术又发现API接口存在一些越权漏洞，可越权查看用户信息，可导致APP的用户信息被泄露和篡改，比如用户的金额也可以直接通过这个接口漏洞直接修改成任意的金额，APP中的留言反馈功能还存在XSS跨站攻击，导致黑客可以获取到后台的session值和cookie值，可直接登录后台，还有一些接口使用说明，也直接暴露在了前端，由于开发人员没有安全意识，随手就把一些备份文件放到了网站根目录下，通过一些爬虫工具，可获取到了此备份文件，文件里包含很多代码信息，诸如此类的漏洞实在是太多了，如果有遇到此类问题的朋友记得要仔细排查每一个细节和功能，凡是关联数据库的服务器或网站或APP一定都要仔细排查漏洞，因为这都是黑客攻击的入口，入口越多，黑客入侵的成功几率也就越大，如果实在搞不定，又摸不着头脑的话可以找专业的网站漏洞修复服务商来处理数据泄露的问题。

Kubernetes 日志查询分析实践

准备工作

为了完成后续的相关操作，我们需要准备一个 K8s 集群，操作步骤如下：

登陆容器服务控制台。

创建一个标准托管集群（杭州区域），在向导中勾选上【使用 EIP 暴露 API Server】 和【使用日志服务】。

集群创建完毕后，回到集群列表页面，点击【更多->通过 CloudShell 管理集群】。

在 CloudShell 中输入 kubectl get ds -n kube-system，结果中显示的 logtail-ds 即为了实现数据采集所安装的日志服务组件。

打开日志服务控制台，可以看到和 K8s 集群 ID 所对应的 project 也已经创建完毕。

操作截图如下：

图：创建托管集群（步骤 2）

图：打开 CloudShell（步骤 3）

图：在 CloudShell 中查看日志服务组件（步骤 4）

图：打开日志服务控制台，查看 project（步骤 5）

1. 数据采集

在 K8s 环境下，容器日志数据从大体上分为两类：容器标准输出和容器内文本文件，前者是容器特有的一种日志存在形式，后者和传统的文本文件日志类似，只是文件存放在各个容器内部，相互之间隔离。下面我们将介绍如何对这两种类型的日志进行采集。

1.1. Mock 数据

我们将使用如下两个 YAML 文件分别生成标准输出和容器内文件两种形式的 mock 数据。
容器标准输出

# 创建两个 pod 来生成 mock 数据apiVersion: batch/v1kind: Jobmetadata: name: nginx-stdout-log-demo-1 namespace: nginx-stdoutspec: template: metadata: name: nginx-stdout-log-demo-1 spec: containers: - name: nginx-stdout-log-demo-1 image: registry.cn-hangzhou.aliyuncs.com/log-service/docker-log-test:latest command: ["/bin/mock_log"] args: ["--stderr=false", "--stdout=true", "--log-type=nginx", "--total-count=100000000", "--logs-per-sec=5"] restartPolicy: Never---apiVersion: batch/v1kind: Jobmetadata: name: nginx-stdout-log-demo-2 namespace: nginx-stdoutspec: template: metadata: name: nginx-stdout-log-demo-2 spec: containers: - name: nginx-stdout-log-demo-2 image: registry.cn-hangzhou.aliyuncs.com/log-service/docker-log-test:latest command: ["/bin/mock_log"] args: ["--stderr=false", "--stdout=true", "--log-type=nginx", "--total-count=100000000", "--logs-per-sec=5"] restartPolicy: Never

容器内文本文件（/var/log/access.log）

apiVersion: batch/v1kind: Jobmetadata: name: nginx-file-log-demo namespace: nginx-filespec: template: metadata: name: nginx-file-log-demo spec: restartPolicy: Never containers: - name: nginx-file-log-demo image: registry.cn-hangzhou.aliyuncs.com/log-service/docker-log-test:latest command: ["/bin/mock_log"] args: ["--log-type=nginx", "--stdout=false", "--stderr=false", "--path=/var/log/access.log", "--total-count=100000000", "--logs-per-sec=5"]

操作步骤：

打开 CloudShell，参考准备工作中的步骤 3。

在集群中应用上面提及的两个 YAML（Github）。

执行 kubectl get pods 查看负责生成日志的几个 Pod。

查看两个 Pod 生成日志的情况（根据实际情况替换命令中的 pod 名）

标准输出：执行 kubectl logs -n nginx-stdout --tail=10 nginx-stdout-log-demo-1-7kvwx。

容器内文件：执行 kubectl exec -n nginx-file nginx-file-log-demo-7frsp -- bash -c "tail /var/log/access.log"。

$ kubectl create namespace nginx-stdout$ kubectl create -f https://raw.githubusercontent.com/goclis/kubernetes-mock-log/master/pod_nginx_stdout.yaml$ kubectl create namespace nginx-file$ kubectl create -f https://raw.githubusercontent.com/goclis/kubernetes-mock-log/master/pod_nginx_file.yaml

命令：生成 mock 数据（步骤 2）

$ kubectl get pods -ANAMESPACE NAME READY STATUS RESTARTS AGEnginx-file nginx-file-log-demo-7frsp 1/1 Running 0 2m9snginx-stdout nginx-stdout-log-demo-1-7kvwx 1/1 Running 0 2m12snginx-stdout nginx-stdout-log-demo-2-4x7vw 1/1 Running 0 2m12s

命令：查看日志服务组件（步骤 3）

1.2. 采集标准输出
操作步骤：

登陆日志服务控制台，点击进入集群 ID 对应的 project。

创建一个 logstore 用于存储标准输出日志，比如 k8s-stdout。

在 logstore 中新增 Logtail 配置，类型为【Docker 标准输出】，选择现有机器组中前缀为 k8s-group 的机器组。

在【数据源设置】页面，填写【配置名称】和【插件配置】。
操作截图如下：

图：创建 Logtail 采集配置

图：选择 Docker 标准输出配置

图：选择现有机器组

图：选择 k8s-group 开头的机器组

图：填写 Docker 标准输出采集配置内容
以下为两个可选的采集配置（使用 IncludeLabel 分别采集两个 namespace 下的数据，参考）：
配置：采集 namespace nginx-stdout

{ "inputs": [ { "detail": { "IncludeLabel": { "io.kubernetes.pod.namespace": "nginx-stdout" }, "ExcludeLabel": {} }, "type": "service_docker_stdout" } ]}

配置：采集 namespace kube-system

{ "inputs": [ { "detail": { "IncludeLabel": { "io.kubernetes.pod.namespace": "kube-system" }, "ExcludeLabel": {} }, "type": "service_docker_stdout" } ]}

1.3. 采集容器内文件

操作步骤：

登陆日志服务控制台，点击进入集群 ID 对应的 project。

创建一个 logstore 用于存储容器内文件日志，比如 nginx-file。

在 logstore 中新增 Logtail 配置，类型为【Docker 文件】，选择现有机器组中前缀为 k8s-group 的机器组。

在【数据源设置】页面，填写【配置名称】和具体的配置信息（采集文件的路径、Label 等），示例为采集 /var/log/access.log。

图：选择 Docker 文件配置

图：填写 Docker 文件采集配置内容

2. 日志查询

2.1. 设置字段索引 & 开启日志聚类

为了使用日志服务提供的查询、日志聚类等功能，首先需要对索引进行配置。操作步骤如下：

登陆日志服务控制台，进入集群 ID 对应的 project，从左侧导航栏的 logstore 中选择先前创建的 k8s-stdout，展开点击查询分析进行查询控制台。

点击右上角的【查询分析属性 -> 设置索引】。

在弹出窗口中勾选上【日志聚类】，然后点击【自动生成索引】。

点击【确定】保存索引。
操作截图如下：

图：进入 logstore 查询分析界面

图：索引配置入口

图：开启日志聚类

图：自动生成字段索引

2.2. 基本查询

在配置完索引后，我们可以在查询输入框中使用查询语句可以快速地筛选日志，以下是一些示例：

查看命名空间 nginx-stdout 下的日志：_namespace_:nginx-stdout

查看其他命名空间下的日志：not _namespace_: nginx-stdout

查看命名空间 kube-system 下指定 pod 的日志：_namespace_: kube-system and _pod_name_: xxxxxx
在实际查询过程中，我们可以通过直接点击查询结果中的内容来快速填充查询语句，截图如下。

图：点击查询结果中的内容

图：查询语句快速填充

2.3. 日志聚类 & 上下文查询 & LiveTail

在排查问题时，我们一般会组合使用日志聚类、上下文查询以及 LiveTail 这三个功能来辅助问题排查。

首先，利用日志聚类来快速地查看日志模式，发现其中怀疑的问题日志。

接着，利用上下文查询，来跟踪问题日志前后的日志，辅助我们定位问题。

最后，在根据问题做出调整后，使用 LiveTail 来查看最新日志的变化情况，确认是否达到修改预期。
以下假设应用 pod 是 metrics-server，我们可以借助这套方法来对它进行分析：

查询输入框输入 metrics-server，点击查询分析，可以看到所有范围（默认为最近 15 分钟）的全部日志，一般来说会很多。

由于日志较多，为了发现日志模式，我们切换到【日志聚类】标签页，可以看到这段时间内的日志在模式上分为有限的几类。我们可以拖动 pattern 进度条选择粒度，对于特定 pattern，点击【日志数量】来查看具体日志。

悬停到日志时间左侧的图标，点击弹出菜单中的【上下文浏览】，在弹出页面中同样可以进行筛选，并点击【更早】、【更新】来查看指定日志的上文和下文。

悬停到日志时间左侧的图标，点击弹出菜单中的【LiveTail】。

图：日志聚类结果

图：上下文查询入口

图：上下文查询

图：LiveTail

3. Ingress & Audit 方案

除了 K8s 环境下基本的日志采集、查询分析功能以外，我们还针对 K8s 环境下的 Ingress、审计（Audit）日志提供了方案。

3.1. Ingress

为了在集群中部署 Ingress 方案，只需要在集群已安装日志服务组件的基础上，应用如下的 YAML 文件即可：

apiVersion: log.alibabacloud.com/v1alpha1kind: AliyunLogConfigmetadata: # your config name, must be unique in you k8s cluster name: k8s-nginx-ingressspec: # logstore name to upload log logstore: nginx-ingress # product code, only for k8s nginx ingress productCode: k8s-nginx-ingress # logtail config detail logtailConfig: inputType: plugin # logtail config name, should be same with [metadata.name] configName: k8s-nginx-ingress inputDetail: plugin: inputs: - type: service_docker_stdout detail: IncludeLabel: io.kubernetes.container.name: nginx-ingress-controller Stderr: false Stdout: true processors: - type: processor_regex detail: KeepSource: false Keys: - client_ip - x_forward_for - remote_user - time - method - url - version - status - body_bytes_sent - http_referer - http_user_agent - request_length - request_time - proxy_upstream_name - upstream_addr - upstream_response_length - upstream_response_time - upstream_status - req_id - host NoKeyError: true NoMatchError: true Regex: ^(S )s-s[([^]] )]s-s(S )s[(S )sS s"(w )s(S )s([^"] )"s(d )s(d )s"([^"]*)"s"([^"]*)"s(S )s(S ) s[([^]]*)]s(S )s(S )s(S )s(S )s(S )s*(S*).* SourceKey: content

该 YAML 会在集群对应的日志服务 project 中创建一个名为 nginx-ingress 的 logstore，存储相关的日志，并且会对应地创建一系列基于 Ingress 日志所构建的详细报表，辅助我们分析 Ingress 日志。

图：Ingress 概览
更多信息可以阅读《Kubernetes Ingress 日志分析入门》。

审计（Audit）

目前，审计方案会在集群创建时自动应用，相关的日志会存储在日志服务 project 下以 audit- 为前缀的 logstore 中，其中包含针对集群操作的详细日志，比如资源（Pod、Deploy）的创建与删除、集群的扩容记录等。类似地，审计方案同样提供了一系列详细报表。

双12来袭！500元淘宝红包、iPhone11等你拿。

https://www.aliyun.com/1212/2019/home?utm_content=g_1000092611

作者：抱泽

本文为云栖社区原创内容，未经允许不得转载。

知了堂｜11 个步骤排查linux服务器 是否已经被入侵

随着开源产品的越来越盛行，作为一个Linux运维工程师，能够清晰地鉴别异常机器是否已经被入侵了显得至关重要，个人结合自己的工作经历，整理了几种常见的机器被黑情况供参考：

背景信息：以下情况是在CentOS 6.9的系统中查看的，其它Linux发行版类似。

1入侵者可能会删除机器的日志信息

可以查看日志信息是否还存在或者是否被清空，相关命令示例：

2入侵者可能创建一个新的存放用户名及密码文件

可以查看/etc/passwd及/etc/shadow文件，相关命令示例：

3入侵者可能修改用户名及密码文件

可以查看/etc/passwd及/etc/shadow文件内容进行鉴别，相关命令示例：

4查看机器最近成功登陆的事件和最后一次不成功的登陆事件

对应日志“/var/log/lastlog”，相关命令示例：

5查看机器当前登录的全部用户

对应日志文件“/var/run/utmp”，相关命令示例：

6查看机器创建以来登陆过的用户

对应日志文件“/var/log/wtmp”，相关命令示例：

7查看机器所有用户的连接时间（小时）

对应日志文件“/var/log/wtmp”，相关命令示例：

8如果发现机器产生了异常流量

可以使用命令“tcpdump”抓取网络包查看流量情况或者使用工具”iperf”查看流量情况

9可以查看/var/log/secure日志文件

尝试发现入侵者的信息，相关命令示例：

10查询异常进程所对应的执行脚本文件

a.top命令查看异常进程对应的PID

b.在虚拟文件系统目录查找该进程的可执行文件

11如果确认机器已被入侵，重要文件已被删除，可以尝试找回被删除的文件Note:

1、当进程打开了某个文件时，只要该进程保持打开该文件，即使将其删除，它依然存在于磁盘中。这意味着，进程并不知道文件已经被删除，它仍然可以向打开该文件时提供给它的文件描述符进行读取和写入。除了该进程之外，这个文件是不可见的，因为已经删除了其相应的目录索引节点。

2、在/proc 目录下，其中包含了反映内核和进程树的各种文件。/proc目录挂载的是在内存中所映射的一块区域，所以这些文件和目录并不存在于磁盘中，因此当我们对这些文件进行读取和写入时，实际上是在从内存中获取相关信息。大多数与 lsof 相关的信息都存储于以进程的 PID 命名的目录中，即 /proc/1234 中包含的是 PID 为 1234 的进程的信息。每个进程目录中存在着各种文件，它们可以使得应用程序简单地了解进程的内存空间、文件描述符列表、指向磁盘上的文件的符号链接和其他系统信息。lsof 程序使用该信息和其他关于内核内部状态的信息来产生其输出。所以lsof 可以显示进程的文件描述符和相关的文件名等信息。也就是我们通过访问进程的文件描述符可以找到该文件的相关信息。

3、当系统中的某个文件被意外地删除了，只要这个时候系统中还有进程正在访问该文件，那么我们就可以通过lsof从/proc目录下恢复该文件的内容。

假设入侵者将/var/log/secure文件删除掉了，尝试将/var/log/secure文件恢复的方法可以参考如下：

a.查看/var/log/secure文件，发现已经没有该文件

b.使用lsof命令查看当前是否有进程打开/var/log/secure，

c.从上面的信息可以看到 PID 1264（rsyslogd）打开文件的文件描述符为4。同时还可以看到/var/log/ secure已经标记为被删除了。因此我们可以在/proc/1264/fd/4（fd下的每个以数字命名的文件表示进程对应的文件描述符）中查看相应的信息，如下：

d.从上面的信息可以看出，查看/proc/1264/fd/4就可以得到所要恢复的数据。如果可以通过文件描述符查看相应的数据，那么就可以使用I/O重定向将其重定向到文件中，如:

e.再次查看/var/log/secure，发现该文件已经存在。对于许多应用程序，尤其是日志文件和数据库，这种恢复删除文件的方法非常有用。

一步到位，服务器监控就是这么简单

对于运维的日常工作来说，服务器监控是必须且最基础的一项内容。在企业基础设施运维过程中，管理员必须能够掌握所有服务器的运行状况，以便及时发现问题，尽可能减少故障的发生。通常我们会借助一些监控的软件来获取每个服务器的基础指标并进行集中的查看、分析、监控。

市面上开源、收费的服务器监控系统非常多，例如老牌的zabbix、nagios、NewRelic、CollectD等，近期开始流行的Telegraf、Prometheus。各类系统都有其出彩的点，例如Zabbix强大的生态、NewRelic的服务、Prometheus的云原生友好等。服务器监控相对中间件、业务监控更加基础，关注点主要集中在监控的易用性、稳定性、实时性、报警丰富度、报表使用便捷度等。

本期为大家介绍如何使用阿里云SLS来快速构建一套完整的服务器/主机基础指标实时监控方案。

SLS时序存储简介

SLS的日志存储引擎在2016年对外发布，目前承接阿里内部以及众多企业的日志数据存储，每天有数十PB的日志类数据写入。其中有很大一部分属于时序类数据或者用来计算时序指标，为了让用户能够一站式完成整个DevOps生命周期的数据接入、清洗、加工、提取、存储、可视化、监控、问题分析等过程，我们专门推出了时序存储的功能，与日志存储一道为大家解决各类机器数据的存储问题。

SLS时序存储从设计之初就是为了解决阿里内部与众多头部企业客户的时序存储需求，并借助于阿里内部多年的技术积累，使之可以适应绝大部分企业级时序监控/分析诉求。SLS时序存储的特点主要有：

丰富上下游：数据接入上SLS支持众多采集方式，包括各类开源Agent以及阿里云内部的监控数据通道；同时存储的时序数据支持对接各类的流计算、离线计算引擎，数据完全开放；

高性能：SLS存储计算分离架构充分发挥集群能力，尤其在大量数据下端对端的速度提升显著；

免运维：SLS的时序存储完全是服务化，无需用户自己去运维实例，而且所有数据都是3副本高可靠存储，不用担心数据的可靠性问题；

开源友好：SLS的时序存储原生支持Prometheus的写入和查询，并支持SQL92的分析方法，可以原生对接Grafana等可视化方案；

智能：SLS提供了各种AIOps算法，例如多周期估算、预测、异常检测、时序分类等各类时序算法，可以基于这些算法快速构建适应于公司业务的智能报警、诊断平台。

服务器监控方案概述

SLS的主机监控方案非常简单，只需要安装一个Logtail就可以采集各个主机的基础指标，服务端都是云化，无需运维，默认SLS提供了可视化的仪表盘，也可以通过Grafana来进行更加专业的可视化。

目前Logtail采集了主机常用的基础指标，包括CPU、内存、网络、磁盘等，其中对较为关键的指标都做了可视化，便于直接查看。

数据接入

数据接入的流程非常简单，只需要在SLS控制台上操作即可完成（对于非阿里云的服务器，需要在服务器上额外执行2条命令），具体接入的方法可参见：采集主机监控数据。

接入过程中最核心的就是给每台主机的Logtail增加一个采集配置，Logtail的采集配置可以完全云化管理，无需登录每台服务器手动配置。

{ "inputs": [ { "detail": { "IntervalMs": 30000 }, "type": "metric_system_v2" } ]}

可视化

在运维可视化领域Grafana是当前大家接受度最高的可视化方案，SLS为主机监控专门增加了2个Dashboard模板，包括一张集群级别的监控大盘和单机的详细指标大盘。这些大盘可以一键导入到Grafana中。

Grafana的配置流程如下：

在Grafana中把SLS的时序库作为Prometheus的数据源，设置方式可参考：Grafana可视化配置。

导入Grafana模板市场中的SLS模板：主机监控集群指标、主机监控单机指标。

监控数据分析与告警配置

作为一个合格的运维人员，仅仅配置完炫酷的监控仪表盘还不够，还需要对集群设置好足够的告警项并能在需要排查问题的时候利用监控数据分析的语法快速定位问题。这些本质上都是对集群的指标进行一些计算和统计。

SLS时序数据支持SQL、PromQL以及SQL PromQL等多种查询方式，PromQL查询语言相对更加简洁，SQL能够实现的语义更加强大。而主机的监控数据相对比较简单，建议使用PromQL或SQL PromQL的方式。

下面介绍几个在告警、分析中经常会用到的几个统计方式：

计算所有机器的某个指标平均值，例如平均CPU

查找某个指标最高的N台机器，比如查找内存占用最高的5台机器

查找某个指标超过X的机器，比如找到1分钟网络流量超过10M的机器

计算某台机器的某个指标相对某个时间点的变化，比如计算某台机器磁盘使用率相比1天前的变化

这些用PromQL实现起来非常容易，可以在Grafana的Explore页面直接调试：

平均CPU： avg(cpu_util)

查找内存占用最高的5台机器：topk(5, mem_util)

找出1分钟网络流量超过10M的机器：(sum_over_time(net_in[1m]) sum_over_time(net_out[1m])) > (10*1024*1024)

计算某台机器磁盘使用率相比1天前的变化：disk_util{hostname="iZ2ze06ibdlxtgebgtu4xdZ"} - disk_util{hostname="iZ2ze06ibdlxtgebgtu4xdZ"} offset 1d

而告警也可以直接在Grafana上配置，可以在集群监控的Dashboard上直接配置告警，例如下面是配置CPU集群平均CPU超限的告警，告警规则是：每分钟计算最近5分钟内的集群CPU平均利用率，如果连续5分钟超过80%则触发告警。

总结

服务的基础指标监控是我们监控运维领域最基础的工作之一，构造公司IT的全方位监控还有很多工作要做，例如中间件监控、云产品监控、应用监控、业务监控等，而这些利用SLS的日志和时序存储功能都可以很容易的实现，其他相关的实现我们会在后续文章中给大家呈现。

大家在使用SLS中遇到的任何问题，请加钉钉群，我们有专门的日志女仆24小时在线答疑，还有火锅哥和烧烤哥专业支持！~ SLS微信公众号定期会发布各类日志、监控领域的技术分享文章并定期举行抽奖，欢迎小伙伴们关注~

另外欢迎对大数据、分布式、机器学习等有兴趣的同学加入，转岗、内推，来者不拒，请用简历狠狠的砸我，联系邮箱 davidzhang.zc@alibaba-inc.com ！~