- 欢迎使用 SkyWalking
- 观测分析语言 Observability Analysis Language, OAL
- 仪表系统
- 设计目标
- 为什么 SkyWalking 体系中没有使用 MQ?
- 探针简介
- 观测分析平台
- 可视化
- 选择接收器
- 服务自动打点代理
- 手动打点 SDK
- 服务网格探针
- SkyWalking Java 代理支持列表
- 设置
- 协议
- 作用域 Scopes 和字段 Fields
- 概念与设计
- Backend 启动
- Backend 存储
- 安装 Java agent
- Open Fetcher
- 概念与设计总览
- 设置开发环境
- 组件库设置
- 插件自动测试框架
- 使用命令行导出
- 操作名称分组规则
- Spring 注解插件
- Oracle 和 Resin 插件
- 支持忽略自定义的 trace
- 支持自定义增强
- 配置覆盖
- 支持传输层安全性协议(TLS)
- 命名空间
- 令牌认证
- 令牌认证
- 兼容 OpenTracing 的 Skywalking tracer
- 安装 log4j
- 安装 log4j2
- logback 插件
- 应用程序工具包跟踪
- 跨线程追踪
- 通过系统属性动态定义 agent 配置文件
- 插件开发指南
- 在 Kubernetes 中部署
- 通过 ALS 观测服务网格
- UI
- 与 Istio 协作
- 配置 Envoy 来向 SkyWalking 发送度量指标
- 快速入门
- V6 升级
- SkyWalking 跨进程传播的头部协议
- OAP server 支持 gPRC SSL 传输
- 贡献指南
- 数据存储扩展
- 启动模式
- 设置的覆盖
- IP 和端口设置
- 初始化模式
- 集群管理
- 服务器端的跟踪采样
- 慢 SQL 语句设置
- 官方 OAL 脚本
- 告警
- 高级部署
- Metrics Exporter
- TTL
- 动态配置
- 无法打点的网关/代理
- 应用性能指数
- 端点分组参数化
- 后台遥测数据
- Apache SkyWalking 代码提交者
- 如何构建项目
- 新度量指标的源和范围扩展
- 后端存储实体扩展
- 线程转储归并机制
选择接收器
接收器是 SkyWalking 后台中的一个概念。 全模块所有负责从其它监控系统接收遥测或追踪数据的模块都被称为 Receiver 。如果你正在寻找拉模式,可以参考 fetcher 文档
我们有以下 receiver,Apache distribution 中提供了 default
实现者。
- receiver-trace. gRPC 和 HTTPRestful 服务,接收 SkyWalking 格式的追踪数据。
- receiver-register. gRPC 和 HTTPRestful 服务,提供服务、服务实例、端点的注册。
- service-mesh. gRPC 服务,接收来自网格探针的数据。
- receiver-jvm. gRPC 服务,接收 JVM 度量数据。
- istio-telemetry. Istio 遥测数据来自 Istio 官方旁路适配器, 这个接收器匹配自身的 gRPC 服务.
- envoy-metric. Envoy
metrics_service
和ALS(access log service)
由它提供支持。 OAL 脚本支持所有仪表类型度量。 - receiver-profile. gRPC 服务,接收分析任务状态和快照报告。
- receiver_zipkin. 参考 提供给 receiver 的 gRPC/HTTP 服务
默认情况下,所有 GRPC/HTTP 服务都应在
core/gRPC
和core/rest
处提供。 但是receiver-sharing-server
模块提供了一种方式可使所有的 receiver 提供不同的 ip:port ,当然这需要你明确地设置。receiver-sharing-server: default: restHost: ${SW_SHARING_SERVER_REST_HOST:0.0.0.0} restPort: ${SW_SHARING_SERVER_REST_PORT:12800} restContextPath: ${SW_SHARING_SERVER_REST_CONTEXT_PATH:/} gRPCHost: ${SW_SHARING_SERVER_GRPC_HOST:0.0.0.0} gRPCPort: ${SW_SHARING_SERVER_GRPC_PORT:11800}
注意,如果添加这些设置,请确保它们与核心模块不同,因为核心的 GRPC/HTTP 服务器仍用于 UI 和 OAP 内部通信。
Zipkin receiver
Zipkin receiver 可以在两种不同的模式下工作。
1. Tracing mode(default)
追踪模式就是,skywalking 的 OAP 表现得像个 zipkin 收集器,通过 HTTP 服务完全支持 Zipkin 的 v1/v2 格式, 还在 Skywalking 用户界面提供了持久化和查询。但它不会从中分析度量标准。在大多数情况下,当度量来自 service mesh 时,我建议你可以使用这个特性。
注意,在这种模式下,Zipkinr receiver 需要激活
zipkin-elasticsearch
的存储实现。阅读这里了解如何激活。使用以下配置来激活
receiver_zipkin: default: host: ${SW_RECEIVER_ZIPKIN_HOST:0.0.0.0} port: ${SW_RECEIVER_ZIPKIN_PORT:9411} contextPath: ${SW_RECEIVER_ZIPKIN_CONTEXT_PATH:/}
2. Analysis mode(非生产环境准备)
通过 HTTP 服务接收 Zipkin 的 v1/v2 格式。将 trace 转换为 skywalking 原生的格式,并像 skywalking trace 那样进行分析。这个特性尚不能在生产环境使用,这是因为 zipkin tag/endpoint 不可预测,我们无法确保它符合生产环境要求。
激活
analysis mode
, 你需要设置needAnalysis
配置。receiver_zipkin: default: host: ${SW_RECEIVER_ZIPKIN_HOST:0.0.0.0} port: ${SW_RECEIVER_ZIPKIN_PORT:9411} contextPath: ${SW_RECEIVER_ZIPKIN_CONTEXT_PATH:/} needAnalysis: true
注意,Zipkin receiver 只提供在
apache-skywalking-apm-x.y.z.tar.gz
tar 中。Jaeger receiver
Jaeger receiver 目前只在
Tracing Mode(跟踪模式)
下工作,不支持分析。Jaeger receiver 提供额外的 gRPC host/port,如果没有就使用 sharing-server host/port, 还没有就使用 core gRPC host/port。Receiver 需要激活
jaeger-elasticsearch
的存储实。阅读 此处 了解如何激活.同时,你需要 jaeger agent 批量发送 span 至 SkyWalking oap server。 详细参考 Jaeger Architecture
激活 Jaeger receiver
receiver_jaeger: default: gRPCHost: ${SW_RECEIVER_JAEGER_HOST:0.0.0.0} gRPCPort: ${SW_RECEIVER_JAEGER_PORT:14250}
注意,Jaeger receiver 只提供在
apache-skywalking-apm-x.y.z.tar.gz
tar 中。
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论