OneUptime Profiles Monitor 配置指南基于连续性能分析数据的监控与告警【免费下载链接】oneuptimeComplete open-source monitoring and observability platform.项目地址: https://gitcode.com/GitHub_Trending/on/oneuptimeProfiles Monitor 是 OneUptime 观测体系中的一类 Telemetry 监控器MonitorType 枚举中的Profiles它不探测端口、也不执行脚本而是对应用通过 Pyroscope 兼容协议上报的连续性能分析Continuous Profiling数据进行计数与过滤并在满足条件时触发告警。本文基于 profiles-monitor.md 展开结合仓库内监控配置类型、分析模型表结构、告警评估源码与数据接入文档完整讲解 Profiles Monitor 的创建步骤、过滤配置、监控标准与底层实现读完即可独立配置应用持续产生性能数据与性能数据中断/异常两类告警。Profiles Monitor 能做什么Profiles Monitor 在 OneUptime 中统计并过滤符合特定条件的 profile性能分析文件数据而不是对数据内容做函数级分析。它支持监控应用上报的连续性能分析数据按 profile 类型CPU、memory、goroutines 等过滤追踪 profile 的数量与形态patterns在性能分析出现异常如某类型 profile 突然消失时发出告警按自定义 profile 属性attributes进行过滤。从源码结构看这类监控器与 Logs、Metrics、Traces、Exceptions、SecurityEvents 一样被归入Telemetry监控类别MonitorType.ts 中Profiles Profiles并且属于服务端评估型监控器isProbableMonitor返回 false不依赖 Probe 执行其数据来源是应用通过 Grafana AlloyeBPF或 Pyroscope SDK 上报到 OneUptime 的性能分析数据。创建 Profiles Monitor在 OneUptime Dashboard 中按以下步骤创建进入Monitors页面点击Create Monitor选择Profiles作为监控器类型选择要监控的 telemetry 服务按需配置 profile 过滤器与监控标准。需要说明的是从当前仓库源码MonitorTypeHelper.getMonitorTypeCategories中 Telemetry 类别的注释可以看到Profiles 目前没有从监控器类型选择器中直接暴露原因在于 Dashboard 端尚无该监控步骤的配置表单。但Profiles的枚举值、类型属性getAllMonitorTypeProps中 title 为 Profiles、描述为 Alert on continuous profiling data from any source、keywords 含profiling、flamegraph、pprof等以及 Worker 端评估逻辑均完整保留已存在的 Profiles Monitor 可以继续正常工作。配置选项详解Telemetry Services选择一个或多个需要监控的 telemetry 服务。这些服务必须正在通过Grafana AlloyeBPF或Pyroscope SDK向 OneUptime 发送连续性能分析数据。Profile Filters监控器可以通过以下过滤器缩小统计范围过滤器说明是否必填Profile Types按 profile 类型名称过滤例如 CPU、memory、goroutines否Attributes用于过滤自定义 profile 属性的键值对否Time Window向前回溯搜索 profile 的时间范围单位秒默认 60否源码视角MonitorStepProfileMonitor 配置结构仓库中 MonitorStepProfileMonitor.ts 定义了 Profiles 监控步骤的完整配置结构与上述过滤器一一对应export default interface MonitorStepProfileMonitor { attributes: Dictionarystring | number | boolean; profileTypes: Arraystring; telemetryServiceIds: ArrayObjectID; /* * Stable telemetry entity keys (host / pod / container / ...) — scopes * the monitor to profiles carrying any of these in their entityKeys * column. Optional: monitors saved before this field existed have it * undefined. */ entityKeys?: Arraystring | undefined; lastXSecondsOfProfiles: number; profileType: string; }telemetryServiceIds要监控的 telemetry 服务 ID 列表最终编译为对 profile 表primaryEntityId字段的IN查询profileTypes/profileTypeprofile 类型过滤编译为对profileType字段的IN包含或Search模糊搜索条件attributes自定义属性键值对过滤直接映射为对attributes字段的等值查询entityKeys可选字段用于将监控范围限定到带有指定实体键host / pod / container 等的 profile。该字段对应 profile 数据中的entityKeys列见下文 Profile 模型注释明确说明对 entityKeys 列的 hasAny 匹配空值/undefined 为 no-oplastXSecondsOfProfiles时间窗口。在toQuery方法中它以当前时间减去 N 秒作为起点生成InBetween(startDate, endDate)区间查询作用于startTime字段——这正是上文Time Window默认 60 秒的底层实现。MonitorStepProfileMonitorUtil.getDefault()给出的默认值为attributes: {}、profileType: 、profileTypes: []、telemetryServiceIds: []、entityKeys: []、lastXSecondsOfProfiles: 60确认默认时间窗口为 60 秒。监控标准Monitoring Criteria可用的过滤类型过滤类型说明Profile Count在时间窗口内、符合过滤器条件的 profile 数量在类型定义中对应 CriteriaFilter.ts 的CheckOn.ProfileCount Profile Count枚举值。过滤条件支持以下六种数值比较条件Greater Than— profile 数量超过阈值Less Than— profile 数量低于阈值Greater Than or Equal To— profile 数量达到或超过阈值Less Than or Equal To— profile 数量达到或低于阈值Equal To— profile 数量恰好等于阈值Not Equal To— profile 数量不等于阈值示例5 分钟内未收到任何 profile 时告警Time Window300 秒Filter TypeProfile CountFilter ConditionEqual ToValue0该示例是一个典型的数据中断告警只要在最近 300 秒的时间窗口内匹配到的 profile 数量为 0即判定条件满足并触发告警可用于发现 agent 停止上报、进程崩溃或 eBPF 采集失效等问题。底层原理Profile 数据模型与告警评估Profile 分析模型与 ClickHouse 表OneUptime 将 profile 数据存放在 ClickHouse 分析表中模型定义见 Profile.ts。该表AnalyticsTableName.ProfileMergeTree 引擎的排序键与主键为(projectId, startTime, primaryEntityId, profileType)分区键为toYYYYMMDD(startTime)与监控查询条件高度匹配。关键字段包括primaryEntityId/primaryEntityTypeprofile 所属的资源Service / Host / DockerHost / KubernetesCluster / Monitor由primaryEntityType区分监控器对primaryEntityId做IN查询profileTypeprofile 类型如cpu、wall、alloc_objects、alloc_space、goroutine监控器按此过滤attributesMapStringString类型的 profile 级属性监控器的attributes过滤即作用于该列entityKeysprofile 所属的所有 OpenTelemetry 实体稳定键service、host、k8s.pod、container 等支持has(entityKeys, :key)跨实体查询是监控器entityKeys过滤的底层数据支撑startTime/endTime/startTimeUnixNano/endTimeUnixNanoprofile 采集时间范围监控器时间窗口作用于startTimeprofileId、traceId/spanIdprofile 唯一标识及与链路trace/span的关联sampleCountprofile 内样本数unit数值单位纳秒、字节等retentionDate按服务配置的保留期计算的 TTL 删除日期默认保留 15 天。Worker 端评估流程监控评估由服务端完成。在 MonitorCriteriaEvaluator.ts 中当input.monitor.monitorType MonitorType.Profiles时会调用ProfileMonitorCriteria.isMonitorInstanceCriteriaFilterMet进行评估真正的比较逻辑位于 ProfileMonitorCriteria.tsif (input.criteriaFilter.checkOn CheckOn.ProfileCount) { threshold CompareCriteria.convertToNumber(threshold); const currentProfileCount: number (input.dataToProcess as ProfileMonitorResponse).profileCount || 0; return CompareCriteria.compareCriteriaNumbers({ value: currentProfileCount, threshold: threshold as number, criteriaFilter: input.criteriaFilter, }); }即Worker 端先通过MonitorStepProfileMonitorUtil.toQuery将监控配置编译成对 Profile 表的查询聚合出匹配 profile 数量ProfileMonitorResponse.profileCount再与阈值按所选条件大于、小于、等于等做数值比较返回是否满足条件。整个过程不需要任何 Probe 参与属于纯服务端评估的 Telemetry 监控。前置条件先让应用上报性能分析数据Profiles Monitor 依赖应用持续上报性能分析数据。完整接入步骤见 telemetry/profiles.md核心要点如下接入端点OneUptime 暴露 Pyroscope 兼容的采集 API基础 URL 为https://oneuptime.com/pyroscope自托管请替换为自己的主机地址认证头为x-oneuptime-token: YOUR_ONEUPTIME_INGESTION_TOKEN。Pyroscope SDK 会在基础 URL 后追加/ingestGrafana Alloy 则追加/push.v1.PusherService/Push配置时只需填写基础 URL。SDK 的authToken选项会以Authorization: Bearer token发送OneUptime 将其作为x-oneuptime-token的别名接受。接入方式二选一Option AGrafana Alloy eBPF推荐零代码改动——在 Linux 主机上通过 eBPF 采集所有进程的 CPU profile无需侵入应用。需要以特权容器 host PID namespace 运行或直接alloy run alloy-config.alloy配置pyroscope.ebpf与pyroscope.write组件即可。Option BPyroscope 语言 SDK进程内采集——在 Go、Node.js、Python、.NET、Ruby、Rust 应用中集成 Pyroscope SDK将ServerAddress指向 OneUptime 基础 URL、AuthToken填入采集令牌。Go 与 Node.js SDK 上传 pprof 格式Python/Ruby/Rust 默认上传 folded text 格式Java 的 Pyroscope agent 上传 JFR 格式OneUptime 暂不支持Java 服务请改用 Option A 的 Alloy eBPF 方案。支持类型与展示cpu/samplesCPU 时间纳秒、wall墙钟时间、inuse_space/alloc_space/heap内存字节、inuse_objects/alloc_objects内存对象数、mutex/contention/block锁竞争纳秒、goroutinegoroutine 数量等类型在界面中具有一级分组与单位展示其余自定义类型归入 Other。数据保留profile 数据保留期按 telemetry 服务在项目设置中单独配置默认 15 天到期自动删除对应表中retentionDate列的 TTL 机制。配置建议与注意事项合理设置时间窗口Time Window 应与应用的上报间隔匹配。Alloy 默认 15 秒采集间隔、SDK 约 10 秒上传间隔默认 60 秒窗口通常能覆盖多个采集周期如果排查偶发中断可将窗口适当放宽如示例中的 300 秒。Profile Count 条件的选择等于 0适合中断检测大于阈值适合检测异常突增如 goroutine 数量暴涨导致 profile 数量激增小于阈值适合检测采集量衰减。多维度过滤组合可将telemetryServiceIds服务级、profileTypes类型级、attributes自定义属性级与entityKeys实体级组合使用把监控范围精确收敛到某个服务的某种 profile 类型避免全局统计掩盖局部异常。确保数据已接入若监控器长期处于告警状态请先按上文接入文档验证数据链路——可使用curl -i -H x-oneuptime-token: YOUR_TOKEN https://oneuptime.com/otlp/v1/validate校验令牌有效性并在 Dashboard 的Products Performance Profiles页面确认能渲染 flamegraph再排查监控器配置本身。【免费下载链接】oneuptimeComplete open-source monitoring and observability platform.项目地址: https://gitcode.com/GitHub_Trending/on/oneuptime创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 OneUptime Profiles Monitor 配置指南：基于连续性能分析数据的监控与告警
OneUptime Profiles Monitor 配置指南基于连续性能分析数据的监控与告警【免费下载链接】oneuptimeComplete open-source monitoring and observability platform.项目地址: https://gitcode.com/GitHub_Trending/on/oneuptimeProfiles Monitor 是 OneUptime 观测体系中的一类 Telemetry 监控器MonitorType 枚举中的Profiles它不探测端口、也不执行脚本而是对应用通过 Pyroscope 兼容协议上报的连续性能分析Continuous Profiling数据进行计数与过滤并在满足条件时触发告警。本文基于 profiles-monitor.md 展开结合仓库内监控配置类型、分析模型表结构、告警评估源码与数据接入文档完整讲解 Profiles Monitor 的创建步骤、过滤配置、监控标准与底层实现读完即可独立配置应用持续产生性能数据与性能数据中断/异常两类告警。Profiles Monitor 能做什么Profiles Monitor 在 OneUptime 中统计并过滤符合特定条件的 profile性能分析文件数据而不是对数据内容做函数级分析。它支持监控应用上报的连续性能分析数据按 profile 类型CPU、memory、goroutines 等过滤追踪 profile 的数量与形态patterns在性能分析出现异常如某类型 profile 突然消失时发出告警按自定义 profile 属性attributes进行过滤。从源码结构看这类监控器与 Logs、Metrics、Traces、Exceptions、SecurityEvents 一样被归入Telemetry监控类别MonitorType.ts 中Profiles Profiles并且属于服务端评估型监控器isProbableMonitor返回 false不依赖 Probe 执行其数据来源是应用通过 Grafana AlloyeBPF或 Pyroscope SDK 上报到 OneUptime 的性能分析数据。创建 Profiles Monitor在 OneUptime Dashboard 中按以下步骤创建进入Monitors页面点击Create Monitor选择Profiles作为监控器类型选择要监控的 telemetry 服务按需配置 profile 过滤器与监控标准。需要说明的是从当前仓库源码MonitorTypeHelper.getMonitorTypeCategories中 Telemetry 类别的注释可以看到Profiles 目前没有从监控器类型选择器中直接暴露原因在于 Dashboard 端尚无该监控步骤的配置表单。但Profiles的枚举值、类型属性getAllMonitorTypeProps中 title 为 Profiles、描述为 Alert on continuous profiling data from any source、keywords 含profiling、flamegraph、pprof等以及 Worker 端评估逻辑均完整保留已存在的 Profiles Monitor 可以继续正常工作。配置选项详解Telemetry Services选择一个或多个需要监控的 telemetry 服务。这些服务必须正在通过Grafana AlloyeBPF或Pyroscope SDK向 OneUptime 发送连续性能分析数据。Profile Filters监控器可以通过以下过滤器缩小统计范围过滤器说明是否必填Profile Types按 profile 类型名称过滤例如 CPU、memory、goroutines否Attributes用于过滤自定义 profile 属性的键值对否Time Window向前回溯搜索 profile 的时间范围单位秒默认 60否源码视角MonitorStepProfileMonitor 配置结构仓库中 MonitorStepProfileMonitor.ts 定义了 Profiles 监控步骤的完整配置结构与上述过滤器一一对应export default interface MonitorStepProfileMonitor { attributes: Dictionarystring | number | boolean; profileTypes: Arraystring; telemetryServiceIds: ArrayObjectID; /* * Stable telemetry entity keys (host / pod / container / ...) — scopes * the monitor to profiles carrying any of these in their entityKeys * column. Optional: monitors saved before this field existed have it * undefined. */ entityKeys?: Arraystring | undefined; lastXSecondsOfProfiles: number; profileType: string; }telemetryServiceIds要监控的 telemetry 服务 ID 列表最终编译为对 profile 表primaryEntityId字段的IN查询profileTypes/profileTypeprofile 类型过滤编译为对profileType字段的IN包含或Search模糊搜索条件attributes自定义属性键值对过滤直接映射为对attributes字段的等值查询entityKeys可选字段用于将监控范围限定到带有指定实体键host / pod / container 等的 profile。该字段对应 profile 数据中的entityKeys列见下文 Profile 模型注释明确说明对 entityKeys 列的 hasAny 匹配空值/undefined 为 no-oplastXSecondsOfProfiles时间窗口。在toQuery方法中它以当前时间减去 N 秒作为起点生成InBetween(startDate, endDate)区间查询作用于startTime字段——这正是上文Time Window默认 60 秒的底层实现。MonitorStepProfileMonitorUtil.getDefault()给出的默认值为attributes: {}、profileType: 、profileTypes: []、telemetryServiceIds: []、entityKeys: []、lastXSecondsOfProfiles: 60确认默认时间窗口为 60 秒。监控标准Monitoring Criteria可用的过滤类型过滤类型说明Profile Count在时间窗口内、符合过滤器条件的 profile 数量在类型定义中对应 CriteriaFilter.ts 的CheckOn.ProfileCount Profile Count枚举值。过滤条件支持以下六种数值比较条件Greater Than— profile 数量超过阈值Less Than— profile 数量低于阈值Greater Than or Equal To— profile 数量达到或超过阈值Less Than or Equal To— profile 数量达到或低于阈值Equal To— profile 数量恰好等于阈值Not Equal To— profile 数量不等于阈值示例5 分钟内未收到任何 profile 时告警Time Window300 秒Filter TypeProfile CountFilter ConditionEqual ToValue0该示例是一个典型的数据中断告警只要在最近 300 秒的时间窗口内匹配到的 profile 数量为 0即判定条件满足并触发告警可用于发现 agent 停止上报、进程崩溃或 eBPF 采集失效等问题。底层原理Profile 数据模型与告警评估Profile 分析模型与 ClickHouse 表OneUptime 将 profile 数据存放在 ClickHouse 分析表中模型定义见 Profile.ts。该表AnalyticsTableName.ProfileMergeTree 引擎的排序键与主键为(projectId, startTime, primaryEntityId, profileType)分区键为toYYYYMMDD(startTime)与监控查询条件高度匹配。关键字段包括primaryEntityId/primaryEntityTypeprofile 所属的资源Service / Host / DockerHost / KubernetesCluster / Monitor由primaryEntityType区分监控器对primaryEntityId做IN查询profileTypeprofile 类型如cpu、wall、alloc_objects、alloc_space、goroutine监控器按此过滤attributesMapStringString类型的 profile 级属性监控器的attributes过滤即作用于该列entityKeysprofile 所属的所有 OpenTelemetry 实体稳定键service、host、k8s.pod、container 等支持has(entityKeys, :key)跨实体查询是监控器entityKeys过滤的底层数据支撑startTime/endTime/startTimeUnixNano/endTimeUnixNanoprofile 采集时间范围监控器时间窗口作用于startTimeprofileId、traceId/spanIdprofile 唯一标识及与链路trace/span的关联sampleCountprofile 内样本数unit数值单位纳秒、字节等retentionDate按服务配置的保留期计算的 TTL 删除日期默认保留 15 天。Worker 端评估流程监控评估由服务端完成。在 MonitorCriteriaEvaluator.ts 中当input.monitor.monitorType MonitorType.Profiles时会调用ProfileMonitorCriteria.isMonitorInstanceCriteriaFilterMet进行评估真正的比较逻辑位于 ProfileMonitorCriteria.tsif (input.criteriaFilter.checkOn CheckOn.ProfileCount) { threshold CompareCriteria.convertToNumber(threshold); const currentProfileCount: number (input.dataToProcess as ProfileMonitorResponse).profileCount || 0; return CompareCriteria.compareCriteriaNumbers({ value: currentProfileCount, threshold: threshold as number, criteriaFilter: input.criteriaFilter, }); }即Worker 端先通过MonitorStepProfileMonitorUtil.toQuery将监控配置编译成对 Profile 表的查询聚合出匹配 profile 数量ProfileMonitorResponse.profileCount再与阈值按所选条件大于、小于、等于等做数值比较返回是否满足条件。整个过程不需要任何 Probe 参与属于纯服务端评估的 Telemetry 监控。前置条件先让应用上报性能分析数据Profiles Monitor 依赖应用持续上报性能分析数据。完整接入步骤见 telemetry/profiles.md核心要点如下接入端点OneUptime 暴露 Pyroscope 兼容的采集 API基础 URL 为https://oneuptime.com/pyroscope自托管请替换为自己的主机地址认证头为x-oneuptime-token: YOUR_ONEUPTIME_INGESTION_TOKEN。Pyroscope SDK 会在基础 URL 后追加/ingestGrafana Alloy 则追加/push.v1.PusherService/Push配置时只需填写基础 URL。SDK 的authToken选项会以Authorization: Bearer token发送OneUptime 将其作为x-oneuptime-token的别名接受。接入方式二选一Option AGrafana Alloy eBPF推荐零代码改动——在 Linux 主机上通过 eBPF 采集所有进程的 CPU profile无需侵入应用。需要以特权容器 host PID namespace 运行或直接alloy run alloy-config.alloy配置pyroscope.ebpf与pyroscope.write组件即可。Option BPyroscope 语言 SDK进程内采集——在 Go、Node.js、Python、.NET、Ruby、Rust 应用中集成 Pyroscope SDK将ServerAddress指向 OneUptime 基础 URL、AuthToken填入采集令牌。Go 与 Node.js SDK 上传 pprof 格式Python/Ruby/Rust 默认上传 folded text 格式Java 的 Pyroscope agent 上传 JFR 格式OneUptime 暂不支持Java 服务请改用 Option A 的 Alloy eBPF 方案。支持类型与展示cpu/samplesCPU 时间纳秒、wall墙钟时间、inuse_space/alloc_space/heap内存字节、inuse_objects/alloc_objects内存对象数、mutex/contention/block锁竞争纳秒、goroutinegoroutine 数量等类型在界面中具有一级分组与单位展示其余自定义类型归入 Other。数据保留profile 数据保留期按 telemetry 服务在项目设置中单独配置默认 15 天到期自动删除对应表中retentionDate列的 TTL 机制。配置建议与注意事项合理设置时间窗口Time Window 应与应用的上报间隔匹配。Alloy 默认 15 秒采集间隔、SDK 约 10 秒上传间隔默认 60 秒窗口通常能覆盖多个采集周期如果排查偶发中断可将窗口适当放宽如示例中的 300 秒。Profile Count 条件的选择等于 0适合中断检测大于阈值适合检测异常突增如 goroutine 数量暴涨导致 profile 数量激增小于阈值适合检测采集量衰减。多维度过滤组合可将telemetryServiceIds服务级、profileTypes类型级、attributes自定义属性级与entityKeys实体级组合使用把监控范围精确收敛到某个服务的某种 profile 类型避免全局统计掩盖局部异常。确保数据已接入若监控器长期处于告警状态请先按上文接入文档验证数据链路——可使用curl -i -H x-oneuptime-token: YOUR_TOKEN https://oneuptime.com/otlp/v1/validate校验令牌有效性并在 Dashboard 的Products Performance Profiles页面确认能渲染 flamegraph再排查监控器配置本身。【免费下载链接】oneuptimeComplete open-source monitoring and observability platform.项目地址: https://gitcode.com/GitHub_Trending/on/oneuptime创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考