[3806] Further improved traces in the Dhcpv4Srv class.

src/bin/dhcp4/dhcp4_messages.mes

@@ -30,26 +30,31 @@ over the socket. When the message is logged the contents of the received
 packet hasn't been parsed yet. The only available information is the
 interface and the source and destination addresses/ports.
 
-% DHCP4_BUFFER_UNPACK parsing received buffer from %1 to %2 over interface %3
+% DHCP4_BUFFER_UNPACK parsing buffer received from %1 to %2 over interface %3
 This debug message is issued when the server starts parsing the received
-buffer holding the DHCPv4 message.
+buffer holding the DHCPv4 message. The arguments specify the source and
+destination addresses as well as the interface over which the buffer has
+been received.
 
 % DHCP4_BUFFER_WAIT waiting for next DHCPv4 packet with timeout %1 ms
 This debug message is issued when the server enters the state when it
 waits for new packets. The argument specifies the timeout for the server
 to wait for the packet. When this time elapses the server will pass
 through its main loop to perform handling of any pending signals
-and timers. After that it will enter the wait state again.
+and timers. After that, it will enter the wait state again.
 
 % DHCP4_BUFFER_WAIT_SIGNAL signal received while waiting for next packet, next waiting signal is %1
-This debug message is issued when the server's waiting for the packet
-is interrupted by the signal received by the process. The signal
-will be handled before the server starts waiting for next packets.
+This debug message is issued when the server was waiting for the
+packet, but the wait has been interrupted by the signal received
+by the process. The signal will be handled before the server starts
+waiting for next packets. The argument specifies the next signal to
+be handled by the server.
 
 % DHCP4_BUFFER_WAIT_TIMEOUT timeout %1 ms reached while waiting for the next packet
-This debug message is issued when the timeout has occured while
+This debug message is issued when the timeout has occurred while
 waiting for the next packet. The server will now handle signals
 received and ready timers before waiting for next packets again.
+The argument specifies the timeout value in milliseconds.
 
 % DHCP4_CCSESSION_STARTED control channel session started on socket %1
 A debug message issued during startup after the DHCPv4 server has
@@ -59,19 +64,24 @@ successfully established a session with the Kea control channel.
 This debug message is issued just before the DHCPv4 server attempts
 to establish a session with the Kea control channel.
 
-% DHCP4_CLASS_ASSIGNED client packet has been assigned to the following class(es): %1
+% DHCP4_CLASS_ASSIGNED %1: client packet has been assigned to the following class(es): %2
 This debug message informs that incoming packet has been assigned to specified
 class or classes. This is a normal behavior and indicates successful operation.
+The first argument specifies the client and transaction identification
+information. The second argument includes all classes to which the
+packet has been assigned.
 
 % DHCP4_CLIENT_FQDN_PROCESS %1: processing Client FQDN option
 This debug message is issued when the server starts to process the Client
 FQDN option sent in the client's query. The argument includes the
 client and transaction identification information.
 
-% DHCP4_CLIENT_FQDN_DATA %1: client FQDN option information: %2
+% DHCP4_CLIENT_FQDN_DATA %1: Client FQDN option information: %2
 This debug message includes the detailed information extracted from the
 Client FQDN option sent in the query. The first argument includes the
-client and transaction identification information.
+client and transaction identification information. The second argument
+specifies the detailed information about the FQDN option received
+by the server.
 
 % DHCP4_CLIENT_HOSTNAME_PROCESS %1: processing client's Hostname option
 This debug message is issued when the server starts to process the Hostname
@@ -81,12 +91,16 @@ transaction identification information.
 % DHCP4_CLIENT_HOSTNAME_DATA %1: client Hostname option information: %2
 This debug message includes the detailed information extracted from the
 Hostname option sent in the query. The first argument includes the
-client and transaction identification information.
+client and transaction identification information. The second argument
+specifies the hostname carried in the Hostname option sent by the
+client.
 
-% DHCP4_CLIENT_NAME_PROC_FAIL failed to process the fqdn or hostname sent by a client: %1
+% DHCP4_CLIENT_NAME_PROC_FAIL %1: failed to process the fqdn or hostname sent by a client: %2
 This debug message is issued when the DHCP server was unable to process the
 FQDN or Hostname option sent by a client. This is likely because the client's
