rsyslog服务日志报错分析1

客户问题：

最近对服务器进行日志检查时，发现部分主机的rsyslog服务状态有报错，报错详情如下

排查过程：

1.从报错截图来看，报错主要发生在文件‘/usr/lib64/rsyslog/omazuremds.so‘上

2.经查询该文件模块是由LinuxDiagnostic 2.3的虚拟机扩张进行安装的，该扩展的安装位置见下

3.目前怀疑问题机器的LinuxDiagnostic 2.3扩展没有在机器上正确安装，或在虚拟机内部没能正常启动引起的报错

4.可以通过如下方法检查该扩展的正确性

a.在Portal查看该扩展是否安装成功

b.登陆虚拟机查看如下文件是否存在，权限是否正确

[[email protected] ~]# ll /usr/lib64/rsyslog/omazuremds.so

-rwxr--r--. 1 root root 31536 Jun  3 09:13 /usr/lib64/rsyslog/omazuremds.so

[[email protected]-t1 ~]# ll /var/lib/waagent/Microsoft.OSTCExtensions.LinuxDiagnostic-2.3.9021

total 31212

drwxr-xr-x. 2 root root       46 Jun  3 09:13 bin

-rwxr--r--. 1 root root     4121 Jun  3 09:13 ChangeLogs

drwx------. 2 root root       65 Jun  3 09:13 config

-rw-r--r--. 1 root root      554 Jun  3 09:13 daemon.log

-rwxr--r--. 1 root root    56743 Jun  3 09:13 diagnostic.py

-rw-r--r--. 1 root root      462 Jun  3 09:13 HandlerEnvironment.json

-rwxr--r--. 1 root root      420 Jun  3 09:13 HandlerManifest.json

-rw-r--r--. 1 root root     1382 Jun  3 09:13 lad_mdsd.mod

-rw-r--r--. 1 root root     1398 Jun  3 09:13 lad_mdsd.pp

-rwxr--r--. 1 root root      587 Jun  3 09:13 lad_mdsd.te

-rwxr--r--. 1 root root     1134 Jun  3 09:13 license.txt

-rwxr--r--. 1 root root      544 Jun  3 09:13 Makefile

-rwxr--r--. 1 root root      954 Jun  3 09:13 manifest.xml

-rwxr--r--. 1 root root     1505 Jun  3 09:13 mdsdConfig.xml.template

-rw-r--r--. 1 root root        0 Jun  3 09:13 mdsd.log

-rw-r--r--. 1 root root       10 Jun  3 09:13 mdsd.pid

-rw-r--r--. 1 root root        1 Jun  3 09:13 mrseq

-rw-r--r--. 1 root root        0 Jun  3 09:13 omfileconfig

-rwxr--r--. 1 root root     7021 Jun  3 09:13 portal.xml.template

-rwxr--r--. 1 root root    11828 Jun  3 09:13 README.md

drwxr-xr-x. 2 root root       55 Jun  3 09:13 rsyslog5

drwxr-xr-x. 2 root root       55 Jun  3 09:13 rsyslog7

drwxr-xr-x. 2 root root       55 Jun  3 09:13 rsyslog8

-rwxr--r--. 1 root root       44 Jun  3 09:13 run_unittests.sh

-rwxr--r--. 1 root root 31796822 Jun  3 09:13 scx-1.6.2-337.universal.x64.sh

drwxr-xr-x. 2 root root       30 Jun  3 09:13 services

drwx------. 2 root root       22 Jun  3 09:13 status

drwxr-xr-x. 2 root root       48 Jun  3 09:13 tests

drwxr-xr-x. 2 root root     4096 Jun  3 09:13 Utils

-rwxr--r--. 1 root root     3195 Jun  3 09:13 watcherutil.py

-rw-r--r--. 1 root root     2275 Jun  3 09:13 watcherutil.pyc

-rw-r--r--. 1 root root    12036 Jun  3 09:13 xmlCfg.xml

[[email protected]-t1 ~]# ps aux | grep -i xml

root       7366  0.3  0.8 1438776 30252 ?       Sl   09:13   0:06 /var/lib/waagent/Microsoft.OSTCExtensions.LinuxDiagnostic-2.3.9021/bin/mdsd -A -C -c /var/lib/waagent/Microsoft.OSTCExtensions.LinuxDiagnostic-2.3.9021/./xmlCfg.xml -p 29131 -R -r lad_mdsd -e /var/log/azure/Microsoft.OSTCExtensions.LinuxDiagnostic/2.3.9021/mdsd.err -w /var/log/azure/Microsoft.OSTCExtensions.LinuxDiagnostic/2.3.9021/mdsd.warn -o /var/log/azure/Microsoft.OSTCExtensions.LinuxDiagnostic/2.3.9021/mdsd.info

