Prometheus-kafka-adapter is a service which receives Prometheus metrics through remote_write
, marshal into JSON and sends them into Kafka.
It is able to write JSON or Avro-JSON messages in a kafka topic, depending on the SERIALIZATION_FORMAT
configuration variable.
{
"timestamp": "1970-01-01T00:00:00Z",
"value": "9876543210",
"name": "up",
"labels": {
"__name__": "up",
"label1": "value1",
"label2": "value2"
}
}
timestamp
and value
are reserved values, and can't be used as label names. __name__
is a special label that defines the name of the metric and is copied as name
to the top level for convenience.
The Avro-JSON serialization is the same. See the Avro schema.
There is a docker image telefonica/prometheus-kafka-adapter:1.8.0
available on Docker Hub.
Prometheus-kafka-adapter listens for metrics coming from Prometheus and sends them to Kafka. This behaviour can be configured with the following environment variables:
KAFKA_BROKER_LIST
: defines kafka endpoint and port, defaults tokafka:9092
.KAFKA_TOPIC
: defines kafka topic to be used, defaults tometrics
. Could use go template, labels are passed (as a map) to the template: e.g:metrics.{{ index . "__name__" }}
to use per-metric topic. Two template functions are available: replace ({{ index . "__name__" | replace "message" "msg" }}
) and substring ({{ index . "__name__" | substring 0 5 }}
)KAFKA_COMPRESSION
: defines the compression type to be used, defaults tonone
.KAFKA_QUEUE_BUFFERING_MAX_MESSAGES
: defines the maximum number of messages allowed on the producer queue, defaults to100000
.KAFKA_BATCH_NUM_MESSAGES
: defines the number of messages to batch write, defaults to10000
.SERIALIZATION_FORMAT
: defines the serialization format, can bejson
,avro-json
, defaults tojson
.PORT
: defines http port to listen, defaults to8080
, used directly by gin.BASIC_AUTH_USERNAME
: basic auth username to be used for receive endpoint, defaults is no basic auth.BASIC_AUTH_PASSWORD
: basic auth password to be used for receive endpoint, defaults is no basic auth.LOG_LEVEL
: defines log level forlogrus
, can bedebug
,info
,warn
,error
,fatal
orpanic
, defaults toinfo
.GIN_MODE
: manage gin debug logging, can bedebug
orrelease
.
To connect to Kafka over SSL define the following additional environment variables:
KAFKA_SSL_CLIENT_CERT_FILE
: Kafka SSL client certificate file, defaults to""
KAFKA_SSL_CLIENT_KEY_FILE
: Kafka SSL client certificate key file, defaults to""
KAFKA_SSL_CLIENT_KEY_PASS
: Kafka SSL client certificate key password (optional), defaults to""
KAFKA_SSL_CA_CERT_FILE
: Kafka SSL broker CA certificate file, defaults to""
To connect to Kafka over SASL/SCRAM authentication define the following additional environment variables:
KAFKA_SECURITY_PROTOCOL
: Kafka client used protocol to communicate with brokers, must be set if SASL is going to be used, either plain or with SSLKAFKA_SASL_MECHANISM
: SASL mechanism to use for authentication, defaults to""
KAFKA_SASL_USERNAME
: SASL username for use with the PLAIN and SASL-SCRAM-.. mechanisms, defaults to""
KAFKA_SASL_PASSWORD
: SASL password for use with the PLAIN and SASL-SCRAM-.. mechanism, defaults to""
When deployed in a Kubernetes cluster using Helm and using a Kafka external to the cluster, it might be necessary to define the kafka hostname resolution locally (this fills the /etc/hosts of the container). Use a custom values.yaml file with section hostAliases
(as mentioned in default values.yaml).
Prometheus needs to have a remote_write
url configured, pointing to the '/receive' endpoint of the host and port where the prometheus-kafka-adapter service is running. For example:
remote_write:
- url: "http://prometheus-kafka-adapter:8080/receive"
When deployed in a Kubernetes cluster using Helm and using an external Prometheus, it might be necessary to expose prometheus-kafka-adapter input port as a node port. Use a custom values.yaml file to set service.type: NodePort
and service.nodeport: <PortNumber>
(see comments in default values.yaml)
The provided Makefile can do basic linting/building for you simply:
make fmt
-> basic formatting.make test
-> runsgo test
fixturesmake vet
-> runsgo vet
against the packagemake vendor-update
-> ensure dependencies are up to datemake
-> builds libc and musl based binaries, including testing and vetting code
With issues:
- Use the search tool before opening a new issue.
- Please provide source code and commit sha if you find a bug.
- Review existing issues and provide feedback or react to them.
With pull requests:
- Open your pull request against
master
- It should pass all tests in the continuous integration pipeline (Github Actions).
- You should add/modify tests to cover your proposed code changes.
- If your pull request contains a new feature, please document it in this README.
Copyright 2018 Telefónica
Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.