26

When starting Kafka-Connect, I saw lots of warnings

10:33:56.706 [DistributedHerder] WARN  org.apache.kafka.clients.admin.AdminClientConfig - The configuration 'config.storage.topic' was supplied but isn't a known config.
10:33:56.707 [DistributedHerder] WARN  org.apache.kafka.clients.admin.AdminClientConfig - The configuration 'group.id' was supplied but isn't a known config.
10:33:56.708 [DistributedHerder] WARN  org.apache.kafka.clients.admin.AdminClientConfig - The configuration 'status.storage.topic' was supplied but isn't a known config.
10:33:56.709 [DistributedHerder] WARN  org.apache.kafka.clients.admin.AdminClientConfig - The configuration 'internal.key.converter.schemas.enable' was supplied but isn't a known config.
10:33:56.710 [DistributedHerder] WARN  org.apache.kafka.clients.admin.AdminClientConfig - The configuration 'config.storage.replication.factor' was supplied but isn't a known config.
10:33:56.710 [DistributedHerder] WARN  org.apache.kafka.clients.admin.AdminClientConfig - The configuration 'offset.flush.interval.ms' was supplied but isn't a known config.
10:33:56.711 [DistributedHerder] WARN  org.apache.kafka.clients.admin.AdminClientConfig - The configuration 'key.converter.schemas.enable' was supplied but isn't a known config.
10:33:56.712 [DistributedHerder] WARN  org.apache.kafka.clients.admin.AdminClientConfig - The configuration 'internal.key.converter' was supplied but isn't a known config.
10:33:56.712 [DistributedHerder] WARN  org.apache.kafka.clients.admin.AdminClientConfig - The configuration 'internal.value.converter.schemas.enable' was supplied but isn't a known config.
10:33:56.713 [DistributedHerder] WARN  org.apache.kafka.clients.admin.AdminClientConfig - The configuration 'status.storage.replication.factor' was supplied but isn't a known config.
10:33:56.713 [DistributedHerder] WARN  org.apache.kafka.clients.admin.AdminClientConfig - The configuration 'value.converter.schemas.enable' was supplied but isn't a known config.
10:33:56.714 [DistributedHerder] WARN  org.apache.kafka.clients.admin.AdminClientConfig - The configuration 'internal.value.converter' was supplied but isn't a known config.
10:33:56.714 [DistributedHerder] WARN  org.apache.kafka.clients.admin.AdminClientConfig - The configuration 'offset.storage.replication.factor' was supplied but isn't a known config.
10:33:56.715 [DistributedHerder] WARN  org.apache.kafka.clients.admin.AdminClientConfig - The configuration 'offset.storage.topic' was supplied but isn't a known config.
10:33:56.715 [DistributedHerder] WARN  org.apache.kafka.clients.admin.AdminClientConfig - The configuration 'value.converter' was supplied but isn't a known config.
10:33:56.716 [DistributedHerder] WARN  org.apache.kafka.clients.admin.AdminClientConfig - The configuration 'key.converter' was supplied but isn't a known config.

Some post says its because topic creation is disabled, but it's not in my case. The storage topic is still created.

The other mentions it's version mismatch, it's also not in my case. The kafka broker version is 1.0.0, and Kafka-Connect the same as the following pom.xml. Those configurations are provided during the start of Kafka-Connect

<properties>
      <!-->
      Confluent version must match Kafka version
      https://docs.confluent.io/current/installation/versions-interoperability.html
      <-->
        <kafka.version>1.0.0</kafka.version>
        <confluent.version>5.1.2</confluent.version>
        <debezium-connector-mongodb.version>0.7.4</debezium-connector-mongodb.version>
        <logging.version>2.11.2</logging.version>
    </properties>

    <dependencies>
        <dependency>
            <groupId>org.apache.kafka</groupId>
            <artifactId>connect-json</artifactId>
            <version>${kafka.version}</version>
            <scope>runtime</scope>
        </dependency>
        <dependency>
            <groupId>org.apache.kafka</groupId>
            <artifactId>connect-runtime</artifactId>
            <version>${kafka.version}</version>
            <scope>runtime</scope>
            <exclusions>
                <exclusion>
                    <groupId>org.slf4j</groupId>
                    <artifactId>slf4j-log4j12</artifactId>
                </exclusion>
            </exclusions>
        </dependency>
        <dependency>
            <groupId>io.debezium</groupId>
            <artifactId>debezium-connector-mongodb</artifactId>
            <version>${debezium-connector-mongodb.version}</version>
        </dependency>
        <dependency>
            <groupId>org.apache.kafka</groupId>
            <artifactId>connect-file</artifactId>
            <version>${kafka.version}</version>
            <scope>runtime</scope>
        </dependency>
        <dependency>
            <groupId>io.confluent</groupId>
            <artifactId>kafka-connect-jdbc</artifactId>
            <version>${confluent.version}</version>
            <scope>runtime</scope>
            <exclusions>
                <exclusion>
                    <groupId>log4j</groupId>
                    <artifactId>log4j</artifactId>
                </exclusion>
                <exclusion>
                    <groupId>org.slf4j</groupId>
                    <artifactId>slf4j-log4j12</artifactId>
                </exclusion>
            </exclusions>
        </dependency>

what would be something else I should check for fixing those warnings? I can see the data is delivered via Kafka-Connect, but still am worried about theses warnings

Robin Moffatt
  • 30,382
  • 3
  • 65
  • 92
Holm
  • 2,987
  • 3
  • 27
  • 48

1 Answers1

19

These are just WARNings, and can be ignored. In future releases they will be correctly suppressed: https://github.com/apache/kafka/pull/5876

Robin Moffatt
  • 30,382
  • 3
  • 65
  • 92
  • I think it's because those constants are not in the Kafka Client(AdminClientConfig) library, but they are called in Kafka-Connect for what reason? – Holm Apr 01 '19 at 16:10
  • 2
    Across the Kafka-estate, it might be useful to track user-supplied config (somehow) rather than totally suppressing these warnings; if a user supplies config deliberately with the expectation it will alter the semantics or processing, it serves as a good hint that your expectations might not pan out :p ...probably the original intention – Darren Bishop May 20 '20 at 12:44
  • 26
    I still see these in kafka 2.6.0. Ignoring is really not a good answer - the logs should be clean so the monitoring team can react to valid warnings. – dlipofsky Nov 11 '20 at 20:54
  • 1
    @dlipofsky that PR that I reference is still open, so I guess you could follow up on that if you want to progress this :) – Robin Moffatt Nov 12 '20 at 09:31