5.如果上述扩展没有正常启动，可以通过如下方法解决该问题

a.在Azure Portal卸载LinuxDiagnostic的扩展

b.对虚拟机重新启用诊断设置

原文地址：https://www.cnblogs.com/stonehe/p/10970810.html

时间： 2024-11-05 23:26:27

rsyslog服务日志报错分析1的相关文章

数据库日志报错问题分析

Thread 1 cannot allocate new log, sequence 466 Private strand flush not complete Current log# 7 seq# 465 mem# 0: /home/app/oracle/oradata/orcl/redo07.log Thread 1 advanced to log sequence 466 (LGWR switch) Current log# 8 seq# 466 mem# 0: /home/app/or

学会WCF之试错法——安全配置报错分析

安全配置报错分析服务端配置 <system.serviceModel> <bindings> <wsHttpBinding> <binding name ="WsHttpBinding_IService" maxReceivedMessageSize="370000" receiveTimeout="00:10:01" maxBufferPoolSize="100"> <

ssh无法登陆,secure日志报错not allowed because none of user's groups

背景:一台阿里云ECS跑了云市场的一个安全加固脚本,限制了root登录和密码登录,由于客户需求,需要将root放开对应操作: vim /etc/ssh/sshd_config PermitRootLogin yes PasswordAuthentication yes 改完后,便立马重启ssh服务(/etc/init.d/sshd restart)登录测试居然还是登录不了,还以为密码错误呢,就是用控制台VNC登录,证明密码没有问题. 特烦恼,查边了百度的关于限制root用户登录的帖子,都是

记一次rsync日志报错directory has vanished

中午两点的时候邮件告知rsync同部svn源库失败,看rsync日志报错显示如上,当时还在上课,没在公司,怀疑是不是有人动了svn的版本库,后来询问同事并通过vpn登录服务器上查看版本库是正常的,也没有同事反应svn有问题,后来看邮件通知都是正常的,后来查资料说是在同步的过程中,正好有人执行了删除文件的操作,要不要这么巧,不知道是不是这个原因,有知道的小伙伴请联系我:528634141,资料显示如下: Can you ensure, that there is no traffic on the

message日志报错：TCP: time wait bucket table overflow，K哥

2015.9.13 message日志报错:TCP: time wait bucket table overflow 网上很多解决办法,我也是百度的,哈哈先盗一张图,因为问题已经很久了,没截图 K哥盗图. 这个报错需要更改net.ipv4.tcp_max_tw_buckets这个内核参数. 这个参数是系统同时保持timewait套接字的最大数量. 如果超过这个数字,time-wait套接字将立刻被清除并打印警告信息. 这个限制仅仅是为了防止简单的 DoS攻击. 解决方法: 增大 tcp_max

nginx error日志报错

经过与开发的不断协作,终于差不多把error日志的报错信息消灭的差不多了,但还是偶尔出现"*1939 an upstream response is buffered to a temporary file /var/cache/nginx/proxy_temp/2/00/0000000002 while reading upstream, client: 116.231.88.XX, server: _, request: "GET /time HTTP/1.1", ups

KVM服务启动报错：version Base not defined in file libdevmapper.so.1.02

新安装一台KVM服务器,启动KVM服务时候报错:version Base not defined in file libdevmapper.so.1.02 with link time reference 现象如下: # /etc/init.d/libvirtd startStarting libvirtd daemon: libvirtd: relocation error: libvirtd: symbol dm_task_get_info_with_deferred_remove, ver

const变量赋值报错分析

const变量赋值报错分析 const变量赋值报错从变量到常量的赋值是合法C++的语法约定的, 如从char 到const char顺畅: 但从char **到 const char **编译器就会报错: error: invalid conversion from `char**' to `const char**' 示例: int main(int argc, char *argv[]) { char a = '1'; const char b = a; char * a2 = "1234

linux 日志报错：error (unexpected RCODE REFUSED) resolving '

今天在机子上查看日志,偶然间发现了一堆错误.因为之前配置过DNS 和 squid,报错,之后查错,某度了一下,没找到答案. 下面是一点错误信息: Aug 8 11:40:30 host named[1668]: error (unexpected RCODE REFUSED) resolving '208.22.200.65.in-addr.arpa/PTR/IN': 74.115.231.45#53Aug 8 11:40:30 host named[1668]: error (unexpe