江苏龙网

  1. 首页 > 资讯 > 科技 > >

51CTO|如何监控无服务器应用( 二 )


可见 ， 在大多数情况下 ， 我们需要避免出现冷启动现象 。 不过 ， 云服务平台通常不会直接提供针对应用程序栈的冷启动检测和监控 。 我们需要借用Dashbird(https://dashbird.io/features/)之类的监控服务 ， 来发现目标架构中值得改进的地方 。 如果您想了解更多有关如何解决冷启动问题的介绍 ， 请参考--https://dashbird.io/blog/can-we-solve-serverless-cold-starts/ 。
调用错误
有时候 ， 在功能函数接收到调用请求之前 ， 该请求就已经被拒绝了 。 而且 ， 此类调用错误会让Lambda返回400或500系列的HTTP状态代码 。 具体请参见常见错误的列表--https://dashbird.io/knowledge-base/logging/lambda-invocation-function-and-runtime-errors/ ， 或完整的调用错误列表--https://docs.aws.amazon.com/lambda/latest/dg/API_Invoke.html#API_Invoke_Errors 。
通常 ， 典型的企业应用会通过API连接到其他SaaS工具上 ， 如果其中的某个连接或节点出现了问题 ， 则会影响到正常的业务逻辑 。 我们可以通过由Dashbird提供的严重错误仪表板 ， 来快速了解应用程序在第一次和最后一次发生特定瓶颈、或错误的根本原因和具体时间 。
【51CTO|如何监控无服务器应用】费用与使用量
无论是Lambda ， 还是AWS S3存储桶、VPC、DynamoDB等资源 ， 其费用都是与使用量成正比的 。 而我们在使用分布式云服务时 ， 很难有效且及时地跟踪资源在使用过程中所产生的花销 。 因此 ， 在具体实现中 ， 我们往往需要采取以帐户级别监控为主 ， 功能级别监控为辅的方法 。 例如 ， 我们可以使用Dashbird应用来统计从12小时到1个月的时间跨度 ， 按照每隔5分钟抽样一次的详细信息视图 ， 进而发现目标应用中的使用趋势和费用异常 。 如果您想了解更多有关无服务器监控的最佳实践 ， 请参考--https://sls.dashbird.io/en/serverless-best-practices 。
监控工具--AWS CloudWatch
作为Lambda的内置工具 ， AWS CloudWatch会根据功能、版本和容器类型 ， 来组织日志 ， 并在日志中包含运行时、容器错误、以及时间戳 。 当然 ， Lambda也会为每次调用添加各种元数据 。 通过收集和跟踪各类指标 ， CloudWatch日志可以提供有关资源使用情况、应用程序的性能、以及运营状况的等基础架构范围内的视图 。
同时 ， 我们可以使用其自带的AWS Cloudwatch Alarm ， 来设置各种指标警报和复合警报 。 据此 ， 您可以获悉目标应用正在使用的CPU和内容的情况 。 而且 ， 您还可以通过预定义事件来设置门限值 ， 一旦达到或接近该值 ， 就会触发通知 。 因此 ， 我建议您在构建第一个FaaS应用程序时 ， 就将CloudWatch作为监控和跟踪的起点 ， 而当用户和请求数大到一定数量级时 ， 再引入更加全面的工具 。
问题管理与团队合作
任何云端应用程序 ， 即使是最简单的 ， 也会频繁地产生一定数量的事件与问题 ， 尤其是那些正在不断开发与迭代的应用 。 因此 ， 为了能让开发团队有效地获悉和解决问题 ， 监控平台需要以用户友好的方式 ， 可视化和控制各种未解决、已解决、暂时可以被忽略的问题 。 通过设置和提供清晰的工作流程 ， 团队将能够更流畅地沟通 ， 并提出切实可行的解决方案 。
质量跟踪
在监控过程中 ， 快速可视化某个事件在过去所发生过的状况是非常重要的 。 它不但能够帮助我们就某种情况开展进一步的调查 ， 还可以协助我们发现针对某个错误的修复方法 。 通过此类回溯性的质量跟踪 ， 我们可以避免在初始开发和错误纠正的过程中犯同样的错误 ， 同时也能通过创建持续的自动化学习和评估方法 ， 来提高应用的质量与性能 。
事件驱动的调试
开发人员虽然是监控程序的创建者 ， 但是他们并没有责任在生产环境中持续监控自己的应用日志 。 那么面对大量的应用日志 ， 监控系统就需要能够在不错过关键内容的前提下 ， 提供自动化的警报服务 。 也就是说 ， 我们需要通过自定义警报功能 ， 来成功实现监控和错误调试 。


推荐阅读


上一篇：小胖聊数码|牢记华为手机“三不买”原则，不花冤枉钱，选错要吃亏！

下一篇：手机|二手电商平台现国货手机代替iPhone趋势