我们传递的数据包括了调用基本信息（requestContext：异步请求ID、请求的函数、请求结果以及异步调用次数）、异步调用输入 （requestPayload），调用结果信息（responseContext：调用状态码以及函数错误）以及异步调用函数输出（responsePayload）。
这些数据覆盖了异步函数从输入到执行输出的大部分信息，可以在 Destination 目标中使用。
先说说从一个工程师的角度看到的变化：对一个工程师而言，5年前的工作是非常细分的，研发的工作就是把代码开发好。
并且为了保障我们的业务是持续改进的，必须在工作中涉及到更多运营的因素，例如统计系统访问、留存和体验等情况。
但业务的高要求需要在各个环节中承担更大的Scope，从多个视角来看待问题。背后就会有大量、碎片化的数据分析工作。
所以我们可以看到，虽然各个场景角色不同，数据源不同，但在机制上我们是可以建立一套系统性分析框架来承载这类可观察性的需求的。
平台始终向用户提供支撑能力，兼容各种数据源与协议，支撑业务但不做业务产品。
例如用户在1小时内做了5次操作，我们可以把这5次操作的日志或Trace捕捉下来。
例如在原始日志中，只有一个project_id字段在访问url参数里，ip这个字段对应的设计我们无法拿到。在SLS的DSL语言中，我们只需要写3行代码，
以及通过AI来进行运维与用户增长，方法都是通用的。和AI所在的任何一个领域一样，数据是根本、算力是基础、算法是核心，缺一不可。
