Command line access
The following guide describes a method to debug an edge application by deploying the edge application to a system and logging the result of each container.
The SSH command is used to gain access to a remote command line. With the private key, the following command will start an SSH session;
ssh -i <path to private key> <username>@$<ip address or domain name>Some systems may instead use a username and password upon login, where the
-i parameter would not be needed. Further details of gaining remote access to the system are case-dependent and beyond the scope of this guide.
The weeve Agent is a
systemd unit. Check the status with systemctl is-active weeve-agent. More information can be displayed with systemctl status weeve-agent.service.The below screenshot displays a working (active) weeve agent with the latest log messages. This weeve Agent is sending regular heartbeat status messages.
A deployed edge application takes the form of a docker network and a docker container for each module. Running the command
docker container ls -a can assist in gaining an overview of the edge applications running or deployed to the node. The following image (click to expand) and the code block below, show 2 edge applications running, 1 edge application is not running. 
The
docker ps command, an alias for docker network ls shows the running containers. Here we can identify which edge applications are running on the system by the containers and their names. The naming convention for containers as defined in the internal specifications, begins with the network name. [email protected]:~$ docker ps
CONTAINER ID IMAGE NAMES
71d5e2e768d8 weevenetwork/slack-alert:latest Reject_rate_003.weevenetwork_slack-alert_latest.2
0c1f7447ba0b weevenetwork/comparison-filter:latest Reject_rate_003.weevenetwork_comparison-filter_latest.1
7ceb7ef4fe7f weevenetwork/mqtt-ingress:latest Reject_rate_003.weevenetwork_mqtt-ingress_latest.0
34974f140c33 weevenetwork/slack-alert:latest Hilscher_002.weevenetwork_slack-alert_latest.3
e5fb514b1332 weevenetwork/comparison-filter:latest Hilscher_002.weevenetwork_comparison-filter_latest.2
18426d2d13b5 weevenetwork/fluctuation-filter:latest Hilscher_002.weevenetwork_fluctuation-filter_latest.1
An edge application runs within a dedicated docker network. The network name is formed from the (edge application) manifest name. Below, we can identify the first edge application
[email protected]:~$ docker network ls
NETWORK ID NAME DRIVER SCOPE
9938769646c9 Hilscher_002 bridge local
966d2d080b88 Reject_rate_003 bridge local
16d57ce1792e Test_001 bridge local
3c4afbf44b27 bridge bridge local
b8c0eff61d4c host host local
b87d901e7995 none null local
A docker network, like other resources within docker, can have attached metadata. The metadata can be retrieved with the command
docker network inspect. [email protected]:~$ docker network inspect Hilscher_002
...
"Labels": {
"manifestID": "276c0fb5-b86c-46a6-b29d-e1ffebc858c7",
"name": "Hilscher",
"version": "1.0.0"
}
...
Here we can see the manifestID, the edge application name, and the version of the manifest.
With the above commands, ensure all containers exist, and the details of the edge application match expectations.
With the command
docker logs, more information can be retrieved from stopped or exited containers. If the container is not started, first check the logs of the modules sequentially.
If a problem is clear from the logs, either the parameterization of the container is incorrect, or the container itself has a technical issue. In the latter case, the container can be run locally, or even rebuilt. Advanced debugging of docker containers is beyond the scope of this guide.
Similarly, the docker logs may (if the module was developed with appropriate logging) contain details regarding the intercontainer communication. The following screenshot displays suitably informative logging information, with each data item being logged with the timestamp.
Other started containers with the 'UP' status but may be transmitting no data, or incorrect data. In this case, either the parameterization of the container is incorrect, or the container itself has a technical issue. In the latter case, the container can be run locally, or even rebuilt. Advanced debugging of docker containers is beyond the scope of this guide.
Last modified 11mo ago