随着大量物联网场景开始涌现，海量碎片化设备和巨量时序数据给物联网平台带来了一系列新的要求和新的技术挑战。
监控运维的技术挑战
灵活多变的监控需求
物联网平台监控场景面临的是上亿级别的海量设备，相比传统的IT运维，被监控的对象数量增加了好几个数量级。随着业务的飞速发展，面对平台动辄数十亿甚至百亿级别时序数据，我们该如何有效的监控与管理?而随着物联网时序数据量爆发式的增长，传统的线图、直方图、散点图等数据展示方法，很难直接让运维人员找到数据背后的异常或隐藏瓶颈。如何针对不同业务或者不同监控对象，找到更合适的数据看板以及展现形式，成为物联网平台必须解决的问题。
PB级日志数据分析处理
物联网平台是一个复杂的分布式系统，设备消息上下行、设备控制链路都非常复杂，涉及到了非常多的云端系统。而传统的日志信息也往往有多个来源，例如营销活动打点、用户访问、应用日志，并且来自于ECS服务器、容器、移动端、网页端等多种渠道，需要多渠道、多维度、多种处理方法。
物联网场景中日志系统面临着极大的规模挑战，面对上亿在线的设备所产生的数据，系统应具备利用这些日志快速解决问题的能力，这也就要求系统能处理大量数据，且实时性要求高。同时，为了充分发掘日志内容的业务价值，需要结合设备运维场景对多渠道日志做全面分析，监控异常设备指标，定位系统问题，分析出相应的异常调用链路。
海量设备监控运维的技术方案
☞ 自定义监控大盘
传统的物联网平台提供了诸如实时在线设备、上下行消息总量、规则引擎消息流转次数等有限几个系统指标，只能满足客户的基本运维需求。客户根据不同的业务需求，需要监控的数据指标往往存在差异，传统的实时监控指标很难满足客户的日常运维需求。
物联网平台的自定义监控大盘提供了设备、消息、物模型、规则引擎和OTA升级相关指标数据的实时监控服务，指标维度可以选择物联网平台的所有产品或指定的单个产品，指标聚合支持最小、最大和平均等聚合方法，聚合粒度可选择不 同的时间频率，基本满足了客户日常运维的刚性需求。
为保证客户最佳的实时监控使用体验，这里主要通过以下几个关键技术，解决实时监控所面临的数据规模和个性化所带来的技术挑战:
1) 链路的规范性
数据平台对ODPS离线数据和SLS实时数据进行实时筛选、合并和计算，统一计算后将结果输出给云监控，从而实现了系统指标和用户自定义指标数据链路和指标计算的统一性。
2) 计算的实时性
数据平台引入实时数仓Hologres，对衍生指标和原始指标建立了全局加速表，实现了数据的全链路实时化改造，通过Flink将指标聚合计算做到了秒级延时，将原来报表的展示延时从30秒下降到1秒以内。
3) 诊断的联动性
针对大盘指标提供了可配置可组合的下钻能力，帮助精准圈选出故障相关的异常数据，让数据下钻和后续算法平台输出的根因分析模型形成了联动，既可以帮助发现数据共性，同时还能缩小后续故障分析中的数据计算量，一定程度上提高计算效率。
☞ 消息轨迹监控
消息轨迹解决了上下行链路中问题定位的难题，客户可根据TraceID或MessageId，追踪任意一条消息在物联网平台流转的全路径，还可根据出现的故障节点快速分析、定位问题。为保证最佳的链路诊断使用体验，这里主要通过以下几个关键技术，解决消息轨迹所面临的日志存储成本、时序错位和查询性能瓶颈所带来的技术挑战:
1) 链路业务抽象
物联网平台是一个复杂的分布式系统，设备数据上报、下行控制链路都非常复杂，涉及到了云端非常多的内部系统，这些复杂度无需暴露给用户，用户无法理解，对问题分析也会存在干扰。另外，系统内部的日志输出内容较多占用了非常多的存储，格式本身也不统一，随时可能存在变化，从而无法针对日志做深入的分析。
为消除用户的理解成本，在分布式链路中，物联网平台梳理出了消息上下行链路中的关键系统，按照日志聚合规范输出了关键调用节点信息，面向客户可理解的业务原语输出了诊断信息，帮助客户快速识别出链路上的异常节点，并根据错误码的提示进行问题诊断和修复。
2) 推断链路时序
全链路租户日志信息来自于多个不同的分布式系统，打印日志的时间戳非常接近，消息轨迹采集的是按规范输出的业务日志，将系统、模块之间的调用逻辑顺序通过规则配置沉淀下来，通过TraceId或MessageId获取具体租户业务日志时，可以根据逻辑顺序重新绘制出调用链路时序，而无需依赖时间戳。
3) 提升查询性能
租户日志虽然是针对业务特性精简过的日志，但物联网平台上下行链路每天都会产生巨大的日志量(PB级别)，考虑到日志存储成本当前物联网平台只会存储7天的租户日志，即使这样，在所有的租户日志中查询一条特定链路的信息也面临精准性和性能的挑战。针对租户日志查询条件，平台对字段进行了索引加速查询性能，同时也支持用户将租户日志导出到自己的SLS空间长期保存。
阿里云IoT物联网平台性能指标
