Github user kevdoran commented on a diff in the pull request:
https://github.com/apache/nifi-minifi/pull/118#discussion_r175812152
--- Diff:
minifi-c2/minifi-c2-commons/src/main/java/org/apache/nifi/minifi/c2/model/C2Heartbeat.java
---
@@ -0,0 +1,66 @@
+/*
+ * 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.
+ */
+package org.apache.nifi.minifi.c2.model;
+
+import io.swagger.annotations.ApiModel;
+import io.swagger.annotations.ApiModelProperty;
+
+import java.util.Map;
+
+@ApiModel
+public class C2Heartbeat {
+
+ // TODO, timestamp?
+ private DeviceInfo deviceInfo;
+ private AgentInfo agentInfo;
+ private FlowInfo flowInfo;
+ private Map<String, String> metrics;
--- End diff --
Typed metrics have been incorporated as nested objects of the top-level
DeviceInfo, AgentInfo, and FlowInfo objects.
The thinking of the additional `Map<String, String> metrics` fields was
that it might be useful for agents to include some custom measurements in a
heartbeat that are not "core" to the MiNiFi agent, but are relevant to the
particular deployment use case or scenario. For example:
"metrics": {
"com.example.device.battery.health": "0.8",
"com.example.device.battery.cycle-count": "334",
"com.example.device.battery.charge": "0.2"
}
I was thinking that if we built such a framework, all metrics would be
produced as string values (to make it easy to recieve adhoc metrics without
typing metadata), so the it would be the responsibility of the consumer,
presumably customize, to cast the metrics to the desired type. The idea was
that the C2 server would just be an input point for these adhoc metrics that
would then get forwarded to some other time-series metrics store such as Ambari
Metrics System, Graphite, Datadog, etc. Those storage systems usually provide
their own type conversion capabilities, so I was thinking it could keep the
requirements for of defining these customized metrics lightweight and pass the
interpretation logic downstream.
I don't think there is a need/use for this field yet, so I'll remove this
for this PR. At a minimum, it requires work on the agent side to enable a way
to add custom metrics to a heartbeat, so we don't need to officially put it
into the C2 protocol until we have a need and end-to-end design to support it.
There also might be a different way to solve this problem (I could think of
ways to do it without C2 just using site-to-site, or maybe C2 heartbeats is the
right approach, but accurate typing is needed) We can discuss it as a feature
proposal and re-introduce it if people have a need for a way to add custom
metrics to be collected by the MiNiFi agent to be reported in the heartbeat to
the C2 Server.
---
