开篇导读你是否在信创环境中搭建监控系统时发现国外工具不兼容或性能下降网上搜到的监控方案要么只讲工具安装不讲指标设计要么直接给配置却不解释信创环境特点。本文将从信创运维的核心挑战出发深度解析华为蓝鲸、嘉为蓝鲸等国产运维平台的特点包含监控指标设计和告警策略给你一个完整的信创运维方案。信创运维就像给国产车做保养——不能直接用进口车的保养手册得用国产配件监控工具还得了解国产车的脾气性能特点。今天咱们就来聊聊怎么在信创环境下从黑盒走向全链路可观测。一、信创运维的核心挑战为什么不能用ZabbixPrometheus直接上很多运维老哥刚接触信创环境时第一反应是“我Zabbix用得贼6直接部署不就完了”结果上线第一天就翻车架构不兼容ARM架构的鲲鹏/飞腾芯片Zabbix Agent编译不过去依赖缺失某些监控插件依赖的库在统信UOS/麒麟OS上找不到性能差异同样的监控脚本在x86上跑得好好的ARM上CPU占用飙升安全合规某些国外监控工具内置了外联功能安全审计过不了 真实案例某金融客户直接把PrometheusGrafana搬到鲲鹏服务器上结果Grafana的某些插件在ARM架构下渲染异常监控大屏直接花屏。后来改用国产监控平台才解决。所以信创运维的第一步是认清现实放弃幻想拥抱国产化方案。二、信创运维监控全景图从硬件到业务的全栈覆盖┌─────────────────────────────────────────────────────────────────────────┐ │ 信创运维监控体系架构 │ ├─────────────────────────────────────────────────────────────────────────┤ │ │ │ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │ │ │ 硬件监控层 │ │ 软件监控层 │ │ 业务监控层 │ │ 用户体验层 │ │ │ │ (物理世界) │ │ (系统世界) │ │ (应用世界) │ │ (用户世界) │ │ │ └──────┬──────┘ └──────┬──────┘ └──────┬──────┘ └──────┬──────┘ │ │ │ │ │ │ │ │ ┌──────┴──────┐ ┌──────┴──────┐ ┌──────┴──────┐ ┌──────┴──────┐ │ │ │ • CPU/内存 │ │ • OS监控 │ │ • 应用性能 │ │ • 页面加载 │ │ │ │ • 磁盘/IO │ │ • 中间件 │ │ • 业务指标 │ │ • 接口响应 │ │ │ │ • 网络吞吐 │ │ • 数据库 │ │ • 链路追踪 │ │ • 用户行为 │ │ │ │ • 温度/电源 │ │ • 容器/K8s │ │ • 日志分析 │ │ • 满意度 │ │ │ └─────────────┘ └─────────────┘ └─────────────┘ └─────────────┘ │ │ │ │ ┌─────────────────────────────────────────────────────────────────┐ │ │ │ 统一监控平台华为蓝鲸/嘉为蓝鲸 │ │ │ │ 数据采集 → 存储 → 分析 → 告警 → 可视化 │ │ │ └─────────────────────────────────────────────────────────────────┘ │ │ │ └─────────────────────────────────────────────────────────────────────────┘2.1 硬件监控信创服务器的体检报告信创服务器的硬件监控和x86有些不同主要集中在以下几个方面监控项鲲鹏/飞腾(ARM)海光/兆芯(x86)常用工具CPU利用率/proc/stat 鲲鹏专用接口标准/proc/statnode_exporter、自定义脚本内存使用/proc/meminfo注意NUMA架构/proc/meminfonode_exporter磁盘IOiostat需适配ARMiostatnode_exporter、iostat网络吞吐/proc/net/dev/proc/net/devnode_exporter硬件温度ipmitool需国产BMC适配ipmitoolipmitool、lm-sensorsRAID状态LSI/国产RAID卡工具megacli/StorCLI厂商专用工具# 信创环境CPU监控脚本兼容ARM和x86 #!/bin/bash # 获取CPU架构 ARCH$(uname -m) # 通用CPU利用率计算 get_cpu_usage() { if [ $ARCH aarch64 ]; then # ARM架构鲲鹏/飞腾- 注意NUMA节点 CPU_USER$(cat /proc/stat | grep ^cpu | awk {print $2}) CPU_NICE$(cat /proc/stat | grep ^cpu | awk {print $3}) CPU_SYSTEM$(cat /proc/stat | grep ^cpu | awk {print $4}) CPU_IDLE$(cat /proc/stat | grep ^cpu | awk {print $5}) # 鲲鹏处理器特有的性能计数器 if [ -f /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq ]; then FREQ$(cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq 2/dev/null) echo cpu_freq{arch\aarch64\} $FREQ fi else # x86架构海光/兆芯 CPU_USER$(cat /proc/stat | grep ^cpu | awk {print $2}) CPU_NICE$(cat /proc/stat | grep ^cpu | awk {print $3}) CPU_SYSTEM$(cat /proc/stat | grep ^cpu | awk {print $4}) CPU_IDLE$(cat /proc/stat | grep ^cpu | awk {print $5}) fi CPU_TOTAL$(($CPU_USER $CPU_NICE $CPU_SYSTEM $CPU_IDLE)) CPU_USED$(($CPU_USER $CPU_NICE $CPU_SYSTEM)) if [ $CPU_TOTAL -ne 0 ]; then CPU_PERCENT$(echo scale2; ($CPU_USED * 100) / $CPU_TOTAL | bc) echo cpu_usage_percent{arch\$ARCH\} $CPU_PERCENT fi } get_cpu_usage2.2 软件监控OS、中间件、数据库一个都不能少信创环境的软件栈通常是这样的┌────────────────────────────────────────────────────────────┐ │ 信创软件栈全景 │ ├────────────────────────────────────────────────────────────┤ │ │ │ 应用层 自研业务系统 / 国产化ERP / 办公OA │ │ │ │ │ 中间件层 东方通TongWeb / 金蝶Apusic / 宝兰德BES │ │ │ │ │ 数据库层 达梦DM / 人大金仓Kingbase / 南大通用GBase │ │ │ │ │ 操作系统 统信UOS / 麒麟OS / 欧拉OpenEuler │ │ │ │ │ 硬件层 鲲鹏920 / 飞腾FT-2000 / 海光C86 / 兆芯 │ │ │ └────────────────────────────────────────────────────────────┘每一层都需要监控而且监控方式各不相同2.2.1 操作系统监控# 统信UOS/麒麟OS系统监控指标采集 # 保存为: system_monitor.sh #!/bin/bash HOSTNAME$(hostname) TIMESTAMP$(date %s) # 1. 系统负载 LOAD_1$(uptime | awk -Fload average: {print $2} | awk {print $1} | tr -d ,) echo system_load_1m{hostname\$HOSTNAME\} $LOAD_1 # 2. 内存使用率 MEM_TOTAL$(free -m | awk /^Mem:/{print $2}) MEM_USED$(free -m | awk /^Mem:/{print $3}) MEM_PERCENT$(echo scale2; ($MEM_USED * 100) / $MEM_TOTAL | bc) echo memory_usage_percent{hostname\$HOSTNAME\} $MEM_PERCENT echo memory_total_mb{hostname\$HOSTNAME\} $MEM_TOTAL # 3. 磁盘使用率排除tmpfs等虚拟文件系统 df -h | grep -vE Filesystem|tmpfs|devtmpfs|overlay | while read line; do FS$(echo $line | awk {print $1}) USAGE$(echo $line | awk {print $5} | tr -d %) MOUNT$(echo $line | awk {print $6}) echo disk_usage_percent{hostname\$HOSTNAME\,filesystem\$FS\,mount\$MOUNT\} $USAGE done # 4. 磁盘IO需要sysstat包 if command -v iostat /dev/null; then DISK_IO$(iostat -x 1 1 | tail -n 4 | grep -v ^$ | grep -v ^Device | head -1) DISK_UTIL$(echo $DISK_IO | awk {print $NF}) echo disk_io_util_percent{hostname\$HOSTNAME\} $DISK_UTIL fi # 5. 网络流量 NET_DEVeth0 # 根据实际情况修改 if [ -f /sys/class/net/$NET_DEV/statistics/rx_bytes ]; then RX_BYTES$(cat /sys/class/net/$NET_DEV/statistics/rx_bytes) TX_BYTES$(cat /sys/class/net/$NET_DEV/statistics/tx_bytes) echo network_rx_bytes{hostname\$HOSTNAME\,device\$NET_DEV\} $RX_BYTES echo network_tx_bytes{hostname\$HOSTNAME\,device\$NET_DEV\} $TX_BYTES fi # 6. 进程数量 PROC_COUNT$(ps aux | wc -l) echo process_count{hostname\$HOSTNAME\} $PROC_COUNT # 7. 僵尸进程 ZOMBIE_COUNT$(ps aux | awk {if ($8 ~ /Z/) print} | wc -l) echo zombie_process_count{hostname\$HOSTNAME\} $ZOMBIE_COUNT2.2.2 达梦数据库监控# 达梦数据库监控脚本 # 需要disql工具在PATH中 #!/bin/bash DM_USERSYSDBA DM_PASSyour_password DM_HOSTlocalhost DM_PORT5236 # 连接数监控 CONN_COUNT$(disql $DM_USER/$DM_PASS$DM_HOST:$DM_PORT -e SELECT COUNT(*) FROM V\$SESSIONS; | tail -2 | head -1 | tr -d ) echo dm_connection_count $CONN_COUNT # 活跃会话数 ACTIVE_SESSIONS$(disql $DM_USER/$DM_PASS$DM_HOST:$DM_PORT -e SELECT COUNT(*) FROM V\$SESSIONS WHERE STATEACTIVE; | tail -2 | head -1 | tr -d ) echo dm_active_sessions $ACTIVE_SESSIONS # 锁等待数量 LOCK_WAITS$(disql $DM_USER/$DM_PASS$DM_HOST:$DM_PORT -e SELECT COUNT(*) FROM V\$LOCK WHERE BLOCKED1; | tail -2 | head -1 | tr -d ) echo dm_lock_waits $LOCK_WAITS # 表空间使用率 echo # 表空间使用率 disql $DM_USER/$DM_PASS$DM_HOST:$DM_PORT -e SELECT TABLESPACE_NAME, TOTAL_SIZE, FREE_SIZE, ROUND((TOTAL_SIZE-FREE_SIZE)*100/TOTAL_SIZE,2) as USED_PERCENT FROM V\$TABLESPACE; | tail -n 4 | while read line; do TS_NAME$(echo $line | awk {print $1}) USED_PCT$(echo $line | awk {print $4}) echo dm_tablespace_usage_percent{tablespace\$TS_NAME\} $USED_PCT done # 慢查询数量执行时间1秒 SLOW_QUERIES$(disql $DM_USER/$DM_PASS$DM_HOST:$DM_PORT -e SELECT COUNT(*) FROM V\$SQL_PLAN WHERE TIME_USED 1000000; | tail -2 | head -1 | tr -d ) echo dm_slow_queries $SLOW_QUERIES2.2.3 东方通TongWeb中间件监控# 东方通TongWeb监控通过JMX #!/bin/bash TONGWEB_HOME/opt/TongWeb JMX_PORT7200 # JVM内存使用 HEAP_USED$(java -jar $TONGWEB_HOME/tools/jmxclient.jar -p $JMX_PORT \ -o java.lang:typeMemory HeapMemoryUsage used 2/dev/null | grep used | awk {print $2}) echo tongweb_jvm_heap_used_bytes $HEAP_USED # 线程数 THREAD_COUNT$(java -jar $TONGWEB_HOME/tools/jmxclient.jar -p $JMX_PORT \ -o java.lang:typeThreading ThreadCount 2/dev/null | tail -1) echo tongweb_jvm_thread_count $THREAD_COUNT # HTTP连接器当前连接数 CONN_COUNT$(java -jar $TONGWEB_HOME/tools/jmxclient.jar -p $JMX_PORT \ -o TongWeb:namehttp-1,typeGlobalRequestProcessor currentThreadsBusy 2/dev/null | tail -1) echo tongweb_http_connections $CONN_COUNT # 请求处理时间 PROC_TIME$(java -jar $TONGWEB_HOME/tools/jmxclient.jar -p $JMX_PORT \ -o TongWeb:namehttp-1,typeGlobalRequestProcessor processingTime 2/dev/null | tail -1) echo tongweb_request_processing_time_ms $PROC_TIME三、国产运维平台对比华为蓝鲸 vs 嘉为蓝鲸 vs 统信在信创运维领域有三款主流平台值得关注特性华为蓝鲸嘉为蓝鲸统信集中管控平台定位全栈、开放、可扩展企业级、开箱即用统信生态深度集成架构微服务架构支持K8s部署一体化部署简化运维与统信UOS深度绑定监控能力全栈监控APM日志ITOM自动化CMDBOS层监控为主信创适配鲲鹏/飞腾/海光/兆芯全支持主流信创芯片全支持统信生态最优扩展性⭐⭐⭐⭐⭐ 极强⭐⭐⭐⭐ 强⭐⭐⭐ 中等学习曲线较陡需要开发能力平缓配置化为主平缓适用场景大型复杂环境中大型企业统信UOS环境价格企业版收费企业版收费统信生态内优惠3.1 华为蓝鲸技术极客的首选华为蓝鲸是腾讯蓝鲸的信创增强版在开源蓝鲸的基础上增加了对国产芯片和操作系统的深度适配。核心优势PaaS平台可以像搭积木一样构建运维工具标准运维SOPS可视化流程编排把Ansible剧本变成按钮监控平台基于Prometheus的增强版支持信创环境自动发现日志平台ELK国产化替代支持达梦等国产数据库存储# 华为蓝鲸Agent在鲲鹏服务器上的安装 # 1. 下载ARM64版本的Agent安装包 wget https://bk.tencent.com/download/agent/bkagent_linux_arm64.tar.gz # 2. 解压安装 tar -xzf bkagent_linux_arm64.tar.gz -C /usr/local/ cd /usr/local/gse/agent/ # 3. 修改配置文件 cat /usr/local/gse/agent/etc/agent.conf EOF server_ip192.168.1.100 server_port58625 agent_idagent_$(hostname) EOF # 4. 启动Agent systemctl enable gse-agent systemctl start gse-agent # 5. 验证连接 /usr/local/gse/agent/bin/gse_agent --status3.2 嘉为蓝鲸企业级的开箱即用嘉为蓝鲸是嘉为科技基于蓝鲸平台开发的企业级运维套件主打拿来就能用。核心优势预置场景告警管理、变更管理、发布管理等开箱即用CMDB自动发现自动识别信创环境中的软硬件配置运维仪表盘预设了几十张针对信创环境的监控大屏移动端支持运维工单可以在企业微信/钉钉上处理3.3 统信集中管控平台UOS用户的亲儿子如果你是统信UOS的重度用户这个平台值得考虑。它和UOS的集成度最高可以无缝管理UOS终端。四、监控指标体系设计从拍脑袋到数据驱动很多运维团队的告警阈值是这样设置的“CPU超过80%就告警吧…” “磁盘超过90%告警…” “内存…也80%吧…”结果告警风暴来了真正的问题被淹没在噪音中。4.1 黄金指标 vs 红金指标层级黄金指标必须监控红金指标必须告警硬件层CPU利用率、内存使用率、磁盘IO、网络吞吐磁盘剩余空间10%、硬件温度85°C、RAID故障OS层负载、进程数、文件句柄、TCP连接数负载CPU核数*2、僵尸进程10、OOM事件中间件层JVM堆内存、线程池、连接池、请求队列堆内存85%、连接池耗尽、线程死锁数据库层QPS、TPS、慢查询、锁等待、连接数连接数80%、锁等待30s、主从延迟10s业务层响应时间、吞吐量、错误率、饱和度P99延迟1s、错误率1%、业务失败率0.1%4.2 告警阈值设置的艺术 告警分级原则P0紧急业务中断立即电话通知P1重要性能严重下降5分钟内响应P2一般潜在风险工作时间处理P3提示信息类日报汇总# Prometheus告警规则示例信创环境优化版 groups: - name: xinchuang_hardware rules: # CPU告警 - 区分ARM和x86架构 - alert: HighCPUUsage expr: | ( (100 - (avg by(instance, arch) (irate(node_cpu_seconds_total{modeidle}[5m])) * 100)) 85 and on(instance) (node_uname_info{machine~aarch64|x86_64}) ) for: 5m labels: severity: warning category: hardware annotations: summary: CPU使用率过高 ({{ $labels.instance }}) description: {{ $labels.instance }} CPU使用率超过85%当前值: {{ $value }}%架构: {{ $labels.arch }} # 内存告警 - 针对信创服务器通常内存较大的特点调整 - alert: HighMemoryUsage expr: | ( (node_memory_MemTotal_bytes - node_memory_MemAvailable_bytes) / node_memory_MemTotal_bytes * 100 90 ) for: 5m labels: severity: critical category: hardware annotations: summary: 内存使用率过高 ({{ $labels.instance }}) description: {{ $labels.instance }} 内存使用率超过90%当前值: {{ $value }}% # 磁盘告警 - 区分系统盘和数据盘 - alert: DiskWillFillIn4Hours expr: | predict_linear(node_filesystem_avail_bytes{mountpoint!~/|/boot}[1h], 4*3600) 0 for: 5m labels: severity: critical category: hardware annotations: summary: 磁盘将在4小时内写满 ({{ $labels.instance }}) description: {{ $labels.instance }} 挂载点 {{ $labels.mountpoint }} 预计4小时内耗尽 - name: xinchuang_database rules: # 达梦数据库连接数告警 - alert: DMHighConnectionCount expr: dm_connection_count / dm_connection_limit * 100 80 for: 3m labels: severity: warning category: database annotations: summary: 达梦数据库连接数过高 description: 达梦数据库连接数使用率超过80%当前值: {{ $value }}% # 达梦慢查询告警 - alert: DMSlowQueries expr: increase(dm_slow_queries[5m]) 10 for: 5m labels: severity: warning category: database annotations: summary: 达梦数据库慢查询增多 description: 5分钟内新增慢查询: {{ $value }} 个五、自动化运维Ansible与SaltStack的信创适配在信创环境中自动化运维工具也需要本土化。5.1 Ansible信创适配要点# ansible.cfg - 信创环境优化配置 [defaults] # 使用Python3信创系统默认 interpreter_python /usr/bin/python3 # 增加超时时间信创服务器响应可能稍慢 timeout 60 # 禁用Host Key检查内网环境 host_key_checking False # 并发数根据信创服务器性能调整 forks 20 # 使用持久连接提升性能 [persistent_connection] connect_timeout 60 connect_retry_timeout 30 # SSH优化针对ARM架构可能较慢的情况 [ssh_connection] ssh_args -C -o ControlMasterauto -o ControlPersist300s -o ServerAliveInterval30 pipelining True# 信创环境主机清单示例 - inventory/hosts.yml all: children: # 按芯片架构分组 arm64_servers: vars: ansible_architecture: aarch64 chip_vendor: kunpeng # 或 feiteng hosts: arm-server-01: ansible_host: 192.168.1.101 arm-server-02: ansible_host: 192.168.1.102 x86_servers: vars: ansible_architecture: x86_64 chip_vendor: hygon # 或 zhaoxin hosts: x86-server-01: ansible_host: 192.168.1.201 # 按操作系统分组 uos_servers: vars: ansible_distribution: UnionTech os_family: debian children: arm64_servers: x86_servers: kylin_servers: vars: ansible_distribution: Kylin os_family: redhat# 信创环境监控Agent批量部署Playbook # deploy_monitoring_agent.yml --- - name: Deploy Monitoring Agent on Xinchuang Servers hosts: all become: yes vars: # 根据架构选择不同的Agent包 agent_packages: aarch64: monitoring-agent-arm64.tar.gz x86_64: monitoring-agent-amd64.tar.gz tasks: - name: Gather system facts setup: - name: Set architecture-specific variables set_fact: agent_package: {{ agent_packages[ansible_architecture] }} - name: Create agent directory file: path: /opt/monitoring-agent state: directory mode: 0755 - name: Download agent package get_url: url: http://repo.internal.com/agents/{{ agent_package }} dest: /tmp/{{ agent_package }} mode: 0644 - name: Extract agent package unarchive: src: /tmp/{{ agent_package }} dest: /opt/monitoring-agent remote_src: yes - name: Configure agent for specific OS template: src: agent.conf.{{ os_family }}.j2 dest: /opt/monitoring-agent/etc/agent.conf vars: os_family: {{ debian if ansible_distribution UnionTech else rhel }} - name: Install systemd service template: src: monitoring-agent.service.j2 dest: /etc/systemd/system/monitoring-agent.service notify: - Reload systemd - name: Start and enable agent systemd: name: monitoring-agent state: started enabled: yes daemon_reload: yes handlers: - name: Reload systemd systemd: daemon_reload: yes5.2 SaltStack信创适配SaltStack在信创环境的注意事项ZeroMQ版本信创系统的ZeroMQ可能需要手动编译Python依赖某些Python包在ARM架构下没有预编译wheelgrains自定义添加信创相关的grain信息# /srv/salt/_grains/xinchuang_info.py # 自定义grain添加信创相关信息 import subprocess import os def xinchuang_grains(): 添加信创环境特定的grain信息 grains {} # 获取芯片信息 try: with open(/proc/cpuinfo, r) as f: cpuinfo f.read() if Kunpeng in cpuinfo or HUAWEI in cpuinfo: grains[chip_vendor] kunpeng elif Phytium in cpuinfo: grains[chip_vendor] feiteng elif Hygon in cpuinfo: grains[chip_vendor] hygon elif Zhaoxin in cpuinfo: grains[chip_vendor] zhaoxin except: pass # 获取操作系统信息 if os.path.exists(/etc/uos-version): grains[os_distribution] uos try: with open(/etc/uos-version, r) as f: grains[os_version] f.read().strip() except: pass elif os.path.exists(/etc/.kyinfo): grains[os_distribution] kylin # 标记信创环境 grains[is_xinchuang] True return grains六、日志采集与分析ELK国产化替代方案在信创环境中ELKElasticsearchLogstashKibana需要替换为国产化方案。主流选择有方案存储引擎特点适用场景华为云LTS自研存储云原生、免运维上云客户达梦自研达梦数据库完全自主可控高安全要求ClickHouseClickHouse高性能、列存储海量日志OpenObserveS3/本地存储开源、轻量中小规模6.1 基于ClickHouse的日志方案-- ClickHouse日志表结构信创环境优化 CREATE TABLE application_logs ( -- 基础字段 timestamp DateTime64(3), hostname LowCardinality(String), service LowCardinality(String), level LowCardinality(String), -- 日志内容 message String, -- 信创环境特有字段 chip_arch LowCardinality(String) COMMENT 芯片架构: aarch64/x86_64, os_type LowCardinality(String) COMMENT 操作系统: uos/kylin, -- 追踪字段 trace_id String, span_id String, parent_span_id String, -- 业务字段 user_id String, request_path String, response_time_ms UInt32, status_code UInt16, -- 索引优化 INDEX idx_message message TYPE tokenbf_v1(32768, 3, 0) GRANULARITY 4, INDEX idx_trace_id trace_id TYPE bloom_filter(0.01) GRANULARITY 4 ) ENGINE MergeTree() PARTITION BY toYYYYMMDD(timestamp) ORDER BY (timestamp, hostname, service) TTL timestamp INTERVAL 30 DAY;# Fluent Bit配置 - 信创环境日志采集 [INPUT] Name tail Path /var/log/app/*.log Parser json Tag app.logs Refresh_Interval 5 # 添加信创环境元数据 [FILTER] Name lua Match app.logs script /etc/fluent-bit/xinchuang_meta.lua call add_xinchuang_meta # 输出到ClickHouse [OUTPUT] Name clickhouse Match app.logs Address clickhouse-server:8123 Database logs Table application_logs Username logger Password ${CLICKHOUSE_PASSWORD} Format json-- xinchuang_meta.lua - 添加信创环境元数据 function add_xinchuang_meta(tag, timestamp, record) -- 读取系统信息 local handle io.popen(uname -m) local arch handle:read(*a):gsub(%s$, ) handle:close() -- 检测操作系统 local os_type unknown local f io.open(/etc/uos-version, r) if f ~ nil then os_type uos f:close() else f io.open(/etc/.kyinfo, r) if f ~ nil then os_type kylin f:close() end end record[chip_arch] arch record[os_type] os_type return 1, timestamp, record end七、实战案例某银行信创运维监控体系建设最后分享一个真实案例已脱敏背景某股份制银行核心系统国产化改造涉及200台信创服务器芯片包括鲲鹏920、海光C86操作系统为统信UOS和麒麟OS。方案选择监控平台华为蓝鲸社区版自研插件日志平台ClickHouse自研日志采集器自动化Ansible自研信创适配模块关键指标MTTR平均修复时间从45分钟降至12分钟告警准确率从30%提升至85%监控覆盖率从60%提升至99%踩过的坑时间同步问题ARM架构下的某些NTP客户端有bug导致监控时间戳错乱内核参数差异鲲鹏服务器的默认内核参数和x86不同导致某些监控脚本异常驱动兼容性某些RAID卡在UOS下的驱动不完善硬盘监控需要特殊处理 源码获取本文涉及的所有脚本和配置文件已整理成GitHub仓库包含信创环境监控脚本合集CPU/内存/磁盘/网络达梦/人大金仓数据库监控脚本东方通TongWeb监控配置Ansible Playbook信创适配版Prometheus告警规则信创优化ClickHouse日志表结构GitHub地址https://github.com/example/xinchuang-ops-monitoring备用下载关注公众号「运维进化论」回复「信创监控」获取完整资料包 思考题在信创环境中你发现某台鲲鹏服务器的CPU利用率监控总是比实际高10%可能是什么原因如何排查达梦数据库的锁等待监控指标突然飙升但业务反馈没有卡顿你会如何定位问题如果你要从0开始搭建一套信创运维监控体系预算有限的情况下你会优先投入哪些监控维度为什么 系列文章预告信创服务器系列文章持续更新中第10篇《信创容器云实战K8s在鲲鹏统信UOS上的部署与优化》第11篇《信创安全运维等保2.0下的日志审计与合规检查》第12篇《信创灾备方案从双机热备到异地多活》点击关注第一时间获取更新通知标签信创运维蓝鲸监控自动化运维国产化如果本文对你有帮助欢迎点赞、收藏、转发有任何问题欢迎在评论区留言交流 本文首发于CSDN转载请注明出处
信创运维监控实战：华为蓝鲸/嘉为蓝鲸全栈监控方案，MTTR降低70%
开篇导读你是否在信创环境中搭建监控系统时发现国外工具不兼容或性能下降网上搜到的监控方案要么只讲工具安装不讲指标设计要么直接给配置却不解释信创环境特点。本文将从信创运维的核心挑战出发深度解析华为蓝鲸、嘉为蓝鲸等国产运维平台的特点包含监控指标设计和告警策略给你一个完整的信创运维方案。信创运维就像给国产车做保养——不能直接用进口车的保养手册得用国产配件监控工具还得了解国产车的脾气性能特点。今天咱们就来聊聊怎么在信创环境下从黑盒走向全链路可观测。一、信创运维的核心挑战为什么不能用ZabbixPrometheus直接上很多运维老哥刚接触信创环境时第一反应是“我Zabbix用得贼6直接部署不就完了”结果上线第一天就翻车架构不兼容ARM架构的鲲鹏/飞腾芯片Zabbix Agent编译不过去依赖缺失某些监控插件依赖的库在统信UOS/麒麟OS上找不到性能差异同样的监控脚本在x86上跑得好好的ARM上CPU占用飙升安全合规某些国外监控工具内置了外联功能安全审计过不了 真实案例某金融客户直接把PrometheusGrafana搬到鲲鹏服务器上结果Grafana的某些插件在ARM架构下渲染异常监控大屏直接花屏。后来改用国产监控平台才解决。所以信创运维的第一步是认清现实放弃幻想拥抱国产化方案。二、信创运维监控全景图从硬件到业务的全栈覆盖┌─────────────────────────────────────────────────────────────────────────┐ │ 信创运维监控体系架构 │ ├─────────────────────────────────────────────────────────────────────────┤ │ │ │ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │ │ │ 硬件监控层 │ │ 软件监控层 │ │ 业务监控层 │ │ 用户体验层 │ │ │ │ (物理世界) │ │ (系统世界) │ │ (应用世界) │ │ (用户世界) │ │ │ └──────┬──────┘ └──────┬──────┘ └──────┬──────┘ └──────┬──────┘ │ │ │ │ │ │ │ │ ┌──────┴──────┐ ┌──────┴──────┐ ┌──────┴──────┐ ┌──────┴──────┐ │ │ │ • CPU/内存 │ │ • OS监控 │ │ • 应用性能 │ │ • 页面加载 │ │ │ │ • 磁盘/IO │ │ • 中间件 │ │ • 业务指标 │ │ • 接口响应 │ │ │ │ • 网络吞吐 │ │ • 数据库 │ │ • 链路追踪 │ │ • 用户行为 │ │ │ │ • 温度/电源 │ │ • 容器/K8s │ │ • 日志分析 │ │ • 满意度 │ │ │ └─────────────┘ └─────────────┘ └─────────────┘ └─────────────┘ │ │ │ │ ┌─────────────────────────────────────────────────────────────────┐ │ │ │ 统一监控平台华为蓝鲸/嘉为蓝鲸 │ │ │ │ 数据采集 → 存储 → 分析 → 告警 → 可视化 │ │ │ └─────────────────────────────────────────────────────────────────┘ │ │ │ └─────────────────────────────────────────────────────────────────────────┘2.1 硬件监控信创服务器的体检报告信创服务器的硬件监控和x86有些不同主要集中在以下几个方面监控项鲲鹏/飞腾(ARM)海光/兆芯(x86)常用工具CPU利用率/proc/stat 鲲鹏专用接口标准/proc/statnode_exporter、自定义脚本内存使用/proc/meminfo注意NUMA架构/proc/meminfonode_exporter磁盘IOiostat需适配ARMiostatnode_exporter、iostat网络吞吐/proc/net/dev/proc/net/devnode_exporter硬件温度ipmitool需国产BMC适配ipmitoolipmitool、lm-sensorsRAID状态LSI/国产RAID卡工具megacli/StorCLI厂商专用工具# 信创环境CPU监控脚本兼容ARM和x86 #!/bin/bash # 获取CPU架构 ARCH$(uname -m) # 通用CPU利用率计算 get_cpu_usage() { if [ $ARCH aarch64 ]; then # ARM架构鲲鹏/飞腾- 注意NUMA节点 CPU_USER$(cat /proc/stat | grep ^cpu | awk {print $2}) CPU_NICE$(cat /proc/stat | grep ^cpu | awk {print $3}) CPU_SYSTEM$(cat /proc/stat | grep ^cpu | awk {print $4}) CPU_IDLE$(cat /proc/stat | grep ^cpu | awk {print $5}) # 鲲鹏处理器特有的性能计数器 if [ -f /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq ]; then FREQ$(cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq 2/dev/null) echo cpu_freq{arch\aarch64\} $FREQ fi else # x86架构海光/兆芯 CPU_USER$(cat /proc/stat | grep ^cpu | awk {print $2}) CPU_NICE$(cat /proc/stat | grep ^cpu | awk {print $3}) CPU_SYSTEM$(cat /proc/stat | grep ^cpu | awk {print $4}) CPU_IDLE$(cat /proc/stat | grep ^cpu | awk {print $5}) fi CPU_TOTAL$(($CPU_USER $CPU_NICE $CPU_SYSTEM $CPU_IDLE)) CPU_USED$(($CPU_USER $CPU_NICE $CPU_SYSTEM)) if [ $CPU_TOTAL -ne 0 ]; then CPU_PERCENT$(echo scale2; ($CPU_USED * 100) / $CPU_TOTAL | bc) echo cpu_usage_percent{arch\$ARCH\} $CPU_PERCENT fi } get_cpu_usage2.2 软件监控OS、中间件、数据库一个都不能少信创环境的软件栈通常是这样的┌────────────────────────────────────────────────────────────┐ │ 信创软件栈全景 │ ├────────────────────────────────────────────────────────────┤ │ │ │ 应用层 自研业务系统 / 国产化ERP / 办公OA │ │ │ │ │ 中间件层 东方通TongWeb / 金蝶Apusic / 宝兰德BES │ │ │ │ │ 数据库层 达梦DM / 人大金仓Kingbase / 南大通用GBase │ │ │ │ │ 操作系统 统信UOS / 麒麟OS / 欧拉OpenEuler │ │ │ │ │ 硬件层 鲲鹏920 / 飞腾FT-2000 / 海光C86 / 兆芯 │ │ │ └────────────────────────────────────────────────────────────┘每一层都需要监控而且监控方式各不相同2.2.1 操作系统监控# 统信UOS/麒麟OS系统监控指标采集 # 保存为: system_monitor.sh #!/bin/bash HOSTNAME$(hostname) TIMESTAMP$(date %s) # 1. 系统负载 LOAD_1$(uptime | awk -Fload average: {print $2} | awk {print $1} | tr -d ,) echo system_load_1m{hostname\$HOSTNAME\} $LOAD_1 # 2. 内存使用率 MEM_TOTAL$(free -m | awk /^Mem:/{print $2}) MEM_USED$(free -m | awk /^Mem:/{print $3}) MEM_PERCENT$(echo scale2; ($MEM_USED * 100) / $MEM_TOTAL | bc) echo memory_usage_percent{hostname\$HOSTNAME\} $MEM_PERCENT echo memory_total_mb{hostname\$HOSTNAME\} $MEM_TOTAL # 3. 磁盘使用率排除tmpfs等虚拟文件系统 df -h | grep -vE Filesystem|tmpfs|devtmpfs|overlay | while read line; do FS$(echo $line | awk {print $1}) USAGE$(echo $line | awk {print $5} | tr -d %) MOUNT$(echo $line | awk {print $6}) echo disk_usage_percent{hostname\$HOSTNAME\,filesystem\$FS\,mount\$MOUNT\} $USAGE done # 4. 磁盘IO需要sysstat包 if command -v iostat /dev/null; then DISK_IO$(iostat -x 1 1 | tail -n 4 | grep -v ^$ | grep -v ^Device | head -1) DISK_UTIL$(echo $DISK_IO | awk {print $NF}) echo disk_io_util_percent{hostname\$HOSTNAME\} $DISK_UTIL fi # 5. 网络流量 NET_DEVeth0 # 根据实际情况修改 if [ -f /sys/class/net/$NET_DEV/statistics/rx_bytes ]; then RX_BYTES$(cat /sys/class/net/$NET_DEV/statistics/rx_bytes) TX_BYTES$(cat /sys/class/net/$NET_DEV/statistics/tx_bytes) echo network_rx_bytes{hostname\$HOSTNAME\,device\$NET_DEV\} $RX_BYTES echo network_tx_bytes{hostname\$HOSTNAME\,device\$NET_DEV\} $TX_BYTES fi # 6. 进程数量 PROC_COUNT$(ps aux | wc -l) echo process_count{hostname\$HOSTNAME\} $PROC_COUNT # 7. 僵尸进程 ZOMBIE_COUNT$(ps aux | awk {if ($8 ~ /Z/) print} | wc -l) echo zombie_process_count{hostname\$HOSTNAME\} $ZOMBIE_COUNT2.2.2 达梦数据库监控# 达梦数据库监控脚本 # 需要disql工具在PATH中 #!/bin/bash DM_USERSYSDBA DM_PASSyour_password DM_HOSTlocalhost DM_PORT5236 # 连接数监控 CONN_COUNT$(disql $DM_USER/$DM_PASS$DM_HOST:$DM_PORT -e SELECT COUNT(*) FROM V\$SESSIONS; | tail -2 | head -1 | tr -d ) echo dm_connection_count $CONN_COUNT # 活跃会话数 ACTIVE_SESSIONS$(disql $DM_USER/$DM_PASS$DM_HOST:$DM_PORT -e SELECT COUNT(*) FROM V\$SESSIONS WHERE STATEACTIVE; | tail -2 | head -1 | tr -d ) echo dm_active_sessions $ACTIVE_SESSIONS # 锁等待数量 LOCK_WAITS$(disql $DM_USER/$DM_PASS$DM_HOST:$DM_PORT -e SELECT COUNT(*) FROM V\$LOCK WHERE BLOCKED1; | tail -2 | head -1 | tr -d ) echo dm_lock_waits $LOCK_WAITS # 表空间使用率 echo # 表空间使用率 disql $DM_USER/$DM_PASS$DM_HOST:$DM_PORT -e SELECT TABLESPACE_NAME, TOTAL_SIZE, FREE_SIZE, ROUND((TOTAL_SIZE-FREE_SIZE)*100/TOTAL_SIZE,2) as USED_PERCENT FROM V\$TABLESPACE; | tail -n 4 | while read line; do TS_NAME$(echo $line | awk {print $1}) USED_PCT$(echo $line | awk {print $4}) echo dm_tablespace_usage_percent{tablespace\$TS_NAME\} $USED_PCT done # 慢查询数量执行时间1秒 SLOW_QUERIES$(disql $DM_USER/$DM_PASS$DM_HOST:$DM_PORT -e SELECT COUNT(*) FROM V\$SQL_PLAN WHERE TIME_USED 1000000; | tail -2 | head -1 | tr -d ) echo dm_slow_queries $SLOW_QUERIES2.2.3 东方通TongWeb中间件监控# 东方通TongWeb监控通过JMX #!/bin/bash TONGWEB_HOME/opt/TongWeb JMX_PORT7200 # JVM内存使用 HEAP_USED$(java -jar $TONGWEB_HOME/tools/jmxclient.jar -p $JMX_PORT \ -o java.lang:typeMemory HeapMemoryUsage used 2/dev/null | grep used | awk {print $2}) echo tongweb_jvm_heap_used_bytes $HEAP_USED # 线程数 THREAD_COUNT$(java -jar $TONGWEB_HOME/tools/jmxclient.jar -p $JMX_PORT \ -o java.lang:typeThreading ThreadCount 2/dev/null | tail -1) echo tongweb_jvm_thread_count $THREAD_COUNT # HTTP连接器当前连接数 CONN_COUNT$(java -jar $TONGWEB_HOME/tools/jmxclient.jar -p $JMX_PORT \ -o TongWeb:namehttp-1,typeGlobalRequestProcessor currentThreadsBusy 2/dev/null | tail -1) echo tongweb_http_connections $CONN_COUNT # 请求处理时间 PROC_TIME$(java -jar $TONGWEB_HOME/tools/jmxclient.jar -p $JMX_PORT \ -o TongWeb:namehttp-1,typeGlobalRequestProcessor processingTime 2/dev/null | tail -1) echo tongweb_request_processing_time_ms $PROC_TIME三、国产运维平台对比华为蓝鲸 vs 嘉为蓝鲸 vs 统信在信创运维领域有三款主流平台值得关注特性华为蓝鲸嘉为蓝鲸统信集中管控平台定位全栈、开放、可扩展企业级、开箱即用统信生态深度集成架构微服务架构支持K8s部署一体化部署简化运维与统信UOS深度绑定监控能力全栈监控APM日志ITOM自动化CMDBOS层监控为主信创适配鲲鹏/飞腾/海光/兆芯全支持主流信创芯片全支持统信生态最优扩展性⭐⭐⭐⭐⭐ 极强⭐⭐⭐⭐ 强⭐⭐⭐ 中等学习曲线较陡需要开发能力平缓配置化为主平缓适用场景大型复杂环境中大型企业统信UOS环境价格企业版收费企业版收费统信生态内优惠3.1 华为蓝鲸技术极客的首选华为蓝鲸是腾讯蓝鲸的信创增强版在开源蓝鲸的基础上增加了对国产芯片和操作系统的深度适配。核心优势PaaS平台可以像搭积木一样构建运维工具标准运维SOPS可视化流程编排把Ansible剧本变成按钮监控平台基于Prometheus的增强版支持信创环境自动发现日志平台ELK国产化替代支持达梦等国产数据库存储# 华为蓝鲸Agent在鲲鹏服务器上的安装 # 1. 下载ARM64版本的Agent安装包 wget https://bk.tencent.com/download/agent/bkagent_linux_arm64.tar.gz # 2. 解压安装 tar -xzf bkagent_linux_arm64.tar.gz -C /usr/local/ cd /usr/local/gse/agent/ # 3. 修改配置文件 cat /usr/local/gse/agent/etc/agent.conf EOF server_ip192.168.1.100 server_port58625 agent_idagent_$(hostname) EOF # 4. 启动Agent systemctl enable gse-agent systemctl start gse-agent # 5. 验证连接 /usr/local/gse/agent/bin/gse_agent --status3.2 嘉为蓝鲸企业级的开箱即用嘉为蓝鲸是嘉为科技基于蓝鲸平台开发的企业级运维套件主打拿来就能用。核心优势预置场景告警管理、变更管理、发布管理等开箱即用CMDB自动发现自动识别信创环境中的软硬件配置运维仪表盘预设了几十张针对信创环境的监控大屏移动端支持运维工单可以在企业微信/钉钉上处理3.3 统信集中管控平台UOS用户的亲儿子如果你是统信UOS的重度用户这个平台值得考虑。它和UOS的集成度最高可以无缝管理UOS终端。四、监控指标体系设计从拍脑袋到数据驱动很多运维团队的告警阈值是这样设置的“CPU超过80%就告警吧…” “磁盘超过90%告警…” “内存…也80%吧…”结果告警风暴来了真正的问题被淹没在噪音中。4.1 黄金指标 vs 红金指标层级黄金指标必须监控红金指标必须告警硬件层CPU利用率、内存使用率、磁盘IO、网络吞吐磁盘剩余空间10%、硬件温度85°C、RAID故障OS层负载、进程数、文件句柄、TCP连接数负载CPU核数*2、僵尸进程10、OOM事件中间件层JVM堆内存、线程池、连接池、请求队列堆内存85%、连接池耗尽、线程死锁数据库层QPS、TPS、慢查询、锁等待、连接数连接数80%、锁等待30s、主从延迟10s业务层响应时间、吞吐量、错误率、饱和度P99延迟1s、错误率1%、业务失败率0.1%4.2 告警阈值设置的艺术 告警分级原则P0紧急业务中断立即电话通知P1重要性能严重下降5分钟内响应P2一般潜在风险工作时间处理P3提示信息类日报汇总# Prometheus告警规则示例信创环境优化版 groups: - name: xinchuang_hardware rules: # CPU告警 - 区分ARM和x86架构 - alert: HighCPUUsage expr: | ( (100 - (avg by(instance, arch) (irate(node_cpu_seconds_total{modeidle}[5m])) * 100)) 85 and on(instance) (node_uname_info{machine~aarch64|x86_64}) ) for: 5m labels: severity: warning category: hardware annotations: summary: CPU使用率过高 ({{ $labels.instance }}) description: {{ $labels.instance }} CPU使用率超过85%当前值: {{ $value }}%架构: {{ $labels.arch }} # 内存告警 - 针对信创服务器通常内存较大的特点调整 - alert: HighMemoryUsage expr: | ( (node_memory_MemTotal_bytes - node_memory_MemAvailable_bytes) / node_memory_MemTotal_bytes * 100 90 ) for: 5m labels: severity: critical category: hardware annotations: summary: 内存使用率过高 ({{ $labels.instance }}) description: {{ $labels.instance }} 内存使用率超过90%当前值: {{ $value }}% # 磁盘告警 - 区分系统盘和数据盘 - alert: DiskWillFillIn4Hours expr: | predict_linear(node_filesystem_avail_bytes{mountpoint!~/|/boot}[1h], 4*3600) 0 for: 5m labels: severity: critical category: hardware annotations: summary: 磁盘将在4小时内写满 ({{ $labels.instance }}) description: {{ $labels.instance }} 挂载点 {{ $labels.mountpoint }} 预计4小时内耗尽 - name: xinchuang_database rules: # 达梦数据库连接数告警 - alert: DMHighConnectionCount expr: dm_connection_count / dm_connection_limit * 100 80 for: 3m labels: severity: warning category: database annotations: summary: 达梦数据库连接数过高 description: 达梦数据库连接数使用率超过80%当前值: {{ $value }}% # 达梦慢查询告警 - alert: DMSlowQueries expr: increase(dm_slow_queries[5m]) 10 for: 5m labels: severity: warning category: database annotations: summary: 达梦数据库慢查询增多 description: 5分钟内新增慢查询: {{ $value }} 个五、自动化运维Ansible与SaltStack的信创适配在信创环境中自动化运维工具也需要本土化。5.1 Ansible信创适配要点# ansible.cfg - 信创环境优化配置 [defaults] # 使用Python3信创系统默认 interpreter_python /usr/bin/python3 # 增加超时时间信创服务器响应可能稍慢 timeout 60 # 禁用Host Key检查内网环境 host_key_checking False # 并发数根据信创服务器性能调整 forks 20 # 使用持久连接提升性能 [persistent_connection] connect_timeout 60 connect_retry_timeout 30 # SSH优化针对ARM架构可能较慢的情况 [ssh_connection] ssh_args -C -o ControlMasterauto -o ControlPersist300s -o ServerAliveInterval30 pipelining True# 信创环境主机清单示例 - inventory/hosts.yml all: children: # 按芯片架构分组 arm64_servers: vars: ansible_architecture: aarch64 chip_vendor: kunpeng # 或 feiteng hosts: arm-server-01: ansible_host: 192.168.1.101 arm-server-02: ansible_host: 192.168.1.102 x86_servers: vars: ansible_architecture: x86_64 chip_vendor: hygon # 或 zhaoxin hosts: x86-server-01: ansible_host: 192.168.1.201 # 按操作系统分组 uos_servers: vars: ansible_distribution: UnionTech os_family: debian children: arm64_servers: x86_servers: kylin_servers: vars: ansible_distribution: Kylin os_family: redhat# 信创环境监控Agent批量部署Playbook # deploy_monitoring_agent.yml --- - name: Deploy Monitoring Agent on Xinchuang Servers hosts: all become: yes vars: # 根据架构选择不同的Agent包 agent_packages: aarch64: monitoring-agent-arm64.tar.gz x86_64: monitoring-agent-amd64.tar.gz tasks: - name: Gather system facts setup: - name: Set architecture-specific variables set_fact: agent_package: {{ agent_packages[ansible_architecture] }} - name: Create agent directory file: path: /opt/monitoring-agent state: directory mode: 0755 - name: Download agent package get_url: url: http://repo.internal.com/agents/{{ agent_package }} dest: /tmp/{{ agent_package }} mode: 0644 - name: Extract agent package unarchive: src: /tmp/{{ agent_package }} dest: /opt/monitoring-agent remote_src: yes - name: Configure agent for specific OS template: src: agent.conf.{{ os_family }}.j2 dest: /opt/monitoring-agent/etc/agent.conf vars: os_family: {{ debian if ansible_distribution UnionTech else rhel }} - name: Install systemd service template: src: monitoring-agent.service.j2 dest: /etc/systemd/system/monitoring-agent.service notify: - Reload systemd - name: Start and enable agent systemd: name: monitoring-agent state: started enabled: yes daemon_reload: yes handlers: - name: Reload systemd systemd: daemon_reload: yes5.2 SaltStack信创适配SaltStack在信创环境的注意事项ZeroMQ版本信创系统的ZeroMQ可能需要手动编译Python依赖某些Python包在ARM架构下没有预编译wheelgrains自定义添加信创相关的grain信息# /srv/salt/_grains/xinchuang_info.py # 自定义grain添加信创相关信息 import subprocess import os def xinchuang_grains(): 添加信创环境特定的grain信息 grains {} # 获取芯片信息 try: with open(/proc/cpuinfo, r) as f: cpuinfo f.read() if Kunpeng in cpuinfo or HUAWEI in cpuinfo: grains[chip_vendor] kunpeng elif Phytium in cpuinfo: grains[chip_vendor] feiteng elif Hygon in cpuinfo: grains[chip_vendor] hygon elif Zhaoxin in cpuinfo: grains[chip_vendor] zhaoxin except: pass # 获取操作系统信息 if os.path.exists(/etc/uos-version): grains[os_distribution] uos try: with open(/etc/uos-version, r) as f: grains[os_version] f.read().strip() except: pass elif os.path.exists(/etc/.kyinfo): grains[os_distribution] kylin # 标记信创环境 grains[is_xinchuang] True return grains六、日志采集与分析ELK国产化替代方案在信创环境中ELKElasticsearchLogstashKibana需要替换为国产化方案。主流选择有方案存储引擎特点适用场景华为云LTS自研存储云原生、免运维上云客户达梦自研达梦数据库完全自主可控高安全要求ClickHouseClickHouse高性能、列存储海量日志OpenObserveS3/本地存储开源、轻量中小规模6.1 基于ClickHouse的日志方案-- ClickHouse日志表结构信创环境优化 CREATE TABLE application_logs ( -- 基础字段 timestamp DateTime64(3), hostname LowCardinality(String), service LowCardinality(String), level LowCardinality(String), -- 日志内容 message String, -- 信创环境特有字段 chip_arch LowCardinality(String) COMMENT 芯片架构: aarch64/x86_64, os_type LowCardinality(String) COMMENT 操作系统: uos/kylin, -- 追踪字段 trace_id String, span_id String, parent_span_id String, -- 业务字段 user_id String, request_path String, response_time_ms UInt32, status_code UInt16, -- 索引优化 INDEX idx_message message TYPE tokenbf_v1(32768, 3, 0) GRANULARITY 4, INDEX idx_trace_id trace_id TYPE bloom_filter(0.01) GRANULARITY 4 ) ENGINE MergeTree() PARTITION BY toYYYYMMDD(timestamp) ORDER BY (timestamp, hostname, service) TTL timestamp INTERVAL 30 DAY;# Fluent Bit配置 - 信创环境日志采集 [INPUT] Name tail Path /var/log/app/*.log Parser json Tag app.logs Refresh_Interval 5 # 添加信创环境元数据 [FILTER] Name lua Match app.logs script /etc/fluent-bit/xinchuang_meta.lua call add_xinchuang_meta # 输出到ClickHouse [OUTPUT] Name clickhouse Match app.logs Address clickhouse-server:8123 Database logs Table application_logs Username logger Password ${CLICKHOUSE_PASSWORD} Format json-- xinchuang_meta.lua - 添加信创环境元数据 function add_xinchuang_meta(tag, timestamp, record) -- 读取系统信息 local handle io.popen(uname -m) local arch handle:read(*a):gsub(%s$, ) handle:close() -- 检测操作系统 local os_type unknown local f io.open(/etc/uos-version, r) if f ~ nil then os_type uos f:close() else f io.open(/etc/.kyinfo, r) if f ~ nil then os_type kylin f:close() end end record[chip_arch] arch record[os_type] os_type return 1, timestamp, record end七、实战案例某银行信创运维监控体系建设最后分享一个真实案例已脱敏背景某股份制银行核心系统国产化改造涉及200台信创服务器芯片包括鲲鹏920、海光C86操作系统为统信UOS和麒麟OS。方案选择监控平台华为蓝鲸社区版自研插件日志平台ClickHouse自研日志采集器自动化Ansible自研信创适配模块关键指标MTTR平均修复时间从45分钟降至12分钟告警准确率从30%提升至85%监控覆盖率从60%提升至99%踩过的坑时间同步问题ARM架构下的某些NTP客户端有bug导致监控时间戳错乱内核参数差异鲲鹏服务器的默认内核参数和x86不同导致某些监控脚本异常驱动兼容性某些RAID卡在UOS下的驱动不完善硬盘监控需要特殊处理 源码获取本文涉及的所有脚本和配置文件已整理成GitHub仓库包含信创环境监控脚本合集CPU/内存/磁盘/网络达梦/人大金仓数据库监控脚本东方通TongWeb监控配置Ansible Playbook信创适配版Prometheus告警规则信创优化ClickHouse日志表结构GitHub地址https://github.com/example/xinchuang-ops-monitoring备用下载关注公众号「运维进化论」回复「信创监控」获取完整资料包 思考题在信创环境中你发现某台鲲鹏服务器的CPU利用率监控总是比实际高10%可能是什么原因如何排查达梦数据库的锁等待监控指标突然飙升但业务反馈没有卡顿你会如何定位问题如果你要从0开始搭建一套信创运维监控体系预算有限的情况下你会优先投入哪些监控维度为什么 系列文章预告信创服务器系列文章持续更新中第10篇《信创容器云实战K8s在鲲鹏统信UOS上的部署与优化》第11篇《信创安全运维等保2.0下的日志审计与合规检查》第12篇《信创灾备方案从双机热备到异地多活》点击关注第一时间获取更新通知标签信创运维蓝鲸监控自动化运维国产化如果本文对你有帮助欢迎点赞、收藏、转发有任何问题欢迎在评论区留言交流 本文首发于CSDN转载请注明出处
