anchor.diff:  <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)
   
  +Configuring logging is a tradeoff: provide too little and it's not clear what is going on; provide too much and it's too difficult to understand what's going on. Our goal is that `INFO` provides enough to see that the connector is healthy (though logging is not a substitute for link:/docs/monitoring[monitoring]), and that `DEBUG` is provides more detailed information to help you figure out what is going on. But sometimes `DEBUG` is not enough, and that's where `TRACE` comes in. The `TRACE` level is literally every log message produced by or under that named logger, and it can be voluminous.
  +
  +You can also configure logging for a specific subset of the classes within the connector, simply by adding more lines like those above except for more specific logger names. For example, maybe you're not sure why the MySQL connector is skipping some events when it is processing the binlog. Rather than turn on `DEBUG` or `TRACE` logging for whole connector, you can set the connector's logging to `INFO` and then configure `DEBUG` or `TRACE` on just the class that's reading the binlog. For example:
  +
  +[listing,indent=0,options="nowrap"]
  +----
  +...
  +log4j.logger.io.debezium.connector.mysql=INFO, stdout <1>
  +log4j.logger.io.debezium.connector.mysql.BinlogReader=DEBUG, stdout <1>
  +log4j.logger.io.debezium.relational.history=INFO, stdout <2>
  +
  +log4j.additivity.io.debezium.connector.mysql=false <3>
  +log4j.additivity.io.debezium.relational.history=false <3>
  +log4j.additivity.io.debezium.connector.mysql.BinlogReader=false <3>
  +...
  +----
  +
  +This requires a bit more knowledge about the code, but here's a useful tip. First turn on `DEBUG` or `TRACE` logging for the whole connector (or even the `io.debezium` package), find the messages that are most useful, and look at the end of the log message to see the name of the Java class that produced the message. Then, turn the connector's logging back to `INFO` and _add_ a logger configuration for each of those "interesting" classes or packages. If there are a few classes you don't want to see as detailed log messages, add another logger configuration for those classes and set them to `INFO`.
  +
  +We've only just touched on the power of Log4J, so if you want even more control look for some tutorials about how to set up and use other appenders to send different log messages to specific destinations.
   
   == 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:
  +Most Debezium connectors use multiple threads to perform different activities, and the Kafka Connect workers also use multiple threads. This can make it challenging to look at a log file and find only those log messages for one of these logical activities. 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.
  +* `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, so you can use this to find all log messages produced by a given type of connector.
  +* `dbz.connectorName` - The name of the connector or database server as defined in the connector's configuration. For example `products`, `serverA`, etc. All threads associated with a specific _connector instance_ use the same value, so you can find all the log messages produced by a specific connector instance.
  +* `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 connector assigns threads to specific resources (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, so you can find all the log messages associated with this particular activity.
   
   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:
   
  
positive.code: :icons: font
  :source-highlighter: highlight.js
  
  Debezium has extensive logging built into its connectors, and you can easily change the logging configuration to control which of these log statements appear in the logs and where those logs are sent. Debezium (and Kafka, Kafka Conect, and Zookeeper) use the ubiquitous https://logging.apache.org/log4j/1.2/[Log4J] logging framework for Java. You configure Log4J for the whole Java application.
  
  == Logging concepts
  
  
negative.code: 1. `DEBUG` - more detailed activity that would be useful in diagnosing unexpected behavior
  1. `TRACE` - very verbose and detailed activity (usally very high volume)
  
  Log4J also allows you to define one or more _appenders_, which are essentially destinations where log messages will be written. Each appender controls the format of its log messages, giving you even more control over what the log messages look like.
  
  To configure logging, you specify the desired level for each logger and the appender(s) where those log messages should be written. Since loggers are hierarchical, the configuration for the root logger serves as a default for all of the loggers below it, although you can override any child (or decendant) logger.
  
  == Example logging configuration
  
  