-name was malformed or due to internal server error.
+name was malformed or due to internal server error. The first argument
+contains the client and transaction identification information. The
+second argument holds the detailed description of the error.
 
 % DHCP4_COMMAND_RECEIVED received command %1, arguments: %2
 A debug message listing the command (and possible arguments) received
@@ -141,9 +155,10 @@ This error message is logged when the attempt to compute DHCID for a specified
 lease has failed. The lease details and reason for failure is logged in the
 message.
 
-% DHCP4_DISCOVER_CLASS_PROCESSING_FAILED client class specific processing failed for DHCPDISCOVER
+% DHCP4_DISCOVER_CLASS_PROCESSING_FAILED %1: client class specific processing failed for DHCPDISCOVER
 This debug message means that the server processing that is unique for each
 client class has reported a failure. The response packet will not be sent.
+The argument holds the client and transaction identification information.
 
 % DHCP4_DYNAMIC_RECONFIGURATION initiate server reconfiguration using file: %1, after receiving SIGHUP signal
 This is the info message logged when the DHCPv4 server starts reconfiguration
@@ -153,10 +168,11 @@ as a result of receiving SIGHUP signal.
 This is an error message logged when the dynamic reconfiguration of the
 DHCP server failed.
 
-% DHCP4_EMPTY_HOSTNAME received empty hostname from the client, skipping processing of this option
+% DHCP4_EMPTY_HOSTNAME %1: received empty hostname from the client, skipping processing of this option
 This debug message is issued when the server received an empty Hostname option
 from a client. Server does not process empty Hostname options and therefore
-option is skipped.
+option is skipped. The argument holds the client and transaction identification
+information.
 
 % DHCP4_HOOKS_LIBS_RELOAD_FAIL reload of hooks libraries failed
 A "libreload" command was issued to reload the hooks libraries but for
@@ -167,6 +183,8 @@ hooks framework will indicate the nature of the problem.
 This debug message is printed when a callout installed on buffer4_receive
 hook point set the skip flag. For this particular hook point, the
 setting of the flag by a callout instructs the server to drop the packet.
+The arguments specify the source and destination address as well as
+the name of the interface over which the buffer has been received.
 
 % DHCP4_HOOK_BUFFER_SEND_SKIP %1: prepared response is dropped because a callout set the skip flag.
 This debug message is printed when a callout installed on buffer4_send
@@ -193,16 +211,20 @@ of the flag instructs the server to drop the packet. This means that
 the client will not get any response, even though the server processed
 client's request and acted on it (e.g. possibly allocated a lease).
 
-% DHCP4_HOOK_SUBNET4_SELECT_SKIP no subnet was selected, because a callout set skip flag.
+% DHCP4_HOOK_SUBNET4_SELECT_SKIP %1: no subnet was selected, because a callout set skip flag.
 This debug message is printed when a callout installed on the
 subnet4_select hook point sets the skip flag. For this particular hook
 point, the setting of the flag instructs the server not to choose a
 subnet, an action that severely limits further processing; the server
 will be only able to offer global options - no addresses will be assigned.
+The argument specifies the client and transaction identification
+information.
 
-% DHCP4_INFORM_CLASS_PROCESSING_FAILED client class specific processing failed for DHCPINFORM
+% DHCP4_INFORM_CLASS_PROCESSING_FAILED %1: client class specific processing failed for DHCPINFORM
 This debug message means that the server processing that is unique for each
 client class has reported a failure. The response packet will not be sent.
+The argument specifies the client and the transaction identification
+information.
 
 % DHCP4_INFORM_DIRECT_REPLY %1: DHCPACK in reply to the DHCPINFORM will be sent directly to %2
 This debug message is issued when the DHCPACK will be sent directly to the
@@ -224,12 +246,16 @@ argument specifies the requested IP address.
 % DHCP4_LEASE_ADVERT %1: lease %2 will be advertised
 This debug message indicates that the server has found the lease to be
 offered to the client. It is up to the client to choose one server out of
-those which offered leases and continue allocation with that server. This
+those which offered leases and continue allocation with that server.
+The first argument specifies the client and the transaction identification
+information. The second argument specifies the address to be offered.
 
 % DHCP4_LEASE_ALLOC %1: lease %2 has been allocated
 This debug message indicates that the server successfully granted a lease
 in response to client's DHCPREQUEST message. The lease information will
