性能问题
故障和提示
日志
- 读取日志
- 启用日志
指标
Prometheus
Grafana仪表板
OAuth2
帮助
聊天室
论坛
Stack Overflow

性能问题

这篇文档中会描述一些比较常见的情况可用作问题排查和处理的思路。

消息丢失

消息延迟

如果某些规则引擎使用RETRY_ALL, RETRY_FAILED, RETRY_TIMED_OUT或RETRY_FAILED_AND_TIMED_OUT策略失败的节点可能会阻止整个消息队列的处理。

可以执行以下操作来查找问题的原因：

能过分析规则引擎统计仪表板了解消息是否失败或超时并在仪表板底中以找到规则引擎内部异常的描述信息和规则节点名称。
找出失败的规则节点后可以启用调试查看那些消息到导致规则节点失败并了解详细的错误描述。

提示：通过创建单独的队列把不稳定的用例与其它规则琏分开使故障只会影响单独的队列而不会影响整个系统的处理，可以使用设备配置进行隔离。

提示：如果在调用某些处部服务(REST API call,Kafka,MQTT等)的规则节点发生Failure事件可以将失败的消息存储在数据库并发送一些通知或日志。

可能会遇到规则引擎消息处理延迟时可以执行以下操作来查找问题的原因：

检查规则引擎统计仪表板中是否存在超时，规则节点超时会减慢队列处理速度并导致延迟。
检查CPU使用率 for the following services:
- ThingsBoard服务(tb-nodes, tb-rule-engine和tb-core, transport)某些服务的CPU负载过高意味着需要垂直扩展该部分。
- PostgreSQL和pgpool(如果高可用模式)Postgres上的高负载会导致所有与Postgres相关的规则节点（保存属性、读取属性等）以及整个系统的处理速度变慢。
- Cassandra(如果使用Cassandra作为时序数据存储)Cassandra上的高负载会导致所有与Cassandra相关的规则节点的处理速度变慢（保存时序数据等）。
- Queue无论任何消息队列请保证具有足够资源。
检查消费者延迟 (如果使用Kafka消息队列)。
启用消息日志记录最慢的规则节点名称。
按不同队列隔离用例如果将设备分组处理则应配置单独的规则引擎队列，可以根据某些逻辑将消息隔离在不同的队列保证互不影响。

故障和提示

规则引擎

可以查看规则链在处理时是否存在故障、超时或异常并通过此处链接找到更多详细信息。

Kafka

注意： 本方法只适用于Kafka消息队列。

你可以检查消息处理是否存在问题通过此连接了解更多关于消费者滞后引起的规则引擎处理故障（系统中的消息用队列传输可以故障来自于分析规则引擎，传输组件，核心服务等）。

CPU/内存

可以通过登录服务器/容器/pod并执行linux的top命令查看CPU和内存使用情况并为某些服务提供足够资源使用Prometheus和Grafana可以更方便进行指标监控。

如果发现某些服务有时CPU使用率会在100%则可以在群集中创建新节点进行水平扩展或者通过增加CPU数量来垂直扩展服务。

处理消息日志

通过修改日志配置启用消息的DEBUG日志信息。

<logger name="org.thingsboard.server.service.queue.TbMsgPackProcessingContext" level="DEBUG" />

你可以在日志看见以下消息：

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日志存储服务器节点的以下目录中：

/var/log/thingsboard

日志查看方式：

独立部署

Docker-Compose部署

Kubernetes部署

查看运行日志：

tail -f /var/log/thingsboard/thingsboard.log

通过grep命令仅显示包含所需字符串的信息例如：使用以下命令来检查后端是否有任何错误：

cat /var/log/thingsboard/thingsboard.log | grep ERROR

查看运行日志：

docker compose logs -f tb-core1 tb-core2 tb-rule-engine1 tb-rule-engine2

查看关与规则引擎相关的日志：

docker compose logs -f tb-rule-engine1 tb-rule-engine2

通过grep命令仅显示包含所需字符串的信息例如：使用以下命令来检查后端是否有任何错误：

docker compose logs tb-core1 tb-core2 tb-rule-engine1 tb-rule-engine2 | grep ERROR

提示：将日志写入文件后通过文本编辑器进行分析：

docker compose logs -f tb-rule-engine1 tb-rule-engine2 > rule-engine.log

注意： 查看容器日志：

docker ps
docker exec -it NAME_OF_THE_CONTAINER bash

查看集群的所有Pod：

kubectl get pods

查看指定容器日志：

kubectl logs -f POD_NAME

查看ThingsBoard节点日志：

kubectl logs -f tb-node-0

通过grep命令仅显示包含所需字符串的信息例如：使用以下命令来检查后端是否有任何错误：

kubectl logs -f tb-node-0 | grep ERROR

提示：将日志写入文件后通过文本编辑器进行分析：

kubectl logs -f tb-node-0 > tb-node-0.log
kubectl logs -f tb-node-1 > tb-node-1.log

注意： 查看容器日志：

kubectl exec -it tb-node-0 -- bash
cat /var/log/thingsboard/tb-node-0/thingsboard.log

启用日志

ThingsBoard支持启用/禁用日志功能用于故障排查所需的信息，配置的logback.xml文件在服务器节点的以下目录中：

/usr/share/thingsboard/conf

logback.xml配置的示例：

<!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部署

通过独立部署日志配置/usr/share/thingsboard/conf/logback.xml文件目录。

通过docker-compose部件将/config映射至本地的(./tb-node/conf)目录中并更新logback.xml需要执行以下操作：

通过Kubernetes部署使用ConfigMapkubernetes Entity提供带有配置的TB节点并更新logback.xml需要执行以下操作：

edit common/tb-node-configmap.yml
kubectl apply -f common/tb-node-configmap.yml

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配置请单击此处。

帮助

聊天室

在线向官方工程师分享你的想法

论坛

官方用户论坛获得技术支持

Stack Overflow

技术问答社区

如果上述任何指南都没有你想要的答案请联系ThingsBoard团队。

联系我们

本页目录

Troubleshooting

性能问题

故障和提示

规则引擎

Kafka

CPU/内存

处理消息日志

Redis

日志

读取日志

启用日志

指标

Prometheus

tb-node

transport

PostgreSQL

Cassandra

Grafana仪表板

OAuth2

帮助

聊天室

论坛

Stack Overflow