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

Question

我正在开发 IOS 和 Android 上的移动应用程序。目前我使用 Firebase Crashlytic 来跟踪应用程序崩溃日志。
我对使用 Crashlytic 能做的事情不太满意。例如，当用户报告问题并有视频记录应用程序在特定时间崩溃时，我想查看当时设备的日志，但使用 Crashlytic 并不容易。
我想到了一个解决方案，让移动应用程序将崩溃日志发送到我的 AWS SQS 队列并以某种方式将其传递给 Elasticsearch，以便我可以使用 Kibana 过滤日志。
我想实现这样的东西

移动应用程序将所有内容记录到可旋转的临时文件中。

当满足以下条件时，将日志从文件发送到 SQS 队列。

在显示任何错误弹出窗口之前

在任何应用程序崩溃事件后

当 API 在 X 秒后没有响应时

2.如果在发送日志的过程中发现任何错误，设置标志retry_send_error=true在内存中。

在任何可能的应用程序事件中，如果发现 retry_send_error==true在内存中，尝试再次发送日志。

创建一个监听 SQS 队列的 lambda 并将日志发送到 LogStash 或 Elasticsearch。

我一直在互联网上搜索一些引用示例，但找不到任何好的。所以我怀疑我的解决方案可能有问题。
请帮助建议您是否知道一些与此类似的架构的好示例，或者您是否知道该解决方案不那么受欢迎的原因。

Answer 1

你想解决这个问题的方式基本上还不错。
但在我看来麋鹿 不正是你想要的。
SQS + Lambda 聚合和过滤大量公共(public)请求是一个好主意，但在安全性或效率(或成本)方面存在一些问题。
它的架构一点也不简单。
但是，如果我可以推荐 sentry.io ，这正是您需要的工具，因为我正确理解了这个问题。
哨兵有mobile的解决方案, android和 iOS也。
我确实将哨兵用于不同的事情，并且有一个清晰可读的界面可以使用。使用最少的代码分配，您可以标记事件，抛出好的异常进行过滤，而哨兵解决其余的问题。