-be sent to the client in the DHCPACK message.
+be sent to the client in the DHCPACK message. The first argument
+contains the client and the transaction identification information. The
+second argument contains the allocated address.
 
 % DHCP4_LEASE_DATABASE_TIMERS_EXEC_FAIL failed to execute timer-based functions for lease database: %1
 A warning message executed when a server process is unable to execute
@@ -238,11 +264,13 @@ action is a Lease File Cleanup. One of the reasons for the failure is
 a misconfiguration of the lease database, whereby the lease database
 hasn't been selected.
 
-% DHCP4_NAME_GEN_UPDATE_FAIL failed to update the lease after generating name for a client: %1
+% DHCP4_NAME_GEN_UPDATE_FAIL %1: failed to update the lease after generating name %2 for a client: %3
 This message indicates the failure when trying to update the lease and/or
 options in the server's response with the hostname generated by the server
 from the acquired address. The message argument indicates the reason for the
-failure.
+failure. The first argument includes the client and the transaction
+identification information. The second argument specifies the hostname.
+The third argument contains the error details.
 
 % DHCP4_NCR_CREATE %1: DDNS updates enabled, therefore sending name change requests
 This debug message message is issued when the server is starting to send
@@ -266,6 +294,9 @@ DHCPv4 server but it is not running.
 % DHCP4_NO_LEASE_INIT_REBOOT %1: no lease for address %2 requested by INIT-REBOOT client
 This debug message is issued when the client being in the INIT-REBOOT state
 requested an address but this client is unknown. The server will not respond.
+The first argument includes the client and the transaction id identification
+information. The second argument includes the IP address requested by the
+client.
 
 % DHCP4_NO_SOCKETS_OPEN no interface configured to listen to DHCP traffic
 This warning message is issued when current server configuration specifies
@@ -300,50 +331,69 @@ the message has been received.
 
 % DHCP4_PACKET_DROP_0004 %1, from interface %2: missing msg-type option
 This is a debug message informing that incoming DHCPv4 packet did not
-have mandatory DHCP message type option and thus was dropped.
+have mandatory DHCP message type option and thus was dropped. The
+arguments specify the client and transaction identification information,
+as well as the interface on which the message has been received.
 
 % DHCP4_PACKET_DROP_0005 %1: unrecognized type %2 in option 53
 This debug message indicates that the message type carried in DHCPv4 option
 53 is unrecognized by the server. The valid message types are listed
 on the IANA website: http://www.iana.org/assignments/bootp-dhcp-parameters/bootp-dhcp-parameters.xhtml#message-type-53.
-The message will not be processed by the server.
+The message will not be processed by the server. The arguments specify
+the client and transaction identification information, as well as the
+received message type.
 
 % DHCP4_PACKET_DROP_0006 %1: unsupported DHCPv4 message type %2
 This debug message indicates that the message type carried in DHCPv4 option
 53 is valid but the message will not be processed by the server. This includes
-messages being normally sent by the server to the client, such as Offer, ACK,
-NAK etc.
+messages being normally sent by the server to the client, such as DHCPOFFER,
+DHCPACK, DHCPNAK etc. The first argument specifies the client and transaction
+identification information. The second argument specifies the message type.
 
-% DHCP4_PACKET_DROP_0007 %1: failed to process packet - %2
+% DHCP4_PACKET_DROP_0007 %1: failed to process packet: %2
 This is a general catch-all message indicating that the processing of a
 received packet failed.  The reason is given in the message.  The server
-will not send a response but will instead ignore the packet.
+will not send a response but will instead ignore the packet. The first
+argument contains the client and transaction identification information.
+The second argument includes the details of the error.
 
 % DHCP4_PACKET_NAK_0001 %1: failed to select a subnet for incoming packet, src %2, type %3
 This error message is output when a packet was received from a subnet
 for which the DHCPv4 server has not been configured. The most probable
-cause is a misconfiguration of the server.
+cause is a misconfiguration of the server. The first argument contains
+the client and transaction identification information. The second argument
+contains the source address of the packet. The third argument contains
+the name of the received packet.
 
 % DHCP4_PACKET_NAK_0002 %1: invalid address %2 requested by INIT-REBOOT
 This debug message is issued when the client being in the INIT-REBOOT state
 requested an address which is not assigned to him. The server will respond
