https://bbs.huaweicloud.com/blogs/396728这个帖子是什么问题？可以恢复吗？而且审核不通过但是有25阅读量，广告营销内容具体指哪部分？

前提条件主机已经接入运维、监控、日志平台，详细步骤参考新增业务主机接入运维、监控、日志平台。在目标主机执行如下两个命令：grep ^Include /home/zabbix/etc/zabbix_agentd.confgrep ^Include /home/zabbix/etc/zabbix_agent2.conf命令返回的Include即为监控配置文件的存放位置。说明查询监控配置文件的存放位置，如上图所示，选择新建配置文件的目录为“/home/zabbix_cust/etc/*.conf”，因为执行升级时，会重置“/home/zabbix/etc/”目录的文件。场景描述本示例演示了test数据库中testtable表的记录数大于5时，就会触发zabbix中配置的监控项、触发器，最终触发告警并展示在zabbix的Monitoring界面上。告警的开发流程如下：1、首先进行前台配置：配置模板、配置监控项、配置触发器、关联主机。2、然后进行后台配置：创建脚本、查看数据库、配置文件、执行脚本。3、最后查看监控：查看问题、查看监控项。

查看上报数据1、登录Zabbix前端Portal。2、选择“Monitoring > Latest data”，在Hosts输入目标主机名称，Application填入模板的application名称，点击“Apply”。可快速查询到上报的数据。查看告警1、登录Zabbix前端Portal。2、选择“Monitoring > Problems”，根据hosts选择自己的主机，触发告警会需要一个或几个上报数据的周期。在下方就会有告警。

以zabbix_sender方式主动上报监控数据为例。多条数据以文件形式通过zabbix sender一次上报（同一脚本需要上报多条数据时推荐这种方式，相较调用多次zabbix_sender更高效）。# /home/zabbix/bin/zabbix_sender -z server（要向其发送数据的Zabbix服务器或代理的主机名或IP地址） -p 端口 -i 文件路径及文件名 -vv -T（上报的数据中带有时间戳则需要-T）例如/home/zabbix/bin/zabbix_sender -z 192.168.17.6 -p 31152 -i /home/zabbix/logs/metric_label_trapper.txt -vv –T文件内数据格式：hostname key值 时间戳 值文件内数据样例：test_hostname test_key 1583998373 34.393一条数据类型的数据zabbix sender上报。# /home/zabbix/bin/zabbix_sender -z server -p 端口 -s hostname -k key值 -o 值 –vv例如/home/zabbix/bin/zabbix_sender -z 192.168.17.6 -p 31152 -s test_hostname -k test_key -o 34.393 -vv上报正常sender返回值如下图。以zabbix_agent方式被动上报监控数据为例。在目标主机执行grep ^Include /home/zabbix/etc/zabbix_agent.conf，命令返回的Include即为监控配置文件的存放位置。调试自定义脚本和配置文件。将配置文件放入由步骤1得到的Include的路径下。配置文件格式和参考如下：格式：UserParameter="key值", 需要执行的脚本（可带参数）示例：UserParameter=ops_health_agent, sh /home/zabbix/scripts/ops_health_check.sh将自定义脚本放在配置文件中指定的路径下。脚本直接输出需要上报的值，参考值如下图：将配置文件和脚本文件的属主改为zabbix。chown -R zabbix:zabbix 配置文件路径/脚本路径更改脚本文件的读写权限。在脚本目录执行以下命令。chmod 750 *.shchmod 750 *.py重启zabbix agent。切换zabbix用户，查询zabbix agent进程。su zabbix -s "/bin/bash"cat /home/zabbix/logs/zabbix_agent2.pid结束zabbix agent进程。kill (zabbix_agentd的pid)重启zabbix agent进程。/home/zabbix/sbin/zabbix_agent2 &在目标主机上用zabbix_get验证拿到的上报数据的值。如果可以拿到key对应的返回值则进行下一步，如果拿不到则跳转到常见问题进行解决。/home/zabbix/bin/zabbix_get -s 目标主机ip -k 配置文件中的key值

1、登录Zabbix前端Portal。2、单击“Configuration > Hosts”，进入查看目标主机(可在Name或IP处填写目标主机的信息，点击“应用”快速查询主机)，点击Name列的主机名进入主机配置页面。3、在“Hosts”页面，单击“Templates”进入Hosts添加模板页面。4、单击“Select”，选择此次需要关联的模板组。找到此次需要关联的模板，勾选前面的框，点击下方“Select”。在上方Linked templates可以看到刚刚选择的模板名称后点击“Update”。即关联模板成功。

1、登录Zabbix前端Portal。2、单击“Configuration > Hosts”，进入查看目标主机(可在Name或IP处填写目标主机的信息，点击“Apply”快速查询主机)，点击Name列的主机名进入主机配置页面。3、在“Hosts”页面，单击“Templates”进入Hosts添加模板页面。4、单击“Select”，选择此次需要关联的模板组。找到此次需要关联的模板，勾选前面的框，点击下方“Select”。在上方Linked templates可以看到刚刚选择的模板名称后点击“Update”。即关联模板成功。

1、登录Zabbix前端Portal。2、单击“Configuration > Templates”，选择进入对应模板页面。3、进入“Triggers”页签。4、单击“Create triggers”新建触发器。填写下表中的信息点击左下角的“Add”。表1 Triggers参数说明触发器项目含义示例值Name触发器名称102078_{HOST.IP}_nfs is down! [nfs进程数量<1]Severity告警级别HighProblem expression/expression告警条件表达式{Template_NFS_ABC:proc.num[nfsd,,,].max(#2)}<1OK event generation(可省略)OK事件生成选项：\\表达式 -OK事件是基于与问题事件相同的表达式生成的；恢复表达式 -如果恢复表达式的评估结果为TRUE，而问题表达式的评估结果为FALSE，则将生成OK事件。无 -在这种情况下，触发器将永远不会自行返回OK状态Recovery expressionRecovery expression(可省略)恢复条件表达式{Template_NFS_ABC:proc.num[nfsd,,,].min(#2)}>0Tags标签每个产品在Zabbix上触发的告警都要打上两个Tag，以便支持园区Cube的分平台监控视图：一级标签：Tag Name：MonitoringLayerTag Value：DigitalPlatform、BusinessApp（固定值）（二选一）二级标签：Tag Name: DigitalPlatform、BusinessApp（同一级标签的Tag Value）Tag Value：XXX（数字平台或应用APP的名称，比如IOT、GIS、Allcam等第三方Name）其中Tags在第二个页签。其它字段及作用请参考zabbix官方文档：cid:link_1补充：Problem expression填写方式(Recovery expression同)点击Problem expression后面的Add进入添加表达式的页面，点击select，选择需要触发告警的监控项。Function可参照官方文档：cid:link_0

1、登录Zabbix前端Portal。2、单击“Configuration > Templates”，选择进入对应模板页面。3、进入“Items”页签4、单击“Create item”，开始创建新的Item模板。表1 Item参数说明关键字段含义示例值name需要增加的item名字。Zabbixproxy_tcp_port_listen_10051type此处选择zabbix agent类型上报数据。Zabbix agentkey监控项key。可支持的监控项的key，能够在各个监控项类型中找到。这个key在单个主机中必须是唯一的。常用key：net.tcp.listen[<port>]<port>目标主机端口的健康检查，net.tcp.port[<ip>,port](检查是否可以与指定端口建立TCP连接。返回0-无法连接；1-可以连接)等等。net.tcp.listen[10051]，其中10051为目标监控端口号，按实际需要填写。Type of information选择上报数据的类型。Numeric(unsigned)Update interval上报数据的周期(单位是s，m，d)。30sHistory storage period在数据库中保留详细历史记录的天数，housekeeper将删除较旧的数据。数据库中还设置了定期清理的存储过程，默认值是30天。因此即使此处填的是90天，最多也只能查看30天的历史记录。7d/90dTrend storage period在数据库中保留N天的详细历史记录（小时最小，最大，平均值，计数）。 housekeeper将删除较旧的数据。数据库中还设置了定期清理的存储过程，默认值是30天。因此即使此处填的是90天，最多也只能查看30天的历史记录。365dShow value将值映射应用于此监控项。值映射不会改变收到的值，仅用于显示数据。它只适用于整数项。As isNew application新建应用集。Ops|Zabbix|HealthcheckApplications应用集。Ops|Zabbix|HealthcheckDescription添加对此item的描述。{"offering":"OPS", "type":"应用健康检查", "description":"zabbixproxy健康检查"}

1、登录Zabbix前端Portal。2、单击“Configuration > Templates”，选择进入对应模板页面。3、进入“Application”页签。4、单击“Create application”创建应用。

【问题来源】【必填】 南海农商行【问题简要】【必填】cms t_cms_vdn_dst_rule表为空，导致日总结数据无法生成【问题类别】【必填】    CMS 【AICC解决方案版本】【必填】    AICC可选择版本：AICC 8.22.100【期望解决时间】【选填】尽快【问题现象描述】【必填】cms t_cms_vdn_dst_rule表为空，导致日总结数据无法生成

1、登录Zabbix前端Portal。2、单击“Configuration > Templates”。3、单击“Create template”进入创建模板。4、填入相关参数。在Template name处填入此次新增的模板名称Template_Ops_Zabbixproxy，点击Add添加模板。表1 模板参数说明属性描述Template name唯一的模板名称。Visible name如果你设置了这个名字，那么它将是list，map等中可见的。（可省略）Groups模板所属的主机/模板组。（可省略）Description输入模板说明。（可省略）在Templates页面找到刚刚添加的Template_Ops_Zabbixproxy模板(可在name处填写模板名称，点击‘应用’按钮进行快速搜索)，点击对应的Applications，添加Application。Application相当于一个组，将监控项添加到Application下可快速查询上报数值。(可省略)。

1、登录Zabbix前端Portal。2、单击“Configuration > Templates”。3、单击“Create template”进入创建模板。4、填入相关参数。在Template name处填入此次新增的模板名称Template_Ops_Zabbixproxy，点击Add添加模板。表1 模板参数说明属性描述Template name唯一的模板名称。Visible name如果你设置了这个名字，那么它将是list，map等中可见的。（可省略）Groups模板所属的主机/模板组。（可省略）Description输入模板说明。（可省略）在Templates页面找到刚刚添加的Template_Ops_Zabbixproxy模板(可在name处填写模板名称，点击Apply进行快速搜索)，点击对应的Applications，添加Application。Application相当于一个组，将监控项添加到Application下可快速查询上报数值。(可省略)。

添加主机组要在Zabbix页面配置主机组，请执行以下步骤：1、以admin用户登录Zabbix前端Portal。2、左边导航栏选择“Configuration > Host groups”。3、在页面右上方单击主机组（Create host group），在表单中输入参数。参数描述Group name输入唯一的主机组名称。在zabbix前端创建一台主机按照以下步骤在Zabbix前端创建一台主机：1、以admin用户登录Zabbix前端Portal。2、切换到“配置 (Configuration)>主机 (Hosts)” 。3、在右侧点击创建主机（Create host） (或者在主机名上编辑一台已有的主机）。在表单中输入主机的相关参数。已经存在的主机上使用Clone和Full clone按钮的形式创建一个新的主机，点击Clone将保留所有的主机参数和模板链接（保留所有的模板入口），Full clone将额外保留直属实体（应用集、监控项、触发器、视图、底层自动发现规则和Web定制的场景）。配置如下：Host标签页包含了通用的主机属性：表1 参数说明属性描述Host name输入一个唯一的主机名。允许有字母、空格、圆点、破折号和下划线。注意： 由于Zabbix agent运行在你所配置的那台主机上，所以此agent配置文件的参数“Hostname”必须和这里输入的主机名是一致的。 在配置主动代理检查的过程中参数中的主机名也是需要的。Visible name显示名称。如果你设置了这个名称，它将会在列表、拓扑图等地方显示。此属性支持UTF-8 。Groups选择主机所属主机组。一个主机必须至少属于一个主机组。Interfaces支持这几种主机接口类型: Agent、SNMP、JMX和IPMI。要增加一个新接口，在Interfaces区域点击“Add” ，输入IP/DNS、Connect to和Port信息。注意: 用在任何监控项的接口都不能被删除，并且Remove链接是灰色的。在SNMP接口使用Use bulk requests选项来为每个接口启用和禁用SNMP请求的批量处理。IP address主机的IP地址（可选），IP和DNS至少填一个。DNS name主机的DNS名称（可选），IP和DNS至少填一个。Connect to点击对应的按钮告诉Zabbix服务器采用哪种模式从代理端获取数据:IP - 连接到主机的IP地址（推荐）。DNS - 连接到主机的DNS名称。PortTCP/UDP端口。默认端口：Zabbix agent 10050，SNMP agent 161，JMX 12345，IPMI 623。Description填写主机描述。Monitored by proxy主机可以被Zabbix服务器或者Zabbix代理服务器监控：(no proxy) - Zabbix服务器监控主机。Proxy name - Zabbix代理服务器“代理服务器名称”监控主机。Enabled选中此项激活主机，准备接受监控。如果没选中，表示主机未激活，不能被监控。Templates选项卡允许你将templates链接到主机。所有实体（监控项、触发器、图表和应用集）将从模板继承。要链接一个新模板，请开始在“Link new templates”区域键入，直到匹配键入的模板列表出现。向下滚动选择你希望链接的模板。当所有的模板链接完成后，单击“Add”。要取消链接模板，请使用Linked templates区域的两个选项之一：Unlink：取消链接模板，但保留它的监控项、触发器和图表。Unlink and clear ：取消链接模板并删除所有它的监控项、触发器和图表。列出的模板名可以点击跳转到模板配置表单。

第三方接入告警项配置和开发总体流程：

英文原文：cid:link_1说明：【】中内容为方便解释自己加的在这篇文章中，我们描述了Pinpoint的技术细节比如请求追踪（transaction tracing）和字节码插装（bytecode instrumentation）,同时说明了应用于Pinpoint agent中的优化方法，它可以修改字节码并记录性能数据。分布式事务追踪，基于Google的Dapper基于Google的Dapper，Pinpoint可以追踪到一个事务（transaction）中的分布式请求【这里说白了即指Pinpoint能够追踪到从应用A到应用B的一次分布式请求中的所有数据】Google Dapper 中分布式事务追踪是如何工作的分布式追踪系统的目的就是对于分布式系统中的两个节点Node1和Node2，当有一条消息从Node1发送到Node2时，分布式追踪系统能够识别Node1和Node2之间的关系（如图1所示）图1. 分布式系统中的消息关系问题在于没有方法能够识别消息之间的关系，比如我们无法辨别从Node1发送的N条消息和Node2接收到的N条消息之间的关系，换句话说，当从Node1发送第X条消息时，你无法在Node2收到的N条消息里分辨出Node1发送的第X条消息。有系统尝试在操作系统或者TCP级别追踪这些消息，然而实现复杂度高，同时性能低，因为需要针对每个协议单独实现。此外，很难准确地跟踪消息。Google的Dapper提供了一种解决上述问题的简单方法。方案便是当发送消息的时候，在应用级别给这些消息加上标签，从而能够使这些消息关联起来。例如，对于Http请求，它在Http请求头中加入标签信息，并使用这个标签信息追踪消息。可以查看论文了解Dapper :cid:link_2Pinpoint 基于Google的Dapper中的追踪技术，同时进行了修改，在远程调用的时候，pinpoint会在调用方加入应用级别的标签数据来追踪分布式事务（请求），标签数据由一系列的key组成，在pinpoint中定义为 TraceIdPinpoint中的数据结构在pinpoint中，核心的数据结构包括：Spans，Traces 以及 TraceIdsSpan: RPC（远程过程调用）追踪的基本单元，它代表了远程调用到达时处理的工作并且包含了追踪数据【直白点说，你可以把一个应用当作一个Span】，为了确保代码级别的可见性，Span有子节点，用SpanEvent【这个就相当于一次方法调用，故一个Span可能大部分都会有多个SpanEvent】表示，每个Span都包含一个TraceId，每个Span有一个SpanId和ParentSpanId，如果这个Span为请求的最原始的发起者，ParentSpanId为-1。Trace: Span的集合，由关联的RPC调用组成【这个也就是说在分布式系统中，每个应用代表一个Span，不同应用的一次全链路的请求表示一个Trace，即一个Trace会包含多个Span】，在同一个链路中的Spans共享同一个TransactionId，Trace通过SpanIds和ParentSpanIds排序成分层树结构。TraceId: 一系列key的集合，这些key包括：TransactionId，SpanId和ParentSpanId，TransactionId代表消息的id，这个id在一次追踪过程中唯一，SpanId和ParentSpanId代表远程调用的父子关系。TransactionId(TxId): 一次事务（请求）中分布式系统发送/接收的消息id，在整个请求关联的所有应用服务中必须唯一SpanId: 处理接收RPC消息的应用id，在RPC消息到达某个节点时生成ParentSpanId(pSpanId): 发起RPC调用的父span的 SpandId，如果某个节点时整个事务请求的发起者，那么它没有父span，对于这种情况，我们使用 -1表示这是整个事务请求的根spanGoogle的Dapper和NAVER的Pinpoint的术语的不同处Pinpoint中的术语 TransactionId和Google的Dapper中的术语TraceId意思相同，TraceId在Pinpoint中表示的是一系列key的集合【前面提到的TransactionId,SpanId等】TraceId如何工作？下图展示的是TraceId的行为，里面包括了三次RPC请求以及4个节点【这个就相当于一次请求，即一次transaction】图2. TraceId行为样例在图2中，TransactionId(TxId)表示的是三次不同的调用通过TransactionId(TxId)关联在一起作为一次事务请求（transaction），然而，TransactionId自身并不能明显的描述RPC之间的关系。为了识别RPC之间的关系，我们需要SpanId以及ParentSpanId(pSpanId)。假设节点是tomcat，你可以想象成 SpanId是处理http请求的线程，parentSpanId代表的是发起这次RPC请求的SpanId【这里假设应用A和B，A调B，A和B都是一个Node，同时A是SpanIdA，B是SpanIdB，因为是A调B，那么B的parentSpanId就是SpanIdA了】Pinpoint通过TransactionId查找关联的多个Span，同时根据SpanId和ParentSpanId对他们进行层次关系排序。SpanId和ParentSpanId都是64位的长整型，由于数字是随机产生的，因此可能会有冲突，但是考虑到64位长整型的范围是 -9223372036854775808到9223372036854775807，冲突发生的几率很小。如果真的产生冲突，Pinpoint和Google的Dapper一样，会让开发者知道发生的情况而不是解决冲突。TransactionId由 agentId，JVM启动时间以及一个序列号组成agentId: JVM启动时用户创建的id；在安装了Pinpoint的整个服务器组内必须唯一，最简单的方式是使用主机名hostname，因为通常主机名不会重复，如果你需要在服务器组运行多个JVM，可以在主机名前加下前缀避免重复jvm启动时间：用于保证生成的唯一序列号（SequenceNumber）从0开始【这里没怎么懂】，这个值用来当用户不小心创建了相同的agentId时避免transactionId冲突SequenceNumber: Pinpoint agent产生的id，从0开始递增，每条消息都会产生一个Dapper和Zipkin（Twitter的一个分布式追踪平台），随机生成TraceIds(对应Pinpoint中的TransactionIds)，认为id冲突是很常见场景。但是，在Pinpoint中，我们努力避免这种冲突，有两个选择：一是id中的数量量小但是冲突的可能性很高；另外一种是id的数据量大但是冲突的可能性低，Pinpoint选择的是后一种【也就是说pinpoint为了使TransactionId的冲突减少，TransactionId的数据会大点】可能有更好的方法来解决这个问题，我们提出几个想法，比如通过一个中心key服务器来产生key【这里指的应该就是前面的TransactionId】，但是由于性能和网络问题没有实现。目前我们仍然在考虑批量产生key作为替代解决方案。因此在将来，可能会开发出这样的方法，但就目前而言，我们采用了一种简单的方法。在Pinpoint中，TransactionId是可变的数据。字节码注入，无需修改代码前面我们解释了分布式事务追踪。一种方法是让开发者修改自己的代码，当发生RPC调用的时候允许开发者增加标记信息，然后修改代码负担比较重。Twitter的Zipkin使用修改后的类库以及容器（Finagle）来提供分布式追踪的功能，然后它同样需要开发者修改代码，我们想要的是不修改代码就能实现追踪功能，同时提供代码级别的可见性，Pinpoint使用了字节码注入技术（bytecode instrumentation），Pinpoint的Agent干预（拦截）调用RPC的代码以便自动处理标记信息。克服字节码注入的缺点如下所说，有两种方式实现分布式追踪。字节码注入是一种自动的方式手动方式：开发者使用Pinpoint提供的api在关键位置记录数据自动方式：开发者无需修改代码，Pinpoint决定那些代码需要干预和增强两种方式的优缺点如下方法优点缺点手动追踪需要较少的开发资源；API可以变得简单因此bug也少开发者需要修改代码；跟踪级别低【这里的跟踪级别高低怎么理解？】自动追踪开发者无需修改代码；可以收集到更精确的数据需要高素质的开发人员可以快速的识别哪些代码需要跟踪，以及在哪些跟踪点需要处理；由于使用了字节码注入等高级开发技巧，bug也会多字节码注入技术会引入更高的难度和风险，但是有很多益处。尽管字节码注入需要很多的开发资源，但是部署应用的时候几乎不需要（即开发难，部署运行简单）【中间一段无关痛痒的分析字节码注入方式的好处就不翻译了】字节码注入的价值我们使用字节码注入（自动方法）来实现除了上面提到的还有下面一些理由隐藏API如果API是暴露给开发者使用，作为API的提供者，想根据我们的需要修改API时往往会受到限制，这种限制会给我们很多压力我们可能会修改API来纠正错误或者添加新功能，然而如果修改受到限制的话，我们很难完善API，解决此类问题的最佳答案是可扩展的系统设计，这并不是每个人都知道的简单选择。 创建完美的API设计几乎是不可能的，因为我们无法预测未来。通过字节码注入技术，我们不用担心暴露追踪API导致的这些问题，也可以持续完善设计而不用考虑依赖关系。想要使用Pinpoint开发应用的开发者需要注意API可能会修改，因为我们的第一优先级是提高性能和设计。容易开始或者关闭使用字节码注入的缺点是当分析的类库或者Pinpoint本身有问题时，你的应用程序会受到影响，但是你不许需要修改代码，只需要禁用Pinpoint即可解决这种问题通过在JVM启动脚本中添加以下三行（与Pinpoint Agent的配置相关联），可以轻松地为应用程序启用Pinpoint：-javaagent:$AGENT_PATH/pinpoint-bootstrap-$VERSION.jar-Dpinpoint.agentId=<Agent's UniqueId>-Dpinpoint.applicationName=<The name indicating a same service (AgentId collection)>123如果因为Pinpoint导致什么问题，只需要删除启动参数里的配置字节码注入是如何工作由于字节码注入需要处理Java字节码，往往会增加开发风险同时降低开发效率，此外，开发人员容易犯错误。在Pinpoint中，我们通过抽象出拦截器提高开发效率和可访问性，Pinpoint在类加载时干预应用程序代码，注入必要的代码来跟踪分布式请求以及性能信息，由于跟踪代码直接注入应用程序代码，因此这提高了性能。图3. 字节码注入的基本原理在Pinpoint中，API拦截部分和数据记录部分是分开的。 拦截器被注入到我们想要跟踪的方法中，并调用before()和after()方法来处理数据记录。 通过字节码检测，Pinpoint Agent只从必要的方法记录数据，这使得分析数据的大小变得紧凑。优化Pinpoint Agent的性能下面我们描述下如何优化Pinpoint agent的性能使用二进制格式（Thrift）你可以使用二进制格式（Thrift）加快编码速度，尽管它很难使用和调试，但是可以提高网络利用率以及减小生成的数据大小使用可变长度编码和格式优化记录数据如果你把一个长整型转化成定长的字符串，数据大小是8字节，但是，如果你使用可变长度编码，跟你长整型数字的大小，转化后的数据长度可能是1到10字节。为了减少数据大小，Pinpoint通过Compact Protocol of Thrift将数据编码为可变长度字符串，并记录要针对编码格式进行优化的数据。 Pinpoint Agent通过将基于根方法的剩余时间转换为矢量值来减少数据大小。可以通过Google开发者的 Base 128 Varints来了解更多关于可变长度编码图4.定长编码和可变长度编码的比较如图4，有三个不同的方法开始调用和完成调用，你需要在这6处记录时间，采用定长编码，需要48字节（6处*8字节）。Pinpoint agent使用可变长度编码，并根据其对应的格式记录数据，同时以根方法的起始时间为基准，计算其他方法处与基准的差异（矢量值）来计算时间，由于向量值是一个小数字，它消耗少量字节，因此只消耗13个字节而不是48字节如果执行方法需要更多时间，即使使用可变长度编码，也会增加字节数。 但是，它仍然比固定长度编码更有效。使用常量表替换重复的API信息，SQL语句以及字符串我们希望pinpoint能够实现代码级别的追踪，然而会造成数据变大的问题，每次高精度的数据发送到服务端，数据变大会增加带宽开销。为了解决这种问题，我们采用了一种策略，通过在远程的HBase服务中创建一张常量表，既然每次发送“方法A”的数据到Pinpoint的Collector都有负载，Pinpoint Agent把"方法A"的数据转化成一个ID并在HBase的常量表中存储方法A的信息，并且使用这个ID继续后面的追踪，当用户在网站上检索跟踪数据时，Pinpoint Web会在常量表中搜索相应ID的方法信息并重新组织它们。 使用同样的方法用于减少SQL或常用字符串中的数据大小处理批量请求的采样Naver提供的在线门户服务请求非常庞大。 单个服务每天处理超过200亿个请求。 跟踪此类请求的一种简单方法是根据需要扩展网络基础架构和服务器以满足请求的数量。 但是，这不是处理这种情况的经济有效的方法。在Pinpoint中，您可以只收集采样数据，而不是跟踪每个请求。 在请求很少的开发环境中，每个数据都会被收集。 在请求很大的生产环境中，只收集整个数据的1~5％，这足以分析整个应用程序的状态。 通过采样，您可以最大限度地减少应用程序中的网络开销，并降低网络和服务器等基础设施的花费。Pinpoint中的采样方法：Pinpoint支持一个计数采样器（Counting Sampler），如果设置为10，那么只会收集十分之一的请求。我们计划添加新的采样器来更高效地收集数据使用异步数据传输最小化被终止的应用线程Pinpoint不会干挠应用程序线程，因为数据编码和远程消息传输是通过异步线程实现的通过UDP传输数据与Google的Dapper不同，Pinpoint通过网络传输数据以确保数据速度。 当数据流量突然爆发时，与你的服务共享网络可能是一个问题。 在这种情况下，Pinpoint Agent开始使用UDP协议这样你的服务便有网络连接优先级【这里也是说如果你的服务使用TCP，pinpoint 使用UDP的话，TCP优先级高于UDP?】注意: 数据传输的API可以被替换，因为他是独立的接口，你可以替换成不同的实现，比如通过本地文件Pinpoint应用样例下面是如何在你的应用程序中获取数据的例子，这样你能全面理解上面描述的内容。图5展示当你的TomcatA和TomcatB安装了Pinpoint你可以看到什么，你可以看到单个节点作为单个请求事务的追踪数据，表示的是分布式事务追踪的流图5 实践中的pinpoint样例下面描述了Pinpoint在每个方法中做的事情当请求到达TomcatA时，Pinpoint Agent产生了一个TraceIdTX_ID: TomcatA^ TIME^1SpanId: 10ParentSpanId: -1(根)从Spring MVC controllers中记录数据干预 HttpClient.execute()方法的调用，并在HttpGet中组装TraceId创建子 TraceIdTX_ID: TomcatA^ TIME^ 1 -> TomcatA^ TIME^1SPAN_ID: 10->20PARENT_SPAN_ID: -1->10(父SpanId) ——在HTTP头部中配置子TraceIdHttpGet.setHeader(PINPOINT_TX_ID,“TomcatA^ TIME^1”)HttpGet.setHeader(PINPOINT_SPAN_ID,“20”)HttpGet.setHeader(PINPOINT_PARENT_SPAN_ID,“10”)将打了标记的请求传输到TomcatBTomcatB检查传输过来的请求头部HttpServletRequest.getHeader(PINPOINT_TX_ID)——TomcatB成了子节点，因为它识别到了header中的TraceIdTX_ID: TOMCATA^ TIME^1SPAN_ID: 20PARENT_SPAN_ID: 10注意到子节点的SPAN_ID其实是由父节点创建好的从Spring MVC controllers中记录数据并完成请求当TomcatB中的请求完成时Pinpoint agent将追踪数据发送到Pinpoint Collector存储到HBase来自TomcatB的HTTP调用终止后，TomcatA的请求完成。 Pinpoint Agent将跟踪数据发送到Pinpoint Collector以将其存储在HBase中UI从HBase读取跟踪数据，并通过对树进行排序来创建调用堆栈总结Pinpoint是另一个与你的应用程序一起运行的应用程序。 使用字节码检测使Pinpoint看起来像是不需要修改代码。 通常，字节码检测技术使应用程序容易受到风险的影响; 如果Pinpoint出现问题，它也会影响你的应用程序。 但就目前而言，我们并没有摆脱这些威胁，而是专注于提高Pinpoint的性能和设计。 因为我们认为这使得Pinpoint更有价值。 因此，是否使用Pinpoint是由你决定的。我们仍然需要做大量的工作来改进Pinpoint。 尽管Pinpoint不完整，但它作为一个开源项目被发布了; 我们不断努力开发和改进Pinpoint，以满足你的期望