MetricLogger shouldn't throw exception

[takezoe]

Fluency throws an exception when the buffer is full and fail to flush, but it shouldn't break the host logic even if such unknown errors occur inside of it.

[xerial]

Most likely AnyCodec has an issue if this part is throwing an exception

[xerial]

@takezoe So we also need to wrap TypeMetricLogger.emit

[takezoe]

I see. I'll update to wrap emit().

[codecov]

Codecov Report

Merging #757 into master will increase coverage by <.01%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master     #757      +/-   ##
==========================================
+ Coverage   83.31%   83.32%   +<.01%     
==========================================
  Files         217      217              
  Lines        8633     8634       +1     
  Branches      608      606       -2     
==========================================
+ Hits         7193     7194       +1     
  Misses       1440     1440

Impacted Files	Coverage Δ
...in/scala/wvlet/airframe/fluentd/MetricLogger.scala	76.47% <100%> (+1.47%)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 7603f16...15afbcc. Read the comment docs.

[xerial]

It would be great if there is an way to show warning messages at least once for the same type of errors. For example, while debugging we usually need to know the cause of errors.

[xerial]

Second thought:

• Essentially we need a circuit breaker if reporting metrics becomes difficult due to fluency or network issues. This feature can be added to airframe-control.
• Usually throwing an exception is better so that the client side program can decide what to do if metrics cannot be send. For example, we can store metrics to a disk, then resume sending metrics to fluentd if it recovers. This behavior should be configurable (e.g., report warning, ignore exceptions, throw exceptions)

[takezoe]

Certainly, MetricLogger is not for only logging but also for sending system metrics. If sending metrics is the responsibility of the client, an exception should be handled in the client-side. OK, I withdraw this pull request and implement error handling in the client-side.