-to this client with DHCPNAK.
+to this client with DHCPNAK. The first argument contains the client and
+the transaction identification information. The second arguments holds the
+address requested by the client.
 
 % DHCP4_PACKET_NAK_0003 %1: failed to advertise a lease, client sent ciaddr %2, requested-ip-address %3
 This message indicates that the server has failed to offer a lease to
 the specified client after receiving a DISCOVER message from it. There are
-many possible reasons for such a failure.
+many possible reasons for such a failure. The first argument contains
+the client and the transaction identification information. The second
+argument contains the address in the ciaddr field. The third
+argument contains the IP address in the requested-ip-address option
+(if present).
 
 % DHCP4_PACKET_NAK_0004 %1: failed to grant a lease, client sent ciaddr %2, requested-ip-address %3
 This message indicates that the server failed to grant a lease to the
 specified client after receiving a REQUEST message from it.  There are many
 possible reasons for such a failure. Additional messages will indicate the
-reason.
+reason. The first argument contains the client and the transaction
+identification information. The second argument contains the address in
+the ciaddr field. The third argument contains the IP address in the
+requested-ip-address option (if present).
 
 % DHCP4_PACKET_PACK %1: preparing on-wire format of the packet to be sent
 This debug message is issued when the server starts preparing the on-wire
 format of the packet to be sent back to the client. The argument specifies
-the identifiers of the client: HW address and client identifier.
+the client and the transaction identification information.
 
 % DHCP4_PACKET_PACK_FAIL %1: preparing on-wire-format of the packet to be sent failed %2
 This error message is issued when preparing an on-wire format of the packet
@@ -364,8 +414,9 @@ address and port, destination address and port and the interface name.
 
 % DHCP4_PACKET_SEND_FAIL %1: failed to send DHCPv4 packet: %2
 This error is output if the DHCPv4 server fails to send an assembled
-DHCP message to a client. The reason for the error is included in the
-message.
+DHCP message to a client. The first argument includes the client and
+the transaction identification information. The second argument includes
+the reason for failure.
 
 % DHCP4_PARSER_COMMIT_EXCEPTION parser failed to commit changes
 On receipt of message containing details to a change of the DHCPv4
@@ -399,8 +450,10 @@ of the named configuration element, or the creation succeeded but the
 parsing actions and committal of changes failed.  The reason for the
 failure is given in the message.
 
-% DHCP4_QUERY_DATA %1, packet details: [%2]
-A debug message listing the details of the received from the client.
+% DHCP4_QUERY_DATA %1, packet details: %2
+A debug message printing the details of the received packet. The first
+argument includes the client and the transaction identification
+information.
 
 % DHCP4_QUEUE_NCR name change request to %1 DNS entry queued: %2
 A debug message which is logged when the NameChangeRequest to add or remove
@@ -410,14 +463,19 @@ The second parameter carries the details of the NameChangeRequest.
 
 % DHCP4_RELEASE %1: address %2 was released properly.
 This debug message indicates that an address was released properly. It
-is a normal operation during client shutdown.
+is a normal operation during client shutdown. The first argument includes
+the client and transaction identification information. The second argument
+includes the released IP address.
 
 % DHCP4_RELEASE_EXCEPTION %1: while trying to release address %2 an exception occured: %3
 This message is output when an error was encountered during an attempt
-to process a RELEASE message. The error will not affect the client,
-which does not expect any response from the server for RELEASE
+to process a DHCPRELEASE message. The error will not affect the client,
+which does not expect any response from the server for DHCPRELEASE
 messages. Depending on the nature of problem, it may affect future
-server operation.
+server operation. The first argument includes the client and the
+transaction identification information. The second argument
+includes the IP address which release was attempted. The last
+argument includes the detailed error description.
 
 % DHCP4_RELEASE_FAIL %1: failed to remove lease for address %2
 This error message indicates that the software failed to remove a
@@ -425,7 +483,10 @@ lease from the lease database. It is probably due to an error during a
 database operation: resolution will most likely require administrator
 intervention (e.g. check if DHCP process has sufficient privileges to
 update the database). It may also be triggered if a lease was manually
-removed from the database during RELEASE message processing.
+removed from the database during RELEASE message processing. The
+first argument includes the client and the transaction identification
+information. The second argument holds the IP address which release
+was attempted.
 
 % DHCP4_RELEASE_FAIL_NO_LEASE %1: client is trying to release non-existing lease %2
 This debug message is printed when client attempts to release a lease,
@@ -445,7 +506,10 @@ This warning message indicates that client tried to release an address
 that does belong to it, but the lease information was associated with
 a different hardware address. One possible reason for using different
 hardware address is that a cloned virtual machine was not updated and
-both clones use the same client-id.
+both clones use the same client-id. The first argument includes the
+client and the transaction identification information. The second
+argument includes the address which release was attempted. The
+third argumnet includes the HW address of the lease owner.
 
 % DHCP4_RESPONSE_FQDN_DATA %1: including FQDN option in the server's response: %2
 This debug message is issued when the server is adding the Client FQDN
@@ -479,7 +543,10 @@ information.
 
 % DHCP4_RESPONSE_DATA %1: responding with packet %2 (type %3), packet details: "%4"
 A debug message including the detailed data about the packet being sent
-to the client.
+to the client. The first argument contains the client and the transaction
+identification information. The second and third argument contains the
+packet name and type respectively. The fourth argument contains detailed
+packet information.
 
 % DHCP4_SERVER_FAILED server failed: %1
 The DHCPv4 server has encountered a fatal error and is terminating.
@@ -514,7 +581,24 @@ This is a debug message issued during the DHCPv4 server startup.
 It lists some information about the parameters with which the server
 is running.
 
-% DHCP4_SUBNET_SELECTED the %1 subnet was selected for client assignment
+% DHCP4_SUBNET_DATA %1: the selected subnet details: %2
+This debug message includes the details of the subnet selected fot
+the client. The first argument includes the client and the
+transaction identification information. The second arguments
+includes the subnet details.
+
+% DHCP4_SUBNET_SELECTED %1: the subnet with ID %2 was selected for client assignments
 This is a debug message noting the selection of a subnet to be used for
-address and option assignment.  Subnet selection is one of the early
-steps in the processing of incoming client message.
+address and option assignment. Subnet selection is one of the early
+steps in the processing of incoming client message. The first
+argument includes the client and the transaction identification
+information. The second argument holds the selected subnet id.
+
+% DHCP4_SUBNET_SELECTION_FAILED %1: failed to select subnet for the client
+This debug message indicates that the server failed to select the
+subnet for the client which has sent a message to the server.
+The server will not be able to offer any lease to the client and
+will drop its message if the received message was DHCPDISCOVER,
+and will send DHCPNAK if the received message was DHCPREQUEST.
+The argument includes the client and the transaction identification
+information.

src/bin/dhcp4/dhcp4_srv.cc

@@ -279,8 +279,9 @@ Dhcpv4Srv::selectSubnet(const Pkt4Ptr& query) const {
         // will be selected. Packet processing will continue, but it will
         // be severely limited (i.e. only global options will be assigned)
         if (callout_handle->getSkip()) {
-            LOG_DEBUG(dhcp4_logger, DBG_DHCP4_HOOKS,
-                      DHCP4_HOOK_SUBNET4_SELECT_SKIP);
+            LOG_DEBUG(srv_hooks_logger, DBG_DHCP4_HOOKS,
+                      DHCP4_HOOK_SUBNET4_SELECT_SKIP)
+                .arg(query->getLabel());
             return (Subnet4Ptr());
         }
 
@@ -288,6 +289,23 @@ Dhcpv4Srv::selectSubnet(const Pkt4Ptr& query) const {
         callout_handle->getArgument("subnet4", subnet);
     }
 
+    if (subnet) {
+        // Log at higher debug level that subnet has been found.
+        LOG_DEBUG(packet_logger, DBG_DHCP4_DETAIL, DHCP4_SUBNET_SELECTED)
+            .arg(query->getLabel())
+            .arg(subnet->getID());
+        // Log detailed information about the selected subnet at the
+        // lower debug level.
+        LOG_DEBUG(packet_logger, DBG_DHCP4_DETAIL_DATA, DHCP4_SUBNET_DATA)
+            .arg(query->getLabel())
+            .arg(subnet->toText());
+
+    } else {
+        LOG_DEBUG(packet_logger, DBG_DHCP4_DETAIL,
+                  DHCP4_SUBNET_SELECTION_FAILED)
+            .arg(query->getLabel());
+    }
+
     return (subnet);
 }
 
@@ -539,17 +557,10 @@ Dhcpv4Srv::run() {
             // (The problem is logged as a debug message because debug is
             // disabled by default - it prevents a DDOS attack based on the
             // sending of problem packets.)
-            if (dhcp4_logger.isDebugEnabled(DBG_DHCP4_BASIC)) {
-                std::string source = "unknown";
-                HWAddrPtr hwptr = query->getHWAddr();
-                if (hwptr) {
-                    source = hwptr->toText();
-                }
-                LOG_DEBUG(bad_packet_logger, DBG_DHCP4_BASIC,
-                          DHCP4_PACKET_DROP_0007)
-                    .arg(query->getLabel())
-                    .arg(e.what());
-            }
+            LOG_DEBUG(bad_packet_logger, DBG_DHCP4_BASIC,
+                      DHCP4_PACKET_DROP_0007)
+                .arg(query->getLabel())
+                .arg(e.what());
         }
 
         if (!rsp) {
@@ -892,7 +903,7 @@ Dhcpv4Srv::processClientName(Dhcpv4Exchange& ex) {
                 processHostnameOption(ex);
             }
         }
-    } catch (const Exception& ex) {
+    } catch (const Exception& e) {
         // In some rare cases it is possible that the client's name processing
         // fails. For example, the Hostname option may be malformed, or there
         // may be an error in the server's logic which would cause multiple
@@ -901,8 +912,9 @@ Dhcpv4Srv::processClientName(Dhcpv4Exchange& ex) {
         // from the log. We don't want to throw an exception here because,
         // it will impact the processing of the whole packet. We rather want
         // the processing to continue, even if the client's name is wrong.
-        LOG_DEBUG(dhcp4_logger, DBG_DHCP4_DETAIL_DATA, DHCP4_CLIENT_NAME_PROC_FAIL)
-            .arg(ex.what());
+        LOG_DEBUG(hostname_logger, DBG_DHCP4_DETAIL_DATA, DHCP4_CLIENT_NAME_PROC_FAIL)
+            .arg(ex.getQuery()->getLabel())
+            .arg(e.what());
     }
 }
 
@@ -983,7 +995,8 @@ Dhcpv4Srv::processHostnameOption(Dhcpv4Exchange& ex) {
     /// @todo It would be more liberal to accept this and let it fall into
     /// the case  of replace or less than two below.
     if (label_count == 0) {
-        LOG_DEBUG(dhcp4_logger, DBG_DHCP4_DETAIL_DATA, DHCP4_EMPTY_HOSTNAME);
+        LOG_DEBUG(hostname_logger, DBG_DHCP4_DETAIL_DATA, DHCP4_EMPTY_HOSTNAME)
+            .arg(ex.getQuery()->getLabel());
         return;
     }
     // Copy construct the hostname provided by the client. It is entirely
@@ -1095,7 +1108,7 @@ queueNameChangeRequest(const isc::dhcp_ddns::NameChangeType chg_type,
     try {
         dhcid  = computeDhcid(lease);
     } catch (const DhcidComputeError& ex) {
-        LOG_ERROR(dhcp4_logger, DHCP4_DHCID_COMPUTE_ERROR)
+        LOG_ERROR(hostname_logger, DHCP4_DHCID_COMPUTE_ERROR)
             .arg(lease->toText())
             .arg(ex.what());
         return;
@@ -1111,7 +1124,7 @@ queueNameChangeRequest(const isc::dhcp_ddns::NameChangeType chg_type,
                                                     lease->valid_lft_),
                                                    lease->valid_lft_));
 
-    LOG_DEBUG(dhcp4_logger, DBG_DHCP4_DETAIL_DATA, DHCP4_QUEUE_NCR)
+    LOG_DEBUG(hostname_logger, DBG_DHCP4_DETAIL_DATA, DHCP4_QUEUE_NCR)
         .arg(chg_type == CHG_ADD ? "add" : "remove")
         .arg(ncr->toText());
 
@@ -1152,9 +1165,6 @@ Dhcpv4Srv::assignLease(Dhcpv4Exchange& ex) {
     /// @todo: move subnet selection to a common code
     resp->setSiaddr(subnet->getSiaddr());
 
-    LOG_DEBUG(dhcp4_logger, DBG_DHCP4_DETAIL_DATA, DHCP4_SUBNET_SELECTED)
-        .arg(subnet->toText());
-
     // Get client-id. It is not mandatory in DHCPv4.
     ClientIdPtr client_id = ex.getContext()->clientid_;
 
@@ -1330,7 +1340,9 @@ Dhcpv4Srv::assignLease(Dhcpv4Exchange& ex) {
                 }
 
             } catch (const Exception& ex) {
-                LOG_ERROR(dhcp4_logger, DHCP4_NAME_GEN_UPDATE_FAIL)
+                LOG_ERROR(hostname_logger, DHCP4_NAME_GEN_UPDATE_FAIL)
+                    .arg(query->getLabel())
+                    .arg(lease->hostname_)
                     .arg(ex.what());
             }
         }
@@ -1590,7 +1602,8 @@ Dhcpv4Srv::processDiscover(Pkt4Ptr& discover) {
     /// doing class specific processing.
     if (!classSpecificProcessing(ex)) {
         /// @todo add more verbosity here
-        LOG_DEBUG(dhcp4_logger, DBG_DHCP4_BASIC, DHCP4_DISCOVER_CLASS_PROCESSING_FAILED);
+        LOG_DEBUG(options_logger, DBG_DHCP4_DETAIL, DHCP4_DISCOVER_CLASS_PROCESSING_FAILED)
+            .arg(discover->getLabel());
     }
 
     return (ex.getResponse());
@@ -1639,7 +1652,8 @@ Dhcpv4Srv::processRequest(Pkt4Ptr& request) {
     /// doing class specific processing.
     if (!classSpecificProcessing(ex)) {
         /// @todo add more verbosity here
-        LOG_DEBUG(dhcp4_logger, DBG_DHCP4_BASIC, DHCP4_REQUEST_CLASS_PROCESSING_FAILED);
+        LOG_DEBUG(dhcp4_logger, DBG_DHCP4_BASIC, DHCP4_REQUEST_CLASS_PROCESSING_FAILED)
+            .arg(ex.getQuery()->getLabel());
     }
 
     return (ex.getResponse());
@@ -1790,7 +1804,8 @@ Dhcpv4Srv::processInform(Pkt4Ptr& inform) {
     /// @todo: decide whether we want to add a new hook point for
     /// doing class specific processing.
     if (!classSpecificProcessing(ex)) {
-        LOG_DEBUG(dhcp4_logger, DBG_DHCP4_BASIC, DHCP4_INFORM_CLASS_PROCESSING_FAILED)
+        LOG_DEBUG(options_logger, DBG_DHCP4_DETAIL,
+                  DHCP4_INFORM_CLASS_PROCESSING_FAILED)
             .arg(inform->getLabel());
     }
 
@@ -2122,7 +2137,8 @@ void Dhcpv4Srv::classifyPacket(const Pkt4Ptr& pkt) {
     }
 
     if (!classes.empty()) {
-        LOG_DEBUG(dhcp4_logger, DBG_DHCP4_BASIC, DHCP4_CLASS_ASSIGNED)
+        LOG_DEBUG(options_logger, DBG_DHCP4_BASIC, DHCP4_CLASS_ASSIGNED)
+            .arg(pkt->getLabel())
             .arg(classes);
     }
 }
@@ -2185,7 +2201,7 @@ void
 Dhcpv4Srv::d2ClientErrorHandler(const
                                 dhcp_ddns::NameChangeSender::Result result,
                                 dhcp_ddns::NameChangeRequestPtr& ncr) {
-    LOG_ERROR(dhcp4_logger, DHCP4_DDNS_REQUEST_SEND_FAILED).
+    LOG_ERROR(hostname_logger, DHCP4_DDNS_REQUEST_SEND_FAILED).
               arg(result).arg((ncr ? ncr->toText() : " NULL "));
     // We cannot communicate with kea-dhcp-ddns, suspend further updates.
     /// @todo We may wish to revisit this, but for now we will simply turn