lordgamez commented on code in PR #1340: URL: https://github.com/apache/nifi-minifi-cpp/pull/1340#discussion_r898829922
########## METRICS.md: ########## @@ -0,0 +1,153 @@ +<!-- + Licensed to the Apache Software Foundation (ASF) under one or more + contributor license agreements. See the NOTICE file distributed with + this work for additional information regarding copyright ownership. + The ASF licenses this file to You 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. +--> + +# Apache NiFi - MiNiFi - C++ Metrics Readme. + + +This readme defines the metrics published by Apache NiFi. All options defined are located in minifi.properties. + +## Table of Contents + +- [Description](#description) +- [Configuration](#configuration) +- [Metrics](#metrics) + +## Description + +Apache NiFi MiNiFi C++ can communicate metrics about the agent's status, that can be a system level or component level metric. +These metrics are exposed through the agent implemented metric publishers that can be configured in the minifi.properties. +Aside from the publisher exposed metrics, metrics are also sent through C2 protocol of which there is more information in the +[C2 documentation](C2.md#metrics). + +## Configuration + +To configure the a metrics publisher first we have to set which publisher class should be used: + + # in minifi.properties + + nifi.metrics.publisher.class=PrometheusMetricsPublisher + +Currently PrometheusMetricsPublisher is the only available publisher in MiNiFi C++ which publishes metrics to a Prometheus server. +To use the publisher a port should also be configured where the metrics will be available to be scraped through: + + # in minifi.properties + + nifi.metrics.publisher.port=9936 Review Comment: As currently we only support having a single publisher configured at a time I wanted to reflect that in the configuration as well. If we changed it to `nifi.metrics.publisher.PrometheusMetricsPublisher.port` that would suggest that we can have multiple publishers in the `nifi.metrics.publisher.class` as well. The other option is to change the property to `nifi.metrics.publisher.classes` and prepare the code to handle multiple publishers in advance. That would make the configuration backwards compatible in the future, but would also introduce some unneeded complexity of parsing and handling the publishers at the moment. I would keep it like this for now and if we want to support exposing multiple publisher classes at the same time then we would change the configuration and the parsing accordingly. What do you think? ########## extensions/prometheus/PublishedMetricGaugeCollection.cpp: ########## @@ -0,0 +1,49 @@ +/** + * Licensed to the Apache Software Foundation (ASF) under one or more + * contributor license agreements. See the NOTICE file distributed with + * this work for additional information regarding copyright ownership. + * The ASF licenses this file to You 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. + */ +#include "PublishedMetricGaugeCollection.h" + +#include <utility> +#include <algorithm> + +#include "prometheus/client_metric.h" +#include "state/PublishedMetricProvider.h" +#include "range/v3/range/conversion.hpp" +#include "range/v3/view/transform.hpp" + +namespace org::apache::nifi::minifi::extensions::prometheus { + +PublishedMetricGaugeCollection::PublishedMetricGaugeCollection(std::shared_ptr<state::PublishedMetricProvider> metric) : metric_{std::move(metric)} { +} + +std::vector<::prometheus::MetricFamily> PublishedMetricGaugeCollection::Collect() const { + std::vector<::prometheus::MetricFamily> collection; + for (const auto& metric : metric_->calculateMetrics()) { + ::prometheus::ClientMetric client_metric; + client_metric.label = ranges::views::transform(metric.labels, [](auto&& kvp) { return ::prometheus::ClientMetric::Label{kvp.first, kvp.second}; }) + | ranges::to<std::vector<::prometheus::ClientMetric::Label>>; + client_metric.gauge = ::prometheus::ClientMetric::Gauge{metric.value}; + collection.push_back({ + .name = metric.name, + .help = "", + .type = ::prometheus::MetricType::Gauge, + .metric = { client_metric } + }); Review Comment: Most guidelines discouraged prefixes for metric names and I didn't want to use it because Prometheus already adds a `job` label for the metric with the `minifi` value that can be filtered for. But I checked the [Prometheus best practices](https://prometheus.io/docs/practices/naming/) and it says that the metrics should have an application name as a prefix to mark the domain (or sometimes it's not an application name but something general like `http`). In our case using `minifi_` prefix is a good idea I added it in 96431d07a867a26723d9d6c2cf71edc1d1dd0b17 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
