anchor.diff:  ...
   ----
   
  -Notice how each line includes the connector type (e.g., `MySQL`), the name of the connector (e.g., `dbserver1`), and the activity of the thread (e.g., `snapshot`).
  +Notice how each line includes the connector type (e.g., `MySQL`), the name of the connector (e.g., `dbserver1`), and the activity of the thread (e.g., `snapshot`). And here you can see at the end of the line the name of the class that generated the message.
   
   
   == Debezium Docker images
   
  -The Debezium Docker images for Zookeeper, Kafka, and Kafka Connect all set up their `log4j.properties` file to configure the Debezium-related loggers and to ensure all log messages go to the Docker containers console so that it is captured in the Docker logs and in file files under the `/kafka/logs` directory (which you can mount if needed).
  +The Debezium Docker images for Zookeeper, Kafka, and Kafka Connect all set up their `log4j.properties` file to configure the Debezium-related loggers and to ensure all log messages go to the Docker containers console (and thus the Docker logs) and are written to files under the `/kafka/logs` directory, which you can mount to easily get access to those files.
   
  -The containers also use the `LOG_LEVEL` environment variable to set the log level for the root logger. So, all you have to do is set this environment variable to one of the log levels (e.g., `-e LOG_LEVEL=DEBUG`), and all of the code within the container will start using that log level. For example:
  +The containers use a `LOG_LEVEL` environment variable to set the log level for the root logger. So, when starting a container simply set this environment variable to one of the log levels (e.g., `-e LOG_LEVEL=DEBUG`), and all of the code within the container will start using that log level.
   
   If you need more control, create a new image that is based on ours, except in your `Dockerfile` copy your own `log4j.properties` file into the image:
   
  
positive.code: <2> Configures the logger named `io.debezium.relational.history` to send `DEBUG`, `INFO`, `WARN`, and `ERROR` messages to the `stdout` appender
  <3> Turns off _additivity_, meaning the messages will not be sent also to appenders of parent loggers (this can prevent seeing duplicate log messages when using multiple appenders)
  
  
  == Mapped Diagnostic Contexts
  
  Most Debezium connectors use multiple threads to separate different activities, and the Kafka Connect workers also use multiple threads. This can make it challenging to associate the various log messages with the corresponding logical activity. To make this easier, Debezium uses _mapped diagnostic contexts_, or _MDC_ to provide additional information for each thread via several properties that you can embed in your appender patterns:
  
  * `dbz.connectorType` - A short alias for the type of connector. For example, `mysql`, `mongo`, `postgres`, etc. All threads associated with the same type of connector use the same value.
  * `dbz.connectorName` - The name of the connector as defined in the connector's configuration. For example `products`, `serverA`, etc. All threads associated with a specific connector instance use the same value.
  * `dbz.connectorContext` - A short name for an activity running as a separate thread running within the connector's task. For example, `main`, `binlog`, `snapshot`, etc. In some cases when a thread is allocated for a specific resource (e.g., table or collection), the name of that resource could be used instead. Each thread associated with a connector would use a distinct value.
  
  You can use these properties within the appender's pattern defined in the `log4j.properties` file. For example, the following is a modification of the `stdout` appender's layout to use these MDC properties:
  
  
negative.code: 
  For the most part, the Debezium code sends its log messages to loggers with names that match the fully-qualified name of the Java class that is generating the log message. This normally works well, since we use packages to organize code with similar or related functions.
  
  This means that you can easily control all of the log messages for a specific class or for all of the classes within or under a specifi package. For example, to turn on debug logging for the _entire_ MySQL connector (and the database history implementation used by the connector) might be as simple as adding the following line(s) to your `log4j.properties` file:
  
  [listing,indent=0,options="nowrap"]
  ----
  