服务器巡检表-监控指标

发布于:2023-09-16 ⋅ 阅读:(85) ⋅ 点赞:(0)

1、巡检指标

  1. 系统资源
  2. K8S集群
  3. Nginx
  4. JAVA应用
  5. RabbitMQ
  6. Redis
  7. PostgreSQL
  8. Elasticsearch
  9. 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

队列长度

正常:≤ 500
低风险:>500
中风险:>1000
高风险:> 2000

Redis

连接数

正常:<1024
低风险:≥ 1024
中风险:≥ 2048
高风险:≥ 4096

内存使用率

正常:<70%
低风险:≥ 70%
中风险:≥ 85%
高风险:≥ 95%

PostgreSQL

数据库连接数

正常:<1024
低风险:≥ 1024
中风险:≥ 2048
高风险:≥ 4096

磁盘空间使用率

正常:<80%
异常:≥ 80%

Elasticsearch

集群状态

正常:集群status为 green
低风险:集群status为 yellow
高风险:集群status 为 red,出现不可用状态

索引状态

正常:索引status为 open
高风险:索引status为 down

ELK日志系统

日志收集是否正常

正常:应用输出的日志是否与ELK收集的一致
低风险:日志出现不一致,收集不完全

索引状态

正常:索引status为 open
中风险:索引状态status为 down

3、巡检项目-重点配置

nginx

连接数

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

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

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

worker_connections 2000;

注意:

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

grafana监控

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移除了持久空间,引入元空间内存模型

 JVM Statistics Threads/Buffers 

  • Threads:线程数量

  • Memory Allocate/Promote:GC时,年轻代分配的内存空间/GC时,老年代分配的内存空间监控

  • Classes :classes加载情况监控

    • Classes Unloaded:未加载的classes数

    • Classes Loaded:已加载的classes数
  • Direct Buffers: JVM缓冲区已用内存监控
  • Mapped Buffers: 内存映射区内存分配,可忽略

 JVM Statistics GC

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堆和方法区的垃圾收集

参考文章:

使用管理规则 (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

本文含有隐藏内容,请 开通VIP 后查看