Skip to main content
All CollectionsWebsite ManagementToolsLogs
Debugging with Logs using Rapyd: Accessing and Analyzing Server Activity
Debugging with Logs using Rapyd: Accessing and Analyzing Server Activity
Rapyd Team avatar
Written by Rapyd Team
Updated over a week ago

Debugging your website is a crucial aspect of ensuring optimal performance and user experience. Logs are an indispensable tool for identifying and resolving issues that may arise on your server. This article will guide you through accessing and analyzing server activity using logs, helping you effectively troubleshoot and maintain your WordPress website.

How to Use Rapyd to Debug with Logs

Before you start debugging, you need to access in Rapyd dashboard and choose your desired website from the dashboard. (For example we use Aviation Leaders here.)

Then click on Tools > Logs from left side menu.

Here you can see different type of logs as tabs ( Server Logs, Database Logs, Redis Logs). For each logs you will find Access logs for each day. You can find the whole detail of this Access log in Introduction to Logs on the Rapyd Dashboard

All of the logs contain different informations which can help to debug with logs.

Different Types of Logs for Debugging

Each log type provides valuable insights into different aspects of your server activity. Here's how When debugging a multi-layered application, utilizing Server logs, Database logs, and Redis logs in tandem can provide a comprehensive view of where issues might be occurring.

Server Logs for Debugging

Server logs can be your first line of defense in debugging. For example, if users are experiencing 404 errors, the server logs can show you exactly which resources are missing. Similarly, a 500 series error might indicate a server-side issue that could be due to a problem in your application code or a server configuration issue. By examining the server logs, you can narrow down the range of possible issues and identify the component that's most likely causing the problem.

Database Logs for Debugging

Database logs are invaluable when you're experiencing issues related to data integrity, performance, or authorization. For instance, if a certain query is taking too long, examining the slow query logs can give you insights into how to optimize it. Error logs can quickly reveal issues like syntax errors in your SQL queries or constraints that are being violated, helping you pinpoint exactly what needs to be fixed in your code or schema.

Redis Logs for Debugging

When debugging issues related to caching or session storage, Redis logs can be extremely helpful. These logs can show you errors in commands or data retrieval and storage actions, giving you clues on what might be going wrong. For example, if an application's session data isn't persisting as expected, the Redis logs might show that data isn't being written due to an error or misconfiguration. Redis logs can also provide metrics on cache hits and misses, helping you tune the performance of your caching mechanisms.

Best Practices for Debugging with Logs with Rapyd Dashboard

IP Address

The IP Address field indicates the origin of a request.

Debugging Benefits:

  • Knowing the IP address can help you identify if the request is coming from a trusted or

  • If you notice an unusually high number of requests or errors from a single IP, this could indicate a bot attack or a configuration issue specific to that location.

  • If a particular user reports an issue, filtering logs by their IP address can make it easier to debug their specific problem.

Status

The Status field typically indicates the HTTP status code returned by the server (e.g., 200 OK, 404 Not Found, 500 Internal Server Error).

Debugging Benefits:

  • The status code immediately informs you of the result of the request, allowing you to focus on problematic areas like 4xx or 5xx series codes.

  • A high number of 2xx statuses may indicate that the server is functioning well, while 3xx could point to multiple redirects that might slow down the website.

  • Codes like 401 and 403 can indicate authentication and authorization issues, while 500-level codes can signal server-side errors that need urgent attention.

Resource

The Resource field tells you what endpoint, URL, or resource was accessed or had an issue.

Debugging Benefits:

  • Knowing the resource helps you narrow down where to look in your codebase.

  • You can determine which resources are most frequently accessed or encounter the most errors, providing cues for optimization or refactoring.

  • If a resource relies on other services or databases, you can use this information to check the health of those dependencies.

CODE

A unique identifier or code helps you quickly pinpoint which part of your codebase is producing a specific log entry.

Debugging Benefit:

  • Helps you easily filter or search for log entries originating from a specific module, function, or block of code.

  • Can be useful in identifying patterns or sequences of operations that lead to an issue.

NOTE

A short, human-readable description of the log entry to provide context.

Debugging Benefit:

  • Gives you a quick overview of what each log entry is about, so you don't have to dig into detailed logs for basic understanding.

  • Makes it easier for team members unfamiliar with the code to contribute to debugging.

TIME

A timestamp indicating when the log entry was created.

Debugging Benefit:

  • Allows you to sort log entries chronologically to trace the sequence of events.

  • Helps in correlating events across different logs (e.g., server logs, database logs, application logs).

  • Makes it easier to match log events with real-world incidents reported by users.

LOG DETAILS

Detailed information related to the log entry, which could include variable values, stack traces, or even payload data.

Debugging Benefit:

  • Provides the nitty-gritty details you often need for debugging.

  • Allows you to understand the state of the application at the time of the log entry.

  • Can include additional context such as user IDs, session IDs, or other metadata that can be crucial for debugging complex issues.

How They Work Together

Initial Assessment:

You start by looking at the TIME and NOTE fields to get a high-level view of when things happened and what generally went wrong.

Filter and Narrow Down:

Use the CODE and TIME fields to filter the log entries, focusing on the relevant parts of the application within the specified timeframe.

In-depth Analysis:

Once you've narrowed down the potential points of failure, delve into the LOG DETAILS to understand the specifics of what went wrong.

Correlation:

If the issue spans multiple systems (e.g., frontend, backend, database), the TIME and CODE fields can help correlate entries across different logs.

Team Collaboration:

Structured logs make it easier for team members to work together on debugging. For instance, a developer who understands the CODE might focus on the LOG DETAILS, while a systems admin might use the TIME to correlate with server logs.

Conclusion

Effectively using logs to debug your WordPress website is an essential skill for maintaining a high-performing and secure site. By accessing and analyzing different types of logs on your web hosting dashboard, you can quickly identify and resolve server issues, ensuring a seamless user experience. Following best practices and working closely with your development team will make the debugging process even more efficient and productive.

Did this answer your question?