为什么移动应用程序向 ELK 发送崩溃日志并不流行

Question

我正在 IOS 和 Android 上开发移动应用程序。目前我使用 Firebase Crashlytic 来跟踪应用程序崩溃日志。

我对 Crashlytic 的功能不太满意。例如，当用户报告问题并在特定时间录制应用程序崩溃的视频时，我希望看到该时间附近设备的日志，但这对于 Crashlytic 来说并不容易。

我脑海中弹出一个解决方案，让移动应用程序将崩溃日志发送到我的 AWS SQS 队列，并以某种方式将其传递到 Elasticsearch，以便我可以使用 Kibana 过滤日志。

我想实现这样的事情

1. 移动应用程序将所有内容记录到可旋转的临时文件中。
2. 当满足以下条件时，将日志从文件发送到SQS队列。

• 在显示任何错误弹出窗口之前
• 发生任何应用程序崩溃事件后
• 当 API 在 X 秒后没有响应时

4. 如果在2.发送日志的过程中发现任何错误，设置flagretry_send_error=true在内存中设置标志。
5. 在任何可能的应用程序事件中，如果发现retry_send_error==true在内存中发现该事件，请尝试再次发送日志。
6. 创建一个 lambda 监听 SQS 队列并将日志发送到 LogStash 或 Elasticsearch。

我一直在互联网上寻找一些参考示例，但找不到任何好的示例。所以我怀疑我的解决方案可能有问题。

如果您知道一些与此类似的架构的好例子，或者您知道这个解决方案不那么受欢迎的原因，请帮助建议。

Answer 1

你想解决这个问题的方式基本上还不错。但在我看来ELK并不正是你想要的。

SQS + Lambda是聚合和过滤大量公共请求的好主意，但在安全性或效率（或可能是成本）方面存在一些问题。其架构一点也不简单。

但是，如果我可以推荐Sentry.io，这正是您需要的工具，因为我正确理解了问题。

Sentry 也有针对移动、Android和iOS的解决方案。

我确实使用哨兵来做不同的事情，并且有一个清晰可读的界面可以使用。通过最少的代码分配，您可以标记事件，抛出良好的异常进行过滤，然后哨兵解决其余问题。