调试监控

发布于 2024-09-12 01:12:57 字数 268 浏览 4 评论 0原文

我发现调试 monit 是一件很痛苦的事情。 Monit 的 shell 环境基本上什么都没有(没有路径或其他环境变量)。另外,我找不到日志文件。

问题是,如果 monit 脚本中的启动或停止命令失败,则很难辨别出问题所在。很多时候,它并不像在 shell 上运行命令那么简单,因为 shell 环境与 monit shell 环境不同。

人们使用哪些技术来调试监控配置?

例如,我很乐意拥有一个 monit shell 来测试我的脚本,或者一个日志文件来查看出了什么问题。

I find debugging monit to be a major pain. Monit's shell environment basically has nothing in it (no paths or other environment variables). Also, there are no log file that I can find.

The problem is, if the start or stop command in the monit script fails, it is difficult to discern what is wrong with it. Often times it is not as simple as just running the command on the shell because the shell environment is different from the monit shell environment.

What are some techniques that people use to debug monit configurations?

For example, I would be happy to have a monit shell, to test my scripts in, or a log file to see what went wrong.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(7

旧人 2024-09-19 01:12:57

我也遇到过同样的问题。使用 monit 的详细命令行选项会有所帮助,但我发现最好的方法是创建一个与 monit 环境尽可能相似的环境,并从那里运行启动/停止程序。

# monit runs as superuser
$ sudo su

# the -i option ignores the inherited environment
# this PATH is what monit supplies by default
$ env -i PATH=/bin:/usr/bin:/sbin:/usr/sbin /bin/sh

# try running start/stop program here
$

我发现最常见的问题与环境变量相关(尤其是 PATH)或与权限相关。您应该记住 monit 通常以 root 身份运行。

另外,如果您在 monit 配置中使用 as uid myusername ,那么您应该在执行测试之前更改为用户 myusername

I've had the same problem. Using monit's verbose command-line option helps a bit, but I found the best way was to create an environment as similar as possible to the monit environment and run the start/stop program from there.

# monit runs as superuser
$ sudo su

# the -i option ignores the inherited environment
# this PATH is what monit supplies by default
$ env -i PATH=/bin:/usr/bin:/sbin:/usr/sbin /bin/sh

# try running start/stop program here
$

I've found the most common problems are environment variable related (especially PATH) or permission-related. You should remember that monit usually runs as root.

Also if you use as uid myusername in your monit config, then you should change to user myusername before carrying out the test.

无力看清 2024-09-19 01:12:57

在让 monit 处理一切之前,请务必仔细检查您的配置并手动监视您的进程。 sysstat(1)、top(1) 和 ps(1) 是您了解资源使用情况和限制的好帮手。了解您监控的过程也很重要。

关于启动和停止脚本,我使用包装脚本来重定向输出并检查环境和其他变量。像这样的事情:

$ cat monit-wrapper.sh

#!/bin/sh
{
  echo "MONIT-WRAPPER date"
  date
  echo "MONIT-WRAPPER env"
  env
  echo "MONIT-WRAPPER $@"
  $@
  R=$?
  echo "MONIT-WRAPPER exit code $R"
} >/tmp/monit.log 2>&1

然后在 monit 中:

start program = "/home/billitch/bin/monit-wrapper.sh my-real-start-script and args"
stop program = "/home/billitch/bin/monit-wrapper.sh my-real-stop-script and args"

您仍然必须弄清楚您想要在包装器中包含哪些信息,例如进程信息、id、系统资源限制等。

Be sure to always double check your conf and monitor your processes by hand before letting monit handle everything. systat(1), top(1) and ps(1) are your friends to figure out resource usage and limits. Knowing the process you monitor is essential too.

Regarding the start and stop scripts i use a wrapper script to redirect output and inspect environment and other variables. Something like this :

$ cat monit-wrapper.sh

#!/bin/sh
{
  echo "MONIT-WRAPPER date"
  date
  echo "MONIT-WRAPPER env"
  env
  echo "MONIT-WRAPPER $@"
  $@
  R=$?
  echo "MONIT-WRAPPER exit code $R"
} >/tmp/monit.log 2>&1

Then in monit :

start program = "/home/billitch/bin/monit-wrapper.sh my-real-start-script and args"
stop program = "/home/billitch/bin/monit-wrapper.sh my-real-stop-script and args"

You still have to figure out what infos you want in the wrapper, like process infos, id, system resources limits, etc.

风筝在阴天搁浅。 2024-09-19 01:12:57

您可以通过将 MONIT_OPTS="-v" 添加到 /etc/default/monit 来以详细/调试模式启动 Monit(不要忘记重新启动;/ etc/init.d/monit restart)。

然后,您可以使用 tail -f /var/log/monit.log 捕获输出

[CEST Jun  4 21:10:42] info     : Starting Monit 5.17.1 daemon with http interface at [*]:2812
[CEST Jun  4 21:10:42] info     : Starting Monit HTTP server at [*]:2812
[CEST Jun  4 21:10:42] info     : Monit HTTP server started
[CEST Jun  4 21:10:42] info     : 'ocean' Monit 5.17.1 started
[CEST Jun  4 21:10:42] debug    : Sending Monit instance changed notification to [email protected]
[CEST Jun  4 21:10:42] debug    : Trying to send mail via smtp.sendgrid.net:587
[CEST Jun  4 21:10:43] debug    : Processing postponed events queue
[CEST Jun  4 21:10:43] debug    : 'rootfs' succeeded getting filesystem statistics for '/'
[CEST Jun  4 21:10:43] debug    : 'rootfs' filesytem flags has not changed
[CEST Jun  4 21:10:43] debug    : 'rootfs' inode usage test succeeded [current inode usage=8.5%]
[CEST Jun  4 21:10:43] debug    : 'rootfs' space usage test succeeded [current space usage=59.6%]
[CEST Jun  4 21:10:43] debug    : 'ws.example.com' succeeded testing protocol [WEBSOCKET] at [ws.example.com]:80/faye [TCP/IP] [response time 114.070 ms]
[CEST Jun  4 21:10:43] debug    : 'ws.example.com' connection succeeded to [ws.example.com]:80/faye [TCP/IP]

You can start Monit in verbose/debug mode by adding MONIT_OPTS="-v" to /etc/default/monit (don't forget to restart; /etc/init.d/monit restart).

You can then capture the output using tail -f /var/log/monit.log

[CEST Jun  4 21:10:42] info     : Starting Monit 5.17.1 daemon with http interface at [*]:2812
[CEST Jun  4 21:10:42] info     : Starting Monit HTTP server at [*]:2812
[CEST Jun  4 21:10:42] info     : Monit HTTP server started
[CEST Jun  4 21:10:42] info     : 'ocean' Monit 5.17.1 started
[CEST Jun  4 21:10:42] debug    : Sending Monit instance changed notification to [email protected]
[CEST Jun  4 21:10:42] debug    : Trying to send mail via smtp.sendgrid.net:587
[CEST Jun  4 21:10:43] debug    : Processing postponed events queue
[CEST Jun  4 21:10:43] debug    : 'rootfs' succeeded getting filesystem statistics for '/'
[CEST Jun  4 21:10:43] debug    : 'rootfs' filesytem flags has not changed
[CEST Jun  4 21:10:43] debug    : 'rootfs' inode usage test succeeded [current inode usage=8.5%]
[CEST Jun  4 21:10:43] debug    : 'rootfs' space usage test succeeded [current space usage=59.6%]
[CEST Jun  4 21:10:43] debug    : 'ws.example.com' succeeded testing protocol [WEBSOCKET] at [ws.example.com]:80/faye [TCP/IP] [response time 114.070 ms]
[CEST Jun  4 21:10:43] debug    : 'ws.example.com' connection succeeded to [ws.example.com]:80/faye [TCP/IP]
榆西 2024-09-19 01:12:57

monit -c /path/to/your/config -v

monit -c /path/to/your/config -v

谁把谁当真 2024-09-19 01:12:57

默认情况下,monit 会记录到您的系统消息日志中,您可以在那里查看发生了什么。

此外,根据您的配置,您可能会登录到不同的位置

tail -f /var/log/monit

http://mmonit。 com/monit/documentation/monit.html#LOGGING

假设默认值(无论我使用什么旧版本的 monit),您可以这样跟踪日志:

CentOS:

tail -f /var/log/messages

Ubuntu:

tail -f /var/log/syslog

Mac OSX

tail -f /var/log/system.log

Windows

这里是 Dragons

但我在出于病态的好奇心搜索如何做到这一点时发现了一个 neato 项目:https://github.com/derFunk/monit-windows-agent

By default, monit logs to your system message log and you can check there to see what's happening.

Also, depending on your config, you might be logging to a different place

tail -f /var/log/monit

http://mmonit.com/monit/documentation/monit.html#LOGGING

Assuming defaults (as of whatever old version of monit I'm using), you can tail the logs as such:

CentOS:

tail -f /var/log/messages

Ubuntu:

tail -f /var/log/syslog

Mac OSX

tail -f /var/log/system.log

Windows

Here be Dragons

But there is a neato project I found while searching on how to do this out of morbid curiosity: https://github.com/derFunk/monit-windows-agent

提笔落墨 2024-09-19 01:12:57

是的,monit 不太容易调试。

这里有一些最佳实践,

  • 使用包装器脚本来设置日志文件。当你在其中写下你的命令参数时:

shell:

#!/usr/bin/env bash

logfile=/var/log/myjob.log
touch ${logfile} 
echo $ ": ################# Starting " $(date) "########### pid " $ >> ${logfile}

echo "Command: the-command $@" >> ${logfile} # log your command arguments
{
  exec the-command $@
} >> ${logfile} 2>&1

这很有帮助。

我发现另一件有帮助的事情是使用“-v”运行 monit,这会给你带来冗长的信息。因此,工作流程是

  • 让你的包装器从 shell“sudo my-wrapper”开始工作
  • ,然后尝试从 monit 开始工作,使用“-v”从命令行运行,
  • 然后尝试从 monit 开始工作,在后台运行。

Yeah monit isn't too easy to debug.

Here a few best practices

  • use a wrapper script that sets up your log file. Write your command arguments in there while you are at it:

shell:

#!/usr/bin/env bash

logfile=/var/log/myjob.log
touch ${logfile} 
echo $ ": ################# Starting " $(date) "########### pid " $ >> ${logfile}

echo "Command: the-command $@" >> ${logfile} # log your command arguments
{
  exec the-command $@
} >> ${logfile} 2>&1

That helps a lot.

The other thing I find that helps is to run monit with '-v', which gives you verbosity. So the workflow is

  • get your wrapper working from the shell "sudo my-wrapper"
  • then try and get it going from monit, run from the command line with "-v"
  • then try and get it going from monit, running in the background.
撩发小公举 2024-09-19 01:12:57

您还可以尝试在进程运行后运行 monit validate,以尝试找出其中是否有任何问题(如果有任何问题,有时会获得比在日志文件中获得的信息更多的信息)。除此之外,您无能为力。

You can also try running monit validate once processes are running, to try and find out if any of them are having problems (and sometimes get more information than you would get in the log files if there are any problems). Beyond that, there's not much more you can do.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文