Linux下应用/进程的存活性监控

本文最后更新于2018年6月2日,已超过 1 年没有更新,如果文章内容失效,还请反馈给我,谢谢!

=Start=

缘由:

很早之前就想了解的一个问题,自己也多少知道一些方法,但总觉得应该有多种实现方式/方法,不过一直没机会整理、总结,所以这次先整理一下,等以后各种方法都实践了一遍再更新一下,或是再写一篇。

正文:

参考解答:

实现「进程监控」可以使用的一些现成工具(Bluepill、eye、god、supervisor、Open-Falcon)

Process monitoring tool. Inspired from Bluepill and God. (Ruby)
https://github.com/kostya/eye

simple process monitoring tool (Ruby)
https://github.com/bluepill-rb/bluepill

Ruby process monitor (Ruby)
https://github.com/mojombo/god
http://godrb.com/

monit (C)
https://github.com/arnaudsj/monit

supervisor (Python)
https://github.com/Supervisor/supervisor

Open-Falcon
http://book.open-falcon.org/zh/usage/proc-port-monitor.html

# 端口监控
机器监听的端口可能很多很多,但是真正想做监控的端口可能不多,这会造成资源浪费
目前Open-Falcon还不支持nodata监控,端口挂了不上报数据了,没有nodata机制,是发现不了的

agent通过 ss -tln 命令拿到当前有哪些端口在监听,如果8080在监听,就设置value=1,汇报给transfer,如果发现8081没在监听,就设置value=0,汇报给transfer。

# 进程监控
name是从/proc/$pid/status文件采集的,cmdline是从/proc/$pid/cmdline采集的。这个文件存放的是你启动进程的时候用到的命令,比如你用java -c uic.properties启动了一个Java进程,进程名是java,其实所有的java进程,进程名都是java,那我们是没法通过name字段做区分的。怎么办呢?此时就要求助于这个/proc/$pid/cmdline文件的内容了。

听起来是不是挺复杂的?呵呵,如果你的进程有端口在监听,就配置一个端口监控就可以了,无需既配置端口监控、又配置进程监控,毕竟如果进程挂了,端口肯定就不会监听了。

==

除了使用上面的工具之外,其实自己也可以写一个low一点的,比如:

  • 用C语言先fork()再waitpid(),如果有返回则说明进程挂掉了,则进行通知并再次将进程拉起;
  • 写个crontab任务,定期检查;

 

上面说的是一些工具和方法,原理基本上都是根据进程名去/proc目录下查找、比对status/cmdline这些文件,如果检查的时候有,则说明进程还存活;如果检查的时候没有,则说明进程挂掉了。

有不少地方需要用到这些特性:

  • 监控重要进程的启停情况(比如:rsyslogd……),要实现安全,首先需要有足够强的感知能力;

 

参考链接:

=END=

声明: 除非注明,ixyzero.com文章均为原创,转载请以链接形式标明本文地址,谢谢!
https://ixyzero.com/blog/archives/3939.html

《Linux下应用/进程的存活性监控》上的6个想法

  1. 进程监控、进程命令行监控的数据源(Process monitoring/Process cmd line monitoring – data sources)
    http://www.hexacorn.com/blog/2018/10/27/process-monitoring-process-cmd-line-monitoring-data-sources/
    `
    Windows
     4688 with no cmd line arguments
     4688 with cmd line arguments
     4688 with cmd line arguments & name of the parent process (newer Windows systems)
     Sysmon / 1
     EDR logs
     AV logs
     Local Proxy logs
     Local IDS logs (CIDS)
     DCOM Logs
     WMI Logs
     there are also some ‘indirect’ logs that may indicate some process ran at some stage in the past (most of these listed below include PID, process name) e.g.:
      service creation / start logs
      powershell logs
      WER logs
      Application error logs
      Application hung logs
      App Locker logs
      Restart Manager logs
      Diagnostics-Performance logs
      Firewall logs
      System/change time logs
      System Logon events logs
      Forensic artifacts (if e.g. EDR picks them up — see this excellent reference by @harrisonamj: https://blog.1234n6.com/2018/10/available-artifacts-evidence-of.html …), etc.
      etc.
    Linux
     auditd (see this reference)
      EXECVE
      USER_CMD
      BPRM_FCAPS
      SYSCALL
      ANOM_EXEC
     content of .bash_history retrieved as a snapshot on regular basis
    OSX
     xnumon logs (anyone actually using it?)
     content of .bash_history retrieved as a snapshot on regular basis
    `

  2. 大规模基础agent的管理
    https://mp.weixin.qq.com/s/3CWJYeZc-B6TwVu3PsEt4g
    `
    agent管理平台主要包括 资源管理、部署更新、异常处理、dashboard 4方面。

    # 资源管理
    通过 cgroup 来限制硬件 cpu、mem、disk io、 networkio 的使用,保证agent 占用资源都在预定范围之内;
    通过 ulimit 来限制 最大进程数、文件数,core dump 大小,避免创建大量进程,打开大量文件,造成耗尽系统资源的情况;
    要求 agent内建日志、临时文件清理机制,避免垃圾文件的堆积,消耗系统资源
    通过设置 oom_adj, nice 值,以低优先级运行,当出现资源紧张时,基础agent优先被kill,释放资源;

    # 部署更新
    # 异常处理
    # dashboard
    `

发表评论

电子邮件地址不会被公开。 必填项已用*标注