Download the PHP package popphp/pop-debug without Composer

pop-debug

• Overview
• Install
• Quickstart
• Handlers
  • Exception
  • Memory
  • Message
  • PHP
  • Query
  • Request
  • Time
• Storage
  • File
  • Database
• Formats
• Retrieving
• Logging

Overview

pop-debug is a debugging component that can be used to hooked into an application to track certain aspects of the application's lifecycle. It can help provide insight to an application's performance or any issues that may arise within an application.

pop-debug is a component of the Pop PHP Framework.

Install

Install pop-debug using Composer.

composer require popphp/pop-debug

Or, require it in your composer.json file

"require": {
    "popphp/pop-debug" : "^2.2.1"
}

Top

Quickstart

The basic concept of the debugger is that it works with a handler object or multiple handler objects and one storage object. The handlers are wired to listen to and track various aspects of the application and push their results to the storage object to be retrieved at a later time.

In this simple example, we can set up a generic message handler to store its triggered messages in a file.

The above code will save the following output to the log folder in a plain text file:

Top

Handlers

There are a total of 6 available handlers. More handlers can be added, provided they implement the Pop\Debug\Handler\HandlerInterface interface.

Exception

The exception handler captures and tracks any exceptions thrown by an application.

The above code will save the following output to the log folder in a plain text file:

Top

Memory

The memory handler captures memory usages and peak memory usage. At any point in the application, you can call the updateMemoryUsage() and updatePeakMemoryUsage() methods to take a snapshot of memory usage in the app at that time.

The above code will save the following output to the log folder in a plain text file:

Top

Message

The message handler provides simple and generic messaging to record debug events from within the application:

The above code will save the following output to the log folder in a plain text file:

Top

PHP

The PHP handler provides a way to take a snapshot of common PHP info and INI values:

The above code will save the PHP info snapshot to the debug storage resource. When used in conjunction with the logging feature, it can be useful for monitoring system requirements.

Top

Query

The query handler is a special handler that ties into the pop-db component and the profiler available with that component. It allows you to capture any database queries and any information associated with them.

You can set up the query handler like this:

The above code will save the following output to the log folder in a plain text file:

Top

Request

The request handler works with a Pop\Http\Server\Request object from the pop-http component and tracks all of the inbound request data. The following example would be a block of code that would run in a script that receives an inbound HTTP request:

The above code will save the following output to the log folder in a plain text file:

Top

Time

The time handler provides a simple way to track how long a application request takes, which is useful for performance metrics.

The above code will save the following output to the log folder in a plain text file:

Top

Storage

There are a few different storage options are available to store the output of the debugger.

File

Store the debugger output into a file in a folder location:

Top

Database

Store the debugger output into a table in a database. The default table name is pop_debug but that can be changed with the database storage object.

Top

Formats

Three different formats are available for the storing of the debugger output:

• Text (Default)
• JSON
• Serialized PHP

You can set it via the constructor:

Also, the format can be set via the setFormat() method:

Top

Retrieving

You can retrieve the stored debug content from the debugger's storage adapter. Calling the save() method returns the request ID generated from that method call.

The auto-generated request ID will look like:

From there, you can call getById to retrieve stored debug content:

The method getByType is also available to get groups of debug content by type:

Top

Logging

The debug component can also work with the pop-log component to deliver syslog-compatible logging messages to a logging resource using the standard BSD syslog protocol RFC-3164. Logging can be used in additional to the storage adapters, or by itself, sending the debug data and information to the logging resource only and without storing anything to a storage adapter.

To work with a logger, a logger object must be passed to the debugger, along with logging parameters, which is an array of options. The minimum parameter required is a level value. The context option can also be used to log the body of the debug messaging results:

Other logging parameters options include:

Memory

The usage_limit and peak_limit are memory-specific limits to monitor is an operation goes above the specified limits.

Query, Request & Time

The limit parameter is supported for the query, request and time handlers. It is a time limit. If any of those operations take longer than the time limit, a log message is sent.

Query Example:

Top