云服务很长一段时间以来都不会成功通知脚本
我有一个python脚本,该脚本位于VPS上,读取(每个小时)的财务新闻,并在出现某些感兴趣的关键字时向我发送电子邮件。每周只会发生几次,但是这样的事件非常重要,不得错过。在任何数据获取或解析错误时,还应通过电子邮件通知我,并且错误当然会记录到服务器的本地日志文件中。
但是,我怎么知道我的SMTP凭据不会被邮件提供商阻止,或者我的副总裁不会被我的董事会关闭呢?在这种情况下,直到我决定手动登录VP并查看日志之前,我将不会被通知,并且不会意识到重要事件(以及未能获取/交付它们)。
即使我会使用备份通知渠道,例如,SMS或电报,它仍然不会防止云提供商服务中断,或者由于临时付款问题而被阻止我的帐户,因为脚本没有实例来交付脚本的实例任何频道上的消息。这就是为什么我怀疑需要某些三方耐受耐受性服务的原因。尤其是如果我是一个有很多类似脚本的自由编码器,则可以使用VPS,无服务器/lambdas的混合物运行,可能是针对不同最终客户端的。
当某些脚本在足够长的时间内没有成功时,您亲爱的开发人员使用的最佳实践是什么?我想要一些可靠且现成的东西,也许您可以推荐一些现有的监视服务。至少我找不到那些立即解决我的特定问题的监视服务。
要澄清,我不想花时间进行一些手动检查,直到绝对必要(在这种情况下,我可以容忍最多2个小时,如果在那个时期内没有自我启动,那么我需要通知我),我显然不想得到定期的烦人报告,说这项服务很好,没有发现有趣的消息。另外,我当然想保持成本合理。
I have a python script that resides on a VPS, reads (each hour) financial news from a public datafeed and emails me when certain keywords of interest appear. That can happen only a few times a week, but such events are very important and must not be missed. On any data fetching or parsing error, I should also be notified via email, and errors of course get recorded into the server's local log file.
But how do I know that my smtp credentials are not blocked by the mail provider, or my VPS is not shut down by my hoster? In that case, I would not be notified and would be unaware of important events (and the failure to fetch/deliver them itself) until I decided to log into VPS manually and take a look at the logs.
Even if I would use a backup notification channel, e.g., SMS or Telegram, it still would not protect against cloud provider service disruption, or my account being blocked due to temporary payment issues, as there would exist no instance of the script to deliver the message on any of the channels. That's why I suspect some 3rd party fault-tolerant service is needed. Especially if I'm a freelance coder having lots of similar scripts, running on a mixture of VPSes, serverless/Lambdas, possibly for different end clients.
What is the best practice you dear developers are using to be notified when some script has not succeeded for a long enough time? I would like something reliable and ready-to-use, maybe you can recommend some existing monitoring services. At least I was not able to find the ones that solve my particular problem straight away.
To clarify, I don't want to spend time on some manual checking until it's absolutely necessary (in this case, I can tolerate up to 2 hours, and if it does not self-heal within that period, then I need to be notified), and I obviously don't want to get regular annoying reports that the service is doing fine and there simply were no interesting news detected. Plus, I of course want to keep the costs reasonable.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论