- 综合排序
- 最热优先
- 最新优先
- 来自专栏程序员阿常
【职场经验·分享】之【资源需求上报】
关键词——职场、资源需求、及时上报 【回顾】 工作背景: ——「A 项目测试环境的搭建」依赖于某些硬件设备，这些硬件设备由 B 部门协调负责，A项目 PM 多次催促 B 部门提供硬件设备，B部门虽然口头答应了 【反思】 存在问题: ——「硬件设备缺失」属于影响项目进度的关键因素，A 项目 PM 在第一次推动 B 部门协调设备未果后就应该及时上报，而不是多次无效催促，严重影响项目进度。 01.邮件向领导提出资源需求申请 ——PM 将资源需求通过邮件形式上报领导，附上「项目信息、资源需求、对接人、优先级别、期望交付日期」，由领导去协调资源。 03.有进度延迟风险，及时上报领导 ——在影响项目进度的问题上，态度必须要强势，提前识别到了风险就要及时有效去消除风险。自己推不动的问题一定要及时抛给上层领导去协调。 【讨论】 大家觉得遇到跨部门资源需求，该怎么推动比较有效？
50920编辑于 2022-07-01 - 来自专栏Vue源码 & 前端进阶体系
【前端监控】静态资源测速&错误上报
小东西快快学快快记，大知识按计划学，不拖延 继续监控内容总结，今天总结的是前端如何监控静态资源的加载情况，并进行数据上报 本文分为3个部分 1、监控静态资源重要性 2、静态资源测速上报 3、静态资源出错上报 从 performance.getEntries 获取的资源列表中，无法判断资源是否加载成功失败 我们这部分只负责上报 资源的 加载速度，错误的资源不应该包含在内，所以需要剔除发生错误的资源。 上报 window.onload() 会在页面完全载入（包括静态资源完成）后触发，所以在这里可以上报一波 2、监听资源加载 再逐个上报 前面总体上报了一波之后，动态增加的资源，可以动态单个上报 5基本流程 可能画得不太规范，但是样子大概是这样 静态资源出错上报 上面我们对资源的加载速度数据进行了上报，我们还需要对错误的资源进行上报 因为 速度 和 错误 不是一个维度的数据，所以我们需要分开上报 1基本原理 之前监听图片错误用于剔除资源测速上报，就是插在这里处理的，并不会监听两次。
5.1K20发布于 2021-09-09 - 来自专栏嵌入式、安防、流媒体、AI分析
电网企标B接口接入记录（二）：资源上报
区别于国标28181不同点 B接口要求设备注册完毕后，已通知的方式上报平台设备自身的资源信息. 摘自原文： 前端系统加电启动并初次注册成功后，应向平台上报前端系统的设备资源信息（包括：视频服务 器、 DVR/DVS 、摄像机、告警设备、环境量采集设备等模拟或数字信号采集设备信息）。 前端系统上报的设备资源信息采用 SIP 的 NOTIFY 消息，消息体应采用 XML 进行封装。 前端系统在上报资源信息时，应按照逐级发送的方式，发送的资源信息记录建议组合成小于 MTU 尺寸的封包进行上报，也允许单个分批的发送方式。 上报流程 参考sip信令 设备to平台 NOTIFY sip:010090000000000000@111.203.3.78:21112;transport=UDP SIP/2.0 From
44410编辑于 2023-01-04 - 来自专栏TSINGSEE青犀视频
EasyGBS支持国密GB35114协议
EasyGBS作为深耕国标GB28181/RTSP/RTMP/ONVIF视频联网领域的核心平台，全面深度支持GB35114国密协议，并非简单的功能叠加，而是从底层架构重构安全能力，既兼顾与原有GB/T 一、破解合规痛点，筑牢政策落地“安全基石”EasyGBS全面支持GB35114协议，彻底破解了这一行业痛点，其核心价值在于实现“低成本合规、快速达标”。 一方面，平台原生嵌入GB35114协议，无需改造前端监控设备、无需重构现有系统，即可直接对接支持国密协议的摄像头、NVR等设备，同时兼容原有GB/T 28181设备，实现新旧系统平滑过渡，大幅降低企业合规改造成本与时间成本 二、重构安全体系，守住关键领域“安全底线”在接入安全层面，EasyGBS基于GB35114协议的SM2数字证书机制，实现平台与前端设备的双向身份认证，只有通过合法认证的设备才能接入平台，彻底杜绝仿冒设备 EasyGBS对国密GB35114的支持，其深远意义在于推动了行业对“安全”这一概念的认知重塑。以往，安全建设常被视为增加预算、降低效率的“成本中心”。
20710编辑于 2026-02-24 - 来自专栏RTSP/RTMP直播相关
国网B接口资源上报(Push_Resourse)接口描述和消息示例
前端系统上报的设备资源信息采用SIP的NOTIFY消息，消息体应采用XML进行封装。 前端系统在上报资源信息时，应按照逐级发送的方式，发送的资源信息记录建议组合成小于MTU尺寸的封包进行上报，也允许单个分批的发送方式（分批次NOTIFY上去）。资源上报属于数据接口。 接口流程图片主要功能流程如下：a） F1：注册成功后，前端系统向其注册平台首次发送上报资源信息的 SIP 消息。b） F2：平台确认，发送 200 OK 响应。 c） F3：前端系统向其注册平台第二次发送上报资源信息的 SIP 消息。d） F4：平台确认，发送 200 OK 响应。 (Push_Resourse)接口描述和消息示例，国网B接口的资源上报，有点类似于GB28181的设备目录查询(Catalog)，只是GB28181的Catalog是平台端发起，然后接入端响应并上报的，
69530编辑于 2022-10-25 - 来自专栏简易现代魔法
Prometheus 上报和查询
数据上报 # 在 Prometheus 内部，所有的采样样本都是以时间序列的形式保存在时序数据库中，但为了方便理解和使用，Prometheus 定义了 4 种数据上报的类型，用户可以根据上报的数据内容选择合适的接口 Add(float64) } 用户可以调用 Inc 接口进行上报数据 +1，也可以调用 Add 接口增加任意的值（必须为非负数）。 如前所述，Prometheus 将数据拆分为不同监控指标名和不同的维度，我们上报的值具体属于哪个监控指标要如何指定呢？ Observe(float64) } 与前面提到的两个上报模式不同，在 counter 中，一个 counter 对应了一个时间序列，我们创建一个 counter 然后用这个 counter 上报数据， 由于 histogram 的分位数是在 PromQL 中指定的，因此它的灵活性比 summary 高（summary 只能获取上报时定下来的分位数）。
1.6K20编辑于 2023-10-20 - 来自专栏IMWeb前端团队
滚动上报实现
scroll 那还不简单，直接监听列表元素的scroll事件，然后上报呗： $list.on('scroll', () => { let itemHeight = $list.find('li'). Math.ceil(scrollTop/itemHeight); // report count... }); 想必聪明的你一看就知道有点问题： scroll事件触发的那么频繁，尽管加上节流也上报了很多次无用数据 首屏的列表卡片曝光个数并没有上报，需要额外地手动触发一次scroll事件 beforeunload 为了避免不必要的上报，我想只在页面卸载的时候上报一次数据应该就可以了吧，于是我就尝试了beforeunload 思前想后，还是在上报次数上折中，决定尝试失焦事件。 $(document.body).on('focusout', () => { if (maxCount > reportedCount) { // 只需上报最大值即可 // report
83420发布于 2019-12-04 - 来自专栏IMWeb前端团队
滚动上报实现
scroll 那还不简单，直接监听列表元素的scroll事件，然后上报呗： $list.on('scroll', () => { let itemHeight = $list.find('li'). Math.ceil(scrollTop/itemHeight); // report count... }); 想必聪明的你一看就知道有点问题： scroll事件触发的那么频繁，尽管加上节流也上报了很多次无用数据 首屏的列表卡片曝光个数并没有上报，需要额外地手动触发一次scroll事件 beforeunload 为了避免不必要的上报，我想只在页面卸载的时候上报一次数据应该就可以了吧，于是我就尝试了beforeunload 思前想后，还是在上报次数上折中，决定尝试失焦事件。 $(document.body).on('focusout', () => { if (maxCount > reportedCount) { // 只需上报最大值即可 // report
1.1K70发布于 2018-01-08 - 来自专栏向治洪
Flutter异常监测与上报
Sentry方案 Sentry是一个商业级的日志管理系统，支持自动上报和手动上报两种方方。 ，因为可以立即定位并修复问题，线上遇到的问题才需要进行上报，因此在进行异常上报时还需要区分开发环境和线上环境。 接入Bugly时，只需要完成一些前置应用信息关联绑定和 SDK 初始化工作，就可以使用 Dart 层封装好的数据上报接口去上报异常了。 可以看到，对于一个应用而言，接入数据上报服务的过程，总体上可以分为两个步骤： 初始化 Bugly SDK； 使用数据上报接口。 考虑到数据上报是整个应用共享的能力，因此我们将数据上报类 FlutterCrashPlugin 的接口都封装成了单例，如下所示。
3.8K10发布于 2020-04-06 - 来自专栏IMWeb前端团队
尝试利用捕获来做上报
最近在做的课程查找页上报需求的时候，有两个问题要解决： 清理之前做的上报 重新添加新的上报 如果在原来的基础上直接改当然可以，但是将上报和业务代码耦合显然不是理想的解决方案，由于内嵌的webview是 大多数的上报都是点击上报 捕获先于冒泡，不用考虑 stopPropagation 的影响 所以可以在最外层，基于捕获来绑定事件： var getReportKey = function($ele, max addEventListener('click', function(event) { // 获得鼠标点击的元素 var $target = $(event.target); // 根据该元素获取上报的 / and so on default: break; } data && todoReport(data); }, true); 以上，所有要上报的点都可以在 此外，对于页面资源的加载监控等也可以使用捕获来做。
60890发布于 2017-12-29 - 来自专栏软件方法
设备数据上报的类图
数据上报的时候，可能与mi不是同一个时刻的，在可能在设备端收集后统一发上来，所以不能合并 UMLChina潘加宇: 再思考一下，分组是对规格分组还是对参数分组 彡工鸟: 参数名和参数值一开始是没有属性的 最开始通过用例分析的时候，分别是存在参数上报，状态上报，事件上报三个mi的，然后对应自己的mi明细。现在合并成一个数据上报，再添加上报类型的描述 ? UMLChina潘加宇: 如实描述。 合并成一个，上报，关联到上报类型 彡工鸟: 谢谢，我再仔细体会一下，到时候同数据库建模一起发上来 彡工鸟: 潘老师，我重新再整理了一下，觉得这样应该更合理。 右下角的事件，同样是设备上报的，事件差不多等同参数/状态 彡工鸟: 潘老师，这个还是需要设备ID吧，不然不知道是哪个设备 ? UMLChina潘加宇: 已经关联到上报了，又关联一次不是重复了吗 彡工鸟: 哦，那事件和状态也是一样处理才行 我想着这样便利一点呢 UMLChina潘加宇: ?
57220发布于 2019-09-23 - 来自专栏蓝天
强制DataNode向NameNode上报blocks
正常情况下，什么时候上报blocks，是由NameNode通过回复心跳响应的方式触发的。 一次机房搬迁中，原机房hadoop版本为2.7.2，新机房版本为2.8.0，采用先扩容再缩容的方式搬迁。 结合DataNode源代码，估计是因为DataNode没有向NameNode上报blocks。 结合DataNode的源代码，发现了HDFS自带的工具triggerBlockReport，它可以强制指定的DataNode向NameNode上报块，使用方法为： hdfs dfsadmin -triggerBlockReport datanode_host:ipc_port 如：hdfs dfsadmin -triggerBlockReport 192.168.31.35:50020 正常情况下NameNode启动时，会要求DataNode上报一次 boolean forceFullBr = scheduler.forceFullBlockReport.getAndSet(false); // triggerBlockReport强制上报仅一次有效
1.7K20发布于 2018-08-02 - 来自专栏田飞雨的专栏
kubelet 状态上报的方式
kubelet 自身会定期更新状态到 apiserver，通过参数 --node-status-update-frequency 指定上报频率，默认是 10s 上报一次，kubelet 不止上报心跳信息还会上报自身的一些数据信息 [condition] 3、Capacity 描述 node 上的可用资源：CPU、内存和可以调度到该 node 上的最大 pod 数量。 使用 kubectl get node xxx -o yaml 可以看到 node 所有的状态的信息，其中 status 中的信息都是 kubelet 需要上报的，所以 kubelet 不止上报心跳信息还上报节点信息 本文主要分析第一种上报方式的实现。 四、总结 本文主要讲述了 kubelet 上报状态的方式及其实现，node 状态上报的方式目前有两种，本文仅分析了第一种状态上报的方式。
1.5K00发布于 2019-12-15 - 来自专栏田飞雨的专栏
kubelet 状态上报的方式
kubelet 自身会定期更新状态到 apiserver，通过参数 --node-status-update-frequency 指定上报频率，默认是 10s 上报一次，kubelet 不止上报心跳信息还会上报自身的一些数据信息 3、Capacity 描述 node 上的可用资源：CPU、内存和可以调度到该 node 上的最大 pod 数量。 使用 kubectl get node xxx -o yaml 可以看到 node 所有的状态的信息，其中 status 中的信息都是 kubelet 需要上报的，所以 kubelet 不止上报心跳信息还上报节点信息 本文主要分析第一种上报方式的实现。 四、总结 本文主要讲述了 kubelet 上报状态的方式及其实现，node 状态上报的方式目前有两种，本文仅分析了第一种状态上报的方式。
3.4K30发布于 2019-12-18 - 来自专栏IMWeb前端团队
尝试利用捕获来做上报
最近在做的课程查找页上报需求的时候，有两个问题要解决： 清理之前做的上报 重新添加新的上报 如果在原来的基础上直接改当然可以，但是将上报和业务代码耦合显然不是理想的解决方案，由于内嵌的webview 大多数的上报都是点击上报 捕获先于冒泡，不用考虑 stopPropagation 的影响 所以可以在最外层，基于捕获来绑定事件： var getReportKey = function($ele, max addEventListener('click', function(event) { // 获得鼠标点击的元素 var $target = $(event.target); // 根据该元素获取上报的 / and so on default: break; } data && todoReport(data); }, true); 以上，所有要上报的点都可以在 此外，对于页面资源的加载监控等也可以使用捕获来做。
42910发布于 2019-12-03 - 来自专栏前端lucio
「前端曝光埋点上报」实现方案
曝光的含义比较模糊，具体的统计方式也比较麻烦，本文分享一个前端曝光埋点上报的实现方案。 方案 为了统计曝光数据，首先要做的是，定义什么是曝光，然后制定上报数据的策略。 数据上报：需要尽量减少上报次数（1）定时器每N秒检查一次，如果有待上报数据就请求接口上报（2）如果待上报数据大于M条，直接上报，不需要等待N秒。 用vue的指令，实现上报数据的绑定，最后使用的时候，只需要为需要上报的元素，加上v-treport=“上报的数据”。 在指令绑定的时候，为dom元素绑定report-data和guid属性，具体值分别为待上报数据和唯一ID。 具体观测和上报曝光的逻辑，后面具体讲。 观测元素的几种情况: A：进入窗口，500ms后退出窗口，需要上报 B：进入窗口，没有退出窗口，超过了500ms，需要上报 C：进入窗口，不到500ms退出窗口，不需要上报 代码实现 require('
3.2K21编辑于 2023-04-22 - 来自专栏彭湖湾的编程世界
详解JavaScript错误捕获和上报流程
Q6: 捕获之后怎么上报和处理？ 问题有点多，我们一个一个来。 Q1. static getDerivedStateFromError(error) { return { hasError: true }; } render() { } } 有错误，那肯定要上报啊 不上报就发现不了Bug这个样子。 —— Sentry官网 Sentry是一个日志上报系统，Sentry 是一个实时的日志记录和汇总处理的平台。专注于错误监控，发现和数据处理，可以让我们不再依赖于用户反馈才能发现和解决线上bug。 message', 'debug'); //fatal，error，warning，info，debug五个值 // fatal最严重,debug最轻 自动记录某些事件 例如下面的方法，会在每次屏幕调整时完成上报
1.7K20发布于 2019-11-24 - 来自专栏web全栈工程师的取经之路
自制上报错误与监控性能
注意 注释 的“抓取文件404报错”，“抓取js常规报错”，“抓取页面性能时间”，代码很好理解，将整个操作放在闭包内执行，以免污染外面。 这段代码必须放在head标签头部内，若头部有js外联，那该段代码必须放在js外联之上，若将这段代码放置在http://www.xxx.com/logservice.js，那代码如下：
62830发布于 2019-08-02 - 来自专栏架构师之路
无线APP日志上报优化实践
---- 二、APP通常有一些什么方法来上报日志？ 3）使用HTTP上报，例如通过GET参数传递需要上报的数据，这种方案使用最为广泛。 ，上面的例子用KV法来上报，则上报形式为： http://daojia.com/up? 答：笔者了解到的主要矛盾有： 1）无效的流量较多，HTTP请求内有很多无效数据 2）URL冗余，每次都要上报URL 3）KEY冗余，每次都要上报KEY 4）上报频度高，每当用户进行了一个操作都要日志上报的话 为了优化，会在这样的一些时间点进行上报： 1）特殊时间点：APP打开时，APP关闭时等 2）按时间上报：例如每隔10分钟上报一次 3）按数据量上报：例如每收集10条记录才上报一次 一般来说上述三种优化方法会结合进行
1.7K160发布于 2018-03-01 - 来自专栏腾讯大讲堂的专栏
数据上报，你“痛”了么？
02 为什么数据上报这么多问题 为什么上报这么多问题呢，我们从整个研发流程来看看。 42%的需求都是一句话的，40%的上报需求都是事后补上报。 数据上报的本质是记录软件变化过程。 ? 我们研究了上千个上报Tapd单，2000多个上报协议，得出我们的上报可以归为几大类，第一类就是行为数据，他是发生在我们系统的UI层，记录用户操作的过程。 进一步的，如果代码架构足够合理，是可以把上报模式化，把上报自动映射到代码中，实现自动埋点。 ? 我们做了一个数据上报定义工具，定义出来我们上报了哪些事件，数据同学要什么数据直接通过这个工具查就好了。 ?
1.1K50发布于 2021-07-19
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号