服务器巡检表-监控指标-Toy模板网

这篇具有很好参考价值的文章主要介绍了服务器巡检表-监控指标。希望对大家有所帮助。如果存在错误或未考虑完全的地方，请大家不吝赐教，您也可以点击"举报违法"按钮提交疑问。

1、巡检指标

系统资源
K8S集群
Nginx
JAVA应用
RabbitMQ
Redis
PostgreSQL
Elasticsearch
ELK日志系统

2、巡检项

检查项目	检查指标	检查标准
系统资源	CPU 使用率	正常：＜70% 低风险：≥ 70% 中风险：≥ 85% 高风险：≥ 95%
	内存使用率	正常：＜70% 低风险：≥ 70% 中风险：≥ 85% 高风险：≥ 95%
	磁盘使用率	正常：＜80% 异常：≥ 80%
	系统负载	正常：＜70% 低风险：≥ 70% 中风险：≥ 85% 高风险：≥ 95%
	日志文件是否有异常	正常：日志中风险无 ERROR报错低风险：日志中风险少量ERROR报错且不影响业务中风险：日志出现5%以上的ERROR报错且影响非核心业务高风险：日志中风险出现10%以上的ERROR报错且已经影响核心业务或者集群状态
	系统服务是否正常运行	正常：没有Failed和Down状态的服务低风险：有Failed和Down状态的服务但不影响业务中风险：有Failed和Down状态的服务且影响非核心业务高风险：有Failed和Down状态的服务已经影响部分业务或者集群状态
	检查系统是否有波峰波谷	正常：指标线没有明显的大波动低风险：少数波峰波谷，一天2-5次且持续时间不长中风险：频繁波峰波谷，一天≥5次且持续时间不长高风险：一直处于波峰波谷，无法提供服务
K8S集群	节点状态	正常：节点状态为 Ready 低风险：出现1台状态为NotReady 中风险：出现2台状态为NotReady 高风险：大于2台状态为NotReady
	Pod 状态	正常：所有 Pod 状态为 Running 低风险：Pod状态为Running但出现重启的情况中风险：非核心业务Pod出现不可用状态高风险：核心业务Pod不可用
	持久卷状态	正常：所有持久卷状态均为 Bound 低风险：持久卷出现异常但不影响业务中风险：持久卷出现异常且影响非核心业务高风险：所有持久卷不可用且核心业务受影响
	节点资源使用情况	正常：所有节点资源使用率均低风险于 70% 低风险：所有节点资源使用率大于70%且不影响业务中风险：所有节点资源使用率大于80%且影响非核心业务高风险：所有节点资源使用率大于95%且影响核心业务
	节点间通信是否正常	正常：节点间通信延迟低风险于 50ms，无丢包低风险：节点间通信延迟大于 50ms但不影响业务中风险：节点间通信延迟大于 100ms出现丢包，且影响非核心业务高风险：节点间通信延迟大于 150ms出现丢包，且影响核心业务
Nginx	端口监听	正常：监听端口包含nginx配置文件监听的端口低风险：监听端口不包含且不影响业务中风险：监听端口不包含且影响非核心业务高风险：监听端口不包含且影响核心业务
	访问正常	正常：响应状态码为 200 低风险：出现非200但不影响业务中风险：出现非200影响非核心业务高风险：出现非200且影响核心业务
	日志记录	正常：日志中风险无 ERROR报错低风险：日志中风险少量ERROR报错，不影响使用中风险：日志出现2%的ERROR报错，影响非重要业务高风险：日志中风险出现10%以上的ERROR报错且已经影响部分重要业务
	连接数	正常：＜1024 低风险：≥ 1024 中风险：≥ 2048 高风险：≥ 4096
JAVA应用	内存泄漏警报	堆内存使用率超过阈值1且持续时间超过阈值2。举例：堆内存使用率超过80%并且持续10分钟以上，则会触发该警报。具体配置可以根据服务器环境自定义。
	GC 暂停时间警报	GC暂停时间超过阈值1并且持续阈值2 举例：GC暂停时间超过该阈值并且持续1分钟以上，则会触发该警报。具体配置可以根据服务器环境自定义。
	程序运行状态	正常：服务正在运行低风险：服务实例数＜2但不影响业务中风险：服务不可用数＜2影响非核心业务高风险：应用程序无法正常运行，核心服务不可用
	检查Pod是否有波峰波谷	正常：指标线没有明显的大波动低风险：少数波峰波谷，一天2-5次且持续时间不长中风险：频繁波峰波谷，一天≥5次且持续时间不长高风险：一直处于波峰波谷，无法征程提供服务
RabbitMQ	节点状态	正常：所有节点状态为 running 中风险：出现一个节点状态为down 高风险：所有节点状态为down
RabbitMQ	队列长度	正常：≤ 500 低风险：＞500 中风险：＞1000 高风险：＞ 2000
Redis	连接数	正常：＜1024 低风险：≥ 1024 中风险：≥ 2048 高风险：≥ 4096
Redis	内存使用率	正常：＜70% 低风险：≥ 70% 中风险：≥ 85% 高风险：≥ 95%
PostgreSQL	数据库连接数	正常：＜1024 低风险：≥ 1024 中风险：≥ 2048 高风险：≥ 4096
PostgreSQL	磁盘空间使用率	正常：＜80% 异常：≥ 80%
Elasticsearch	集群状态	正常：集群status为 green 低风险：集群status为 yellow 高风险：集群status 为 red，出现不可用状态
Elasticsearch	索引状态	正常：索引status为 open 高风险：索引status为 down
ELK日志系统	日志收集是否正常	正常：应用输出的日志是否与ELK收集的一致低风险：日志出现不一致，收集不完全
ELK日志系统	索引状态	正常：索引status为 open 中风险：索引状态status为 down

3、巡检项目-重点配置

nginx

连接数

Nginx默认情况下并没有限制连接数，它会根据系统的资源情况进行调整。然而，如果服务器的资源有限，或者遇到大量并发请求，可能会导致连接数过高，从而影响服务器的性能和稳定性。

你可以通过参数worker_connections来调整Nginx的连接数，这个参数用于限制每个worker进程可以同时处理的连接数。默认值通常是1024，但可以根据服务器的实际情况进行调整。

例如，如果你想将每个worker进程的连接数增加到2000，可以在Nginx配置文件中添加以下行：

worker_connections 2000;

注意：

过大的连接数可能会导致资源过度消耗和性能下降，而过小的连接数可能会导致连接被拒绝或处理不足。根据您的服务器资源和需求进行适当的调整。

grafana监控

服务器巡检表-监控指标,架构设计,k8s,运维,服务器,运维

redis

设置Redis最大内存

为什么要设置最大内存？

redis是一个内存数据库，它将所有数据存储在内存中，因此其内存使用量直接决定了性能和可靠性。如果Redis使用的内存超过了系统所能提供的内存大小，就会触发操作系统的内存换页机制，从而导致性能下降。

为了避免这种情况的发生，我们需要在Redis中设置最大内存限制。当Redis的内存使用量接近最大内存限制时，Redis会触发内存淘汰机制，将一些不常访问的数据从内存中淘汰出去，以释放内存空间。

如何设置最大内存？

Redis提供了一个配置项maxmemory用于设置最大内存限制。可以通过修改Redis的配置文件redis.conf来设置该项。

# 设置最大内存为1GB
maxmemory 1gb

上述配置设置了最大内存为1GB。除了使用gb表示G字节外，还可以使用mb表示M字节，kb表示K字节。也可以直接使用字节数，例如maxmemory 1073741824表示1GB。

java应用

prothums配置

内存泄漏警报

1、prom-jmx.yml：

scrape_configs:
  - job_name: 'prometheus-jmx-scrape'
    jmx_url: 'service:jmx:rmi:///jndi/rmi://localhost:9010/jmxrmi'
    jmx_user: 'admin'
    jmx_password: 'password'
    static_configs:
      - targets: ['localhost']
    metrics_path: '/metrics'
    timeout: 30s

2、prom-alert-rules.yml：

rule_files:
  - 'prom-alert-rules.yml'
alerting:
  alertmanagers:
    - static_configs:
        - targets: ['alertmanager@localhost:9093']

在prom-alert-rules.yml文件中定义内存泄漏的警报规则：

groups:
- name: example
  rules:
  - alert: MemoryLeak
    expr: heap_used_percent > 80
    for: 10m
    labels:
      severity: warning
    annotations:
      message: High heap memory usage ({[label]}%) detected. Leak suspected, action required.

上述配置假设您的警报管理系统（如Alertmanager）在本地主机的9093端口上运行，并且您有一个运行在本地主机的Prometheus实例。警报规则定义了一个内存泄漏警报，如果堆内存使用率超过80%并且持续10分钟以上，则会触发该警报。

请注意，这只是一个示例配置，您需要根据您的实际环境和需求进行适当的修改。

GC 暂停时间警报

1、prom-jmx.yml

scrape_configs:
  - job_name: 'prometheus-jmx-scrape'
    jmx_url: 'service:jmx:rmi:///jndi/rmi://localhost:9010/jmxrmi'
    jmx_user: 'admin'
    jmx_password: 'password'
    static_configs:
      - targets: ['localhost']
    metrics_path: '/metrics'
    timeout: 30s

2、prom-alert-rules.yml

rule_files:
  - 'prom-alert-rules.yml'
alerting:
  alertmanagers:
    - static_configs:
        - targets: ['alertmanager@localhost:9093']

在prom-alert-rules.yml文件中定义GC暂停时间超过某个阈值的警报规则：

groups:
- name: example
  rules:
  - alert: GCPauseWarning
    expr: jvm_gc_pause_seconds{type=" CMS"} > 10 or jvm_gc_pause_seconds{type=" G1"} > 10
    for: 1m
    labels:
      severity: warning
    annotations:
      message: GC Pause Warning (instance{{$labels.instance}})
      summary: GC Pause time exceeded 10 seconds in the last minute. Leak suspected, action required.

上述配置假设您的警报管理系统（如Alertmanager）在本地主机的9093端口上运行，并且您有一个运行在本地主机的Prometheus实例。警报规则定义了一个GC暂停时间超过10秒的警报，无论使用的是CMS还是G1垃圾回收器。如果暂停时间超过该阈值并且持续1分钟以上，则会触发该警报。

请注意，这只是一个示例配置，您需要根据您的实际环境和需求进行适当的修改。

grafana监控-jvm监控

JVM Statistics-Heaps

G1 Eden Space (heap)：新生代Eden 区堆内存使用情况，能够直观反应应用new 对象内存分配情况
- Used:jvm.memory.max JVM最大内存
- committed:jvm.memory.committed JVM可用内存是展示并监控堆内存和Metaspace 重要
- used:jvm.memory.used JVM已用内存
G1 Old Gen (heap)：老年代代堆内存使用情况，能够直观反应应用大对象、长生命周期对象内存分配情况
- Used:jvm.memory.max JVM最大内存
- committed:jvm.memory.committed JVM可用内存是展示并监控堆内存和Metaspace 重要
- used:jvm.memory.used JVM已用内存
G1 Survivor Space (heap)：新生代Survivor 区堆内存使用情况，对象年代提升情况，通过对该区的内存使用监控，可以防止应用出现“过早提升”问题
- Used:jvm.memory.max JVM最大内存
- committed:jvm.memory.committed JVM可用内存是展示并监控堆内存和Metaspace 重要
- used:jvm.memory.used JVM已用内存
Code Cache (non-heap):JVM生成的native code存放的内存空间称之为Code Cache；JIT编译、JNI等都会编译代码到native code，其中JIT生成的native code占用了Code Cache的绝大部分空间
Compressed Class Space (non-heap): 类指针压缩空间（Compressed Class Pointer Space）内存分配。
Metaspace (non-heap)：监控展示了Java元数据内存分配情况。元空间，Java8移除了持久空间，引入元空间内存模型

服务器巡检表-监控指标,架构设计,k8s,运维,服务器,运维

JVM Statistics Threads/Buffers

服务器巡检表-监控指标,架构设计,k8s,运维,服务器,运维

Threads：线程数量
Memory Allocate/Promote：GC时，年轻代分配的内存空间/GC时，老年代分配的内存空间监控
Classes ：classes加载情况监控
- Classes Unloaded：未加载的classes数
- Classes Loaded：已加载的classes数
Direct Buffers: JVM缓冲区已用内存监控
Mapped Buffers: 内存映射区内存分配，可忽略

JVM Statistics GC

服务器巡检表-监控指标,架构设计,k8s,运维,服务器,运维

JVM内存垃圾回收统计分析，对jvm进行gc的时间、数量、jvm停顿时间的监控

GC Count：GC次数统计。
GC Stop the World Duration：GC全局停顿时间统计。

JVM常见的GC包括三种：Minor GC，Major GC与Full GC

新生代收集(Minor GC/Young GC):只是新生代的垃圾收集
老年代收集(Major GC/Old GC):只是老年代的垃圾收集
整堆收集(Full GC)：收集整个Java堆和方法区的垃圾收集

4、报警等级

技术监控报警等级是根据系统或设备的运行状况、故障严重程度以及可能对业务造成的影响来划分的。不同的场景和领域可能会有不同的报警分级标准，以下是一般情况下常见的技术监控报警级别分类：

五级-一般警告（Informational / Notice）：
- 表示系统的某些参数超出正常范围，但尚未对系统运行产生严重影响，或者是非关键信息的通知。
四级-轻度警告（Warning / Minor）：
- 系统出现潜在问题，虽然目前还在可控范围内，但如果继续恶化，可能会导致服务降级或影响用户体验。
三级-中度警告（Major）：
- 设备或系统的重要指标异常，已经明显影响了部分功能的正常执行，需要立即关注并采取措施。
二级-严重警告（Critical）：
- 严重的故障或性能瓶颈，可能导致整个系统或重要服务不可用，必须立即进行处理以防止宕机或其他重大损失。
一级-灾难性警告（Disaster / Emergency）：
- 发生了极端情况，如大规模数据丢失、主系统崩溃等，要求立即启动应急预案，确保核心业务能够迅速恢复或转移至备份环境。

在实际应用中，例如电力系统、煤矿安全监控系统、IT运维监控软件等都有各自特定的报警分级体系，以便于快速识别和响应不同级别的告警事件。同时，这些等级也通常会关联相应的处理流程和响应速度要求。

参考文章：

使用管理规则 (Sun GlassFish Enterprise Manager Performance Advisor 1.0 安装与快速入门指南)

https://www.toutiao.com/article/7273039473196368403/?app=news_article&timestamp=1693872382&use_new_style=1&req_id=20230905080622B7416A0C5BBBDC44F69A&group_id=7273039473196368403&wxshare_count=1&tt_from=weixin&utm_source=weixin&utm_medium=toutiao_android&utm_campaign=client_share&share_token=da41c642-f2d0-4f11-8833-3c0515f6e96d&source=m_redirect文章来源地址https://www.toymoban.com/news/detail-702355.html

到了这里，关于服务器巡检表-监控指标的文章就介绍完了。如果您还想了解更多内容，请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章，希望大家以后多多支持TOY模板网！