性能问题
这篇文档中会描述一些比较常见的情况可用作问题排查和处理的思路。
如果某些规则引擎使用 可以执行以下操作来查找问题的原因: 提示:通过创建单独的队列把不稳定的用例与其它规则琏分开使故障只会影响单独的队列而不会影响整个系统的处理,可以使用设备配置进行隔离。 提示:如果在调用某些处部服务(REST API call,Kafka,MQTT等)的规则节点发生Failure事件可以将失败的消息存储在数据库并发送一些通知或日志。 |
可能会遇到规则引擎消息处理延迟时可以执行以下操作来查找问题的原因:
|
故障和提示
规则引擎
可以查看规则链在处理时是否存在故障、超时或异常并通过此处链接找到更多详细信息。
Kafka
注意: 本方法只适用于Kafka消息队列。
你可以检查消息处理是否存在问题通过此连接了解更多关于消费者滞后引起的规则引擎处理故障(系统中的消息用队列传输可以故障来自于分析规则引擎,传输组件,核心服务等)。
CPU/内存
可以通过登录服务器/容器/pod并执行linux的top
命令查看CPU和内存使用情况并为某些服务提供足够资源使用Prometheus和Grafana可以更方便进行指标监控。
如果发现某些服务有时CPU使用率会在100%则可以在群集中创建新节点进行水平扩展或者通过增加CPU数量来垂直扩展服务。
处理消息日志
通过修改日志配置启用消息的DEBUG日志信息。
1
<logger name="org.thingsboard.server.service.queue.TbMsgPackProcessingContext" level="DEBUG" />
你可以在日志看见以下消息:
1
2
3
4
5
6
7
8
9
2021-03-24 17:01:21,023 [tb-rule-engine-consumer-24-thread-3] DEBUG o.t.s.s.q.TbMsgPackProcessingContext - Top Rule Nodes by max execution time:
2021-03-24 17:01:21,024 [tb-rule-engine-consumer-24-thread-3] DEBUG o.t.s.s.q.TbMsgPackProcessingContext - [Main][3f740670-8cc0-11eb-bcd9-d343878c0c7f] max execution time: 1102. [RuleChain: Thermostat|RuleNode: Device Profile Node(3f740670-8cc0-11eb-bcd9-d343878c0c7f)]
2021-03-24 17:01:21,024 [tb-rule-engine-consumer-24-thread-3] DEBUG o.t.s.s.q.TbMsgPackProcessingContext - [Main][3f6debf0-8cc0-11eb-bcd9-d343878c0c7f] max execution time: 1. [RuleChain: Thermostat|RuleNode: Message Type Switch(3f6debf0-8cc0-11eb-bcd9-d343878c0c7f)]
2021-03-24 17:01:21,024 [tb-rule-engine-consumer-24-thread-3] INFO o.t.s.s.q.TbMsgPackProcessingContext - Top Rule Nodes by avg execution time:
2021-03-24 17:01:21,024 [tb-rule-engine-consumer-24-thread-3] INFO o.t.s.s.q.TbMsgPackProcessingContext - [Main][3f740670-8cc0-11eb-bcd9-d343878c0c7f] avg execution time: 604.0. [RuleChain: Thermostat|RuleNode: Device Profile Node(3f740670-8cc0-11eb-bcd9-d343878c0c7f)]
2021-03-24 17:01:21,025 [tb-rule-engine-consumer-24-thread-3] INFO o.t.s.s.q.TbMsgPackProcessingContext - [Main][3f6debf0-8cc0-11eb-bcd9-d343878c0c7f] avg execution time: 1.0. [RuleChain: Thermostat|RuleNode: Message Type Switch(3f6debf0-8cc0-11eb-bcd9-d343878c0c7f)]
2021-03-24 17:01:21,025 [tb-rule-engine-consumer-24-thread-3] INFO o.t.s.s.q.TbMsgPackProcessingContext - Top Rule Nodes by execution count:
2021-03-24 17:01:21,025 [tb-rule-engine-consumer-24-thread-3] INFO o.t.s.s.q.TbMsgPackProcessingContext - [Main][3f740670-8cc0-11eb-bcd9-d343878c0c7f] execution count: 2. [RuleChain: Thermostat|RuleNode: Device Profile Node(3f740670-8cc0-11eb-bcd9-d343878c0c7f)]
2021-03-24 17:01:21,028 [tb-rule-engine-consumer-24-thread-3] INFO o.t.s.s.q.TbMsgPackProcessingContext - [Main][3f6debf0-8cc0-11eb-bcd9-d343878c0c7f] execution count: 1. [RuleChain: Thermostat|RuleNode: Message Type Switch(3f6debf0-8cc0-11eb-bcd9-d343878c0c7f)]
Redis
注意: 本方法只适用于Redis缓存服务。
ThingsBoard会在运行时重新加载已经损坏的缓存,如果你需要清除缓存可以登录Redis服务器/容器/pod并执行redis-cli FLUSHALL
命令。
如果你正在排查某些无法确定的问题可以先清除Redis缓存以确定不是缓存原因。
日志
读取日志
ThingsBoard日志存储服务器节点的以下目录中:
1
/var/log/thingsboard
日志查看方式:
查看运行日志:
通过grep命令仅显示包含所需字符串的信息例如:使用以下命令来检查后端是否有任何错误:
|
查看运行日志:
查看关与规则引擎相关的日志:
通过grep命令仅显示包含所需字符串的信息例如:使用以下命令来检查后端是否有任何错误:
提示:将日志写入文件后通过文本编辑器进行分析:
注意: 查看容器日志:
|
查看集群的所有Pod:
查看指定容器日志:
查看ThingsBoard节点日志:
通过grep命令仅显示包含所需字符串的信息例如:使用以下命令来检查后端是否有任何错误:
提示:将日志写入文件后通过文本编辑器进行分析:
注意: 查看容器日志:
|
启用日志
ThingsBoard支持启用/禁用日志功能用于故障排查所需的信息,配置的logback.xml文件在服务器节点的以下目录中:
1
/usr/share/thingsboard/conf
logback.xml配置的示例:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
<!DOCTYPE configuration>
<configuration scan="true" scanPeriod="10 seconds">
<appender name="fileLogAppender"
class="ch.qos.logback.core.rolling.RollingFileAppender">
<file>/var/log/thingsboard/thingsboard.log</file>
<rollingPolicy
class="ch.qos.logback.core.rolling.SizeAndTimeBasedRollingPolicy">
<fileNamePattern>/var/log/thingsboard/thingsboard.%d{yyyy-MM-dd}.%i.log</fileNamePattern>
<maxFileSize>100MB</maxFileSize>
<maxHistory>30</maxHistory>
<totalSizeCap>3GB</totalSizeCap>
</rollingPolicy>
<encoder>
<pattern>%d{ISO8601} [%thread] %-5level %logger{36} - %msg%n</pattern>
</encoder>
</appender>
<logger name="org.thingsboard.server" level="INFO" />
<logger name="org.thingsboard.js.api" level="TRACE" />
<logger name="com.microsoft.azure.servicebus.primitives.CoreMessageReceiver" level="OFF" />
<root level="INFO">
<appender-ref ref="fileLogAppender"/>
</root>
</configuration>
通过配置文件可以对指定的类和包启用/禁用日志记录用于排查故障问题,在上面示例中默认日志记录级别是INFO对于其它包可以启用最详细的日志记录级别在上面示例中org.thingsboard.js.api
是跟踪详细信息,com.microsoft.azure.servicebus.primitives.CoreMessageReceiver
直接将日志设置为OFF操作所以配置进行修改后需要等待10秒。
日志查看方式:
通过独立部署日志配置 |
通过docker-compose部件将 |
通过Kubernetes部署使用ConfigMapkubernetes Entity提供带有配置的TB节点并更新logback.xml需要执行以下操作:
10秒配置自动生效。 |
指标
可以通过将环境变量METRICS_ENABLED
设置为true
和METRICS_ENDPOINTS_EXPOSE
设置为prometheus
值启用指标,ThingsBoard微服务方式运行时MQTT和COAP是一个独立的传输服务需要将环境变量设置为WEB_APPLICATION_ENABLE
设置为true
值,
WEB_APPLICATION_TYPE
设置为servlet
和HTTP_BIND_PORT
设置为8081
值以便使用Prometheus指标启用Web-Server。
这些指标可以通过https://<yourhostname>/actuator/prometheus
查看(无需认证)。
Prometheus
ThingsBoard推送给Prometheus的指标列表。
tb-node
- attributes_queue_${index_of_queue} (statsNames - totalMsgs, failedMsgs, successfulMsgs): 将attributes写入数据库
- ruleEngine_${name_of_queue} (statsNames - totalMsgs, failedMsgs, successfulMsgs, tmpFailed, failedIterations, successfulIterations, timeoutMsgs, tmpTimeout): 规则引擎内消息处理的统计信息
Some stats descriptions:
- tmpFailed: 失败并稍后重新处理的消息数
- tmpTimeout: 超时并稍后重新处理的消息数
- timeoutMsgs: 超时并在之后丢弃的消息数
- failedIterations: 处理消息包的迭代其中至少一条消息未成功处理
- ruleEngine_${name_of_queue}_seconds (当前租户tenantId): 不同队列的消息处理所花费时间的统计信息
- core (statsNames - totalMsgs, toDevRpc, coreNfs, sessionEvents, subInfo, subToAttr, subToRpc, deviceState, getAttr, claimDevice, subMsgs): 有关处理内部系统消息的统计信息
- toDevRpc: 来自传输服务的已处理RPC响应数
- sessionEvents: 来自传输服务的会话事件数
- subInfo: 来自运输服务的订阅信息数量
- subToAttr: 从传输服务订阅属性更新的数量
- subToRpc: 从传输服务订阅 RPC 的数量
- getAttr: 来自传输服务的“获取属性”请求数
- claimDevice: 来自传输服务的设备声明数
- deviceState: 对设备状态的已处理更改数
- subMsgs: 已处理的订阅数
- coreNfs: 已处理的特定“系统”消息的数量
- jsInvoke (statsNames - requests, responses, failures): 关于对JS执行程序的请求总数、成功和失败请求的统计信息
- attributes_cache (results - hit, miss): 有关进入缓存的属性请求量的统计信息
transport
- transport (statsNames - totalMsgs, failedMsgs, successfulMsgs): 有关传输从TB节点接收的请求的统计信息
- ruleEngine_producer (statsNames - totalMsgs, failedMsgs, successfulMsgs): 有关将消息从传输推送到规则引擎的统计信息。
- core_producer (statsNames - totalMsgs, failedMsgs, successfulMsgs): 有关将消息从传输推送到TB节点设备的统计信息。
- transport_producer (statsNames - totalMsgs, failedMsgs, successfulMsgs): 有关从传输到TB的请求的统计信息。
某些指标取决于保存时序数据的数据库的类型。
PostgreSQL
- ts_latest_queue_${index_of_queue} (statsNames - totalMsgs, failedMsgs, successfulMsgs): 有关将latest telemetry数据写入数据库的统计信息。
- ts_queue_${index_of_queue} (statsNames - totalMsgs, failedMsgs, successfulMsgs): 有关将telemetry数据写入数据库的统计信息。
Cassandra
- rateExecutor_currBuffer: 当前在 Cassandra 中持久保存的消息数。
- rateExecutor_tenant (当前租户tenantId): 受速率限制的请求数
- rateExecutor (statsNames - totalAdded, totalRejected, totalLaunched, totalReleased, totalFailed, totalExpired, totalRateLimited)
统计说明:
- totalAdded: 提交以持久化的邮件数
- totalRejected: 尝试提交以进行持久化时被拒绝的邮件数
- totalLaunched: 发送到Cassandra的消息数
- totalReleased: 成功持久化的消息数
- totalFailed: 未持久保存的消息数
- totalExpired: 未发送到Cassandra的过期消息数
- totalRateLimited: 由于租户的速率限制而未处理的消息数
Grafana仪表板
可以从此处导入预配置的Grafana仪表板。
注意:根据群集配置可能需要对仪表板进行更改。
通过docker-compose集群部署ThingsBoard后可以查看Grafana仪表板(有关更多信息请查看本指南))。
保证MONITORING_ENABLED
环境变量设置为true
部署后通过http://localhost:9090
和http://localhost:3000
(默认用户名admin
和密码foobar
)访问Prometheus和Grafana。
Grafana仪表板截图:
OAuth2
如果在配置OAuth后没有出现提供程序登录的按钮则是当“Domain name”和“Redirect URI Template”包含了错误值。
实例:
URL | 域名 | 重定向URI模板 |
---|---|---|
http://mycompany.com:8080 | mycompany.com:8080 | http://mycompany.com:8080/login/oauth2/code |
https://mycompany.com | mycompany.com | https://mycompany.com/login/oauth2/code |
“HOME”地址部分不需要包含”/”或其它字符。
管理员身份登录 设置 -> 网址末尾不包含“/”(例如:“https:// mycompany.com ”而不是“https://mycompany.com/”).
关于更多OAuth2配置请单击此处。
帮助
如果上述任何指南都没有你想要的答案请联系ThingsBoard团队。