在 Ubuntu 上监控 Postfix 服务器和 Ruby 响应

发布于 2024-08-02 06:17:47 字数 316 浏览 4 评论 0原文

我正在构建一个 ruby​​ 应用程序,用于抓取发送到服务器的电子邮件并将其记录到数据库中。现在我没有一种方法可以完全测试(电子邮件 -> Ruby -> 数据库)堆栈的停机时间。我正在使用测试运行 ruby​​ 的服务器的停机时间的服务,并且我正在使用 monit 来确保 ruby​​ 守护进程不会停机太长时间。除了定期手动检查之外,我还可以使用任何服务来验证:

1)我的后缀是否仍在运行并接收/发送邮件

2)消息是否仍在从我的守护程序发送到数据库

如果不是,是否有任何最佳实践针对这两种情况之一进行监控和发送警报,或者任何可以可靠工作的家庭酿造方法?

I am building a ruby application that grabs emails sent to a server and logs them to a database. Right now I don't have is a way to fully test the (Email -> Ruby -> Database) stack for downtime. I am using services that test the server the ruby is running on for downtime, and i'm using monit to make sure that the ruby daemon doesn't go down for too long. Besides manually checking periodically, are there any services I can use to verify:

1) Is my postfix still up and receiving/sending mail

2) Are the messages still making it from my daemon to the database

If not, are there any best practices for monitoring and sending alerts for either of those two scenarios, or any home brew methods that could work reliably?

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

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

发布评论

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

评论(3

断桥再见 2024-08-09 06:17:47

您可以让一个 cron 作业发送一条“金丝雀”消息,然后进行另一个 cron 作业测试以查看是否将预期的金丝雀消息写入数据库。 (可选择删除它等)

You could have a cron job send a "canary" message through, and then have another cron job test to see if the expected canary message was written to the database. (optionally deleting it, etc)

孤独岁月 2024-08-09 06:17:47

如果您正在寻找商业工具,www.logicmonitor.com 可以做到。
它具有 Postfix 监控(监控状态,并绘制排队、传递、退回、拒绝等消息的图形)。
还有数据库监控(Mysql、oracle、postgres、sql server)——因此它将对数据库发出警报和趋势,并在需要时提供一些调整建议。
它还可以轻松跟踪诸如上次将电子邮件插入数据库的时间之类的信息 - 并在时间超出预期时发出警报。
另外还可以监视日志文件来跟踪应用程序响应时间。

取决于该系统的重要性以及时间/金钱的权衡。

If you are looking for a commercial tool, www.logicmonitor.com can do that.
It has Postfix monitoring (monitoring status, and graphing messages queued, delivered, bounced, rejected, etc).
Also database monitoring (Mysql, oracle, postgres, sql server) - so it will alert and trend on the database, and provide some advice on tuning if needed.
It can also easily track things like time of last insertion of email into database - and alert if greater time than expected.
Plus monitor log files to track application response times.

Depends on the criticality of this system, and the time/money trade off.

输什么也不输骨气 2024-08-09 06:17:47

我对 Monit 没有经验,但设置这些测试可能是可行的。如果不是,我建议您查看 Nagios - 用于编写您自己的 API测试真的很简单。

测试:

  • SMTP 服务器正在网络上响应。
  • postfix 进程正在运行。
  • 后缀队列为空。

测试往返行程可以使用 DGM 的“金丝雀”建议来完成 - 如果您可以设置这样的例程,它可能具有最佳的精度,并为您提供对错误的最快反应。

如果流量相对频繁,另一种可能有用的方法是监视 postfix 的日志,也可能监视数据库服务器的日志 - 检查最后一条成功的消息是否不早于例如 30 分钟(对于适当的值“30”...和“分钟”...)。这种方法的反应速度会较慢,但会涵盖更多可能的错误情况。

I'm not experienced with Monit, but it might be doable to set up these tests. If it isn't, I'd recommend you have a look at Nagios - the API for writing your own tests is really simple.

Test that:

  • The SMTP server is responding on the network.
  • The postfix processes are running.
  • The postfix queues are empty.

Testing the round-trip could be done with DGMs "canary" suggestion - if you can set up a routine like that it probably has the best precision and gives you the quickest reaction on an error.

An alternative that can be useful if traffic is relatively frequent is to monitor the logs of postfix and possibly the database server - check that the last successful message is no older than for example 30 minutes (for an appropriate value of "30"... and "minutes"...). This approach will be slower to react, but will cover more possible error conditions.

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