Gateway logs

Who it’s for

Engineers diagnosing a ThingsBoard IoT Gateway at the level where events are not enough — a connector failing to parse a message, a protocol handshake going wrong, an exception that only the log records. This is the last stop before opening a shell on the host.

What it does

The Gateway logs widget shows the gateway’s log output on the dashboard, over the dashboard’s time window. Pointed at a gateway device, it presents the log lines the gateway publishes, so a problem can be diagnosed from the platform rather than from the machine the gateway runs on.

• Logs without host access, which is often the difference between diagnosing a remote gateway and dispatching someone to it.
• The log follows the dashboard’s time window, so an investigation can be narrowed to the period around a failure.
• A connector state parameter key is configurable, tying the log view to the connector being examined.
• Access follows the dashboard, so log access is granted by dashboard permissions rather than by distributing host credentials.
• The Gateway logs widget shows what the gateway publishes: log forwarding must be enabled on the gateway, and its log level decides how much detail arrives.

How to set up

Data keys

The Gateway logs widget takes its content from the gateway device it is pointed at.

Key	Role	Type	Description
Gateway log keys	The log lines shown	Timeseries	Point the datasource at the gateway device. Log forwarding has to be enabled on the gateway for anything to arrive.

Logs

Setting	Default	Effect
Connector state parameter key	Unset	The key tying the log view to a connector’s state

Enable log forwarding and set the gateway’s log level before relying on this widget. At a default level the log carries little detail, and raising it is a gateway-side change rather than a widget setting.

How to customize

• To tie the view to a connector — set the Connector state parameter key to that connector’s state key.
• To narrow an investigation — set the dashboard’s time window to the period around the failure, since the log follows it.

Tips

• Raise the gateway’s log level only while investigating, and lower it afterwards. Debug logging on a busy gateway produces a volume of telemetry that costs storage and buries the next problem, and it is easy to leave on.
• Read the events list first and come here for the detail. Events say what happened and are readable at a glance; the log says why and is not, so starting with the log usually means reading a great deal before knowing what to look for.