anchor.diff:  
   See the link:#mongodb-connector-properties[complete list of connector properties] that can be specified in these configurations.
   
  -This configuration can be sent via POST to a running Kafka Connect service, which will then record the configuration and start up the one connector task that will connect to the MongoDB replica set or sharded cluster, assign tasks for each replica set, perform an initial sync if necessary, read the oplog, and record events to Kafka topics.
  -
  +This configuration can be sent via POST to a running Kafka Connect service, which will then record the configuration and start up the one connector task that will connect to the MongoDB replica set or sharded cluster, assign tasks for each replica set, perform a snapshot if necessary, read the oplog, and record events to Kafka topics.
  +
  +[[mongodb-connector-monitoring]]
  +=== Monitoring
  +
  +Kafka, Zookeeper, and Kafka Connect all have built-in support for JMX metrics.
  +The MongoDB connector also publishes a number of metrics about the connector's activities that can be monitored through JMX.
  +The connector has two types of metrics.
  +Snapshot metrics help you monitor the snapshot activity and are available when the connector is performing a snapshot.
  +Streaming metrics help you monitor the progress and activity while the connector reads CDC collection changes.
  +
  +[[monitoring-snapshots]]
  +[[snapshot-metrics]]
  +==== Snapshot Metrics
  +
  +===== *MBean: debezium.mongodb:type=connector-metrics,context=snapshot,server=_<mongodb.name>_*
  +
  +[cols="30%a,10%a,60%a",options="header"]
  +|=======================
  +|Attribute Name
  +|Type
  +|Description
  +
  +|`LastEvent`
  +|`string`
  +|The last snapshot event that the connector has read.
  +
  +|`MilliSecondsSinceLastEvent`
  +|`long`
  +|The number of milliseconds since the connector has read and processed the most recent event.
  +
  +|`TotalNumberOfEventsSeen`
  +|`long`
  +|The total number of events that this connector has seen since last started or reset.
  +
  +|`NumberOfEventsFiltered`
  +|`long`
  +|The number of events that have been filtered by whitelist or blacklist filtering rules configured on the connector.
  +
  +|`MonitoredTables`
  +|`string[]`
  +|The list of collections that are monitored by the connector.
  +
  +|`QueueTotalCapcity`
  +|`int`
  +|The length of the queue used to pass events between the snapshotter and the main Kafka Connect loop.
  +
  +|`QueueRemainingCapcity`
  +|`int`
  +|The free capacity of the queue used to pass events between the snapshotter and the main Kafka Connect loop.
  +
  +|`TotalTableCount`
  +|`int`
  +|The total number of collections that are being included in the snapshot.
  +
  +|`RemainingTableCount`
  +|`int`
  +|The number of collections that the snapshot has yet to copy.
  +
  +|`SnapshotRunning`
  +|`boolean`
  +|Whether the snapshot was started.
  +
  +|`SnapshotAborted`
  +|`boolean`
  +|Whether the snapshot was aborted.
  +
  +|`SnapshotCompleted`
  +|`boolean`
  +|Whether the snapshot completed.
  +
  +|`SnapshotDurationInSeconds`
  +|`long`
  +|The total number of seconds that the snapshot has taken so far, even if not complete.
  +
  +|`RowsScanned`
  +|`Map<String, Long>`
  +|Map containing the number of documents exported for each collection in the snapshot. Collections are incrementally added to the Map during processing. Updates every 10,000 documents scanned and upon completing a collection.
  +
  +|=======================
  +
  +
  +[[monitoring-streaming]]
  +[[streaming-metrics]]
  +==== Streaming Metrics
  +
  +===== *MBean: debezium.sql_server:type=connector-metrics,context=streaming,server=_<mongodb.name>_*
  +
  +[cols="30%a,10%a,60%a",options="header"]
  +|=======================
  +|Attribute Name
  +|Type
  +|Description
  +
  +|`LastEvent`
  +|`string`
  +|The last streaming event that the connector has read.
  +
  +|`MilliSecondsSinceLastEvent`
  +|`long`
  +|The number of milliseconds since the connector has read and processed the most recent event.
  +
  +|`TotalNumberOfEventsSeen`
  +|`long`
  +|The total number of events that this connector has seen since last started or reset.
  +
  +|`NumberOfEventsFiltered`
  +|`long`
  +|The number of events that have been filtered by whitelist or blacklist filtering rules configured on the connector.
  +
  +|`MonitoredTables`
  +|`string[]`
  +|The list of collections that are monitored by the connector.
  +
  +|`QueueTotalCapcity`
  +|`int`
  +|The length of the queue used to pass events between the streamer and the main Kafka Connect loop.
  +
  +|`QueueRemainingCapcity`
  +|`int`
  +|The free capacity of the queue used to pass events between the streamer and the main Kafka Connect loop.
  +
  +|`Connected`
  +|`boolean`
  +|Flag that denotes whether the connector is currently connected to mongodb.
  +
  +|`MilliSecondsBehindSource`
  +|`long`
  +|The number of milliseconds between the last change event's timestamp and the connector processing it. The values will incorporate any differences between the clocks on the machines where the database server and the connector are running.
  +
  +|`NumberOfCommittedTransactions`
  +|`long`
  +|The number of processed transactions that were committed.
  +
  +|`SourceEventPosition`
  +|`map<string, string>`
  +|The coordinates of the last received event.
  +
  +|`LastTransactionId`
  +|`string`
  +|Transaction identifier of the last processed transaction.
  +
  +|=======================
   
   [[mongodb-connector-properties]]
   === Connector properties
  
positive.code: 
  A MongoDB _replica set_ consists of a set of servers that all have copies of the same data, and replication ensures that all changes made by clients to documents on the replica set's _primary_ are correctly applied to the other replica set's servers, called _secondaries_.
  MongoDB replication works by having the primary record the changes in its _oplog_ (or operation log), and then each of the secondaries reads the primary's oplog and applies in order all of the operations to their own documents.
  When a new server is added to a replica set, that server first performs an https://docs.mongodb.com/manual/core/replica-set-sync/[initial sync] of all of the databases and collections on the primary, and then reads the primary's oplog to apply all changes that might have been made since it began the initial sync.
  This new server becomes a secondary (and able to handle queries) when it catches up to the tail of the primary's oplog.
  
  The MongoDB connector uses this same replication mechanism, though it does not actually become a member of the replica set.
  
negative.code: === Connector is stopped for a duration
  
  If the connector is gracefully stopped, the replica sets can continue to be used and any new changes are recorded in MongoDB's oplog.
  When the connector is restarted, it will resume reading the oplog for each replica set where it last left off, recording change events for all of the changes that were made while the connector was stopped. If the connector is stopped long enough such that MongoDB purges from its oplog some operations that the connector has not read, then upon startup the connector will perform a snapshot.
  
  A properly configured Kafka cluster is capable of https://engineering.linkedin.com/kafka/benchmarking-apache-kafka-2-million-writes-second-three-cheap-machines[massive throughput].
  Kafka Connect is written with Kafka best practices, and given enough resources will also be able to handle very large numbers of database change events. Because of this, when a connector has been restarted after a while, it is very likely to catch up with the database, though how quickly will depend upon the capabilities and performance of Kafka and the volume of changes being made to the data in MongoDB.
  