之所以在生产环境使用开源全链路监控方案存在这么大挑战，是因为这些方案本身缺乏大规模实际业务场景的验证。对于技术实力非常强的互联网企业，会有专门的技术团队负责全链路监控项目，在使用开源产品的过程中如果遇到任何问题，都可以通过自身的技术实力进行修复和弥补。但对于绝大多数使用者而言，这些挑战所带来的都是漫长而痛苦的体验。
修改完应用启动命令后，对应用进行重启，就能够成功接入ARMS。如果在1分钟后，ARMS控制台的应用列表能够看到新的应用，就代表接入成功。
JVM监控功能通过可视化页面展示应用的GC情况、内存详情、线程详情，完全可以代替JStat、JStack等JDK自带的JVM分析工具。同样，在以时间为横坐的曲线图处，可以继续选中一个时间段进行下钻分析。
在国外，有一个名为Instagram的照片分享软件，这个软件早期并没有火起来，后来他们通过数据分析发现了一个非常强硬的用户需求点，即“纯粹拍照并分享”。
定好目标后，一定要了解产品背后的数据质量。关于数据质量，公司内部、部门之间的指标定义各不相同，不过普遍存在数据不准、没有数据、数据脏乱差、易用性差等问题。如何解决？其实，数据中包含着业务需求，需求弄清楚了才会转化到埋点设计，埋点方案再转化为具体的研发。
不同终端都有一个ID是长期关系，后面都会用相同的逻辑和体系进行标注，只要维护好需求、事件命名，以及业务层级ID，最终采集到的数据质量是非常好的。
这种AI架构的问题在于，许多设备可能开始超载网络流量，或者您可能正在使用已经大量使用的网络。在这些情况下，将数据发送回中央服务器会导致处理时间过长，这是令人无法接受的。这是Edge AI发挥其价值的地方，因为可以在硬件设备上本地执行较不复杂的机器学习和AI流程。
API 应该是被优先设计的：我们知道用户需求是复杂多变的，比如从桌面到移动端，应用的展现方式和操作流程都有可能不同；然而业务逻辑的概念模型和服务交互是相对稳定的。相对而言，API 的接口是更加稳定的，而具体的实现是可以迭代实现和持续变化的。定义良好的 API 可以更好保障应用系统的质量。
但是 EDA 架构依然存在很多挑战。
1、分布式的松耦合架构大大增加了应用基础设施的复杂性。基于云的部署交付方式和云服务（消息队列、函数计算服务等）可以使得该架构的稳定性，性能和成本效益进一步提高。
最明显的就是小文件问题，用批量数据通道写特别碎的数据进来会产生大量的碎片文件，跑SQL查询就会非常慢，用Tunnel下载也会非常慢。
