Troubleshooting

Workflow

When troubleshooting OSDx, it is important to follow a structured approach to identify the root cause of the problem. This article contains a set of tips to follow when troubleshooting OSDx.

First of all, take a look at this section to see if the device is properly set.

If the problem is network related, we need to run some basic checks to ensure the OSDx is working as expected. First, check how the network is behaving using monitoring traffic. If no solution is found, please refer to this chapter: Inspecting Network Layers, in order to see the status of communications and protocols.

In other cases, a service or feature is not working according to plan and we need to see why this is happening. If this is the case, inspecting logs could be the solution. We can enable them as detailed in chapter, or we can use Syslog to send the events to a remote server.

Another option could be to check if system resources are correct, or if there are issues related to CPU consumption (for example). Please check here to learn how to see all of this information.

Once all checks have been carried out and the relevant logs have been duly analyzed, non-solved issues can be escalated to the OSDx team. To provide enough feedback to the tech support team, please refer to this chapter: Reporting an Error.

Note

To make the most of all of these tips, a tool call journal proves very useful. Journal is responsible for collecting and managing system logs, giving the user data accesss to, for example, identify errors or monitor the system.

If we are able to connect to an OSDx device via ssh or telnet (preferably ssh), it would be wise to open different ssh connections on the same window, run system journal monitor in one of them, and use the others to execute tests while monitoring the behavior at the journal terminal.

More information about Journal and how to use it can be found here.