<div dir="ltr">Hi,<div><br></div><div>we do have a problem w/ our current metrics processing. It&#39;s complicated (lot&#39;s of CDI events and two different JMS messaging approaches...) and also slow (JPQL/JDBC) and it does consume a lot of memory and processing time. This is leading to bugs (incorrect stats) and eventually causes down times, due to heavy processing.</div><div><br></div><div>I&#39;d like to dramatically simplify our metrics processing... to something like:</div><div>Success -&gt; could connect to 3rd party, to deliver tokens</div><div>Failure -&gt; something went wrong when talking to 3rd party service.</div><div><br></div><div><br></div><div><div>Right now we do have metrics on push delivery:</div><div>Pending -&gt; the submission to the 3rd party provider is in flight</div><div>Success -&gt; we were able to connect, and could deliver *something*</div><div>Failure -&gt; something obvious, like invalid certificate (APNs), no connection to 3rd party possible, etc</div><div><br></div><div>Besides that, we also do a count on targeted devices. I think there is not really a huge value. For instance if APNs rejects some tokens, we do not track those, we just show how many tokens our DB did find, not more. We don&#39;t show any of real interest. We could improve this (see below), but I doubt that the current implementation is able to handle this well.<br></div><div><br></div><div>Also, on Android/FCM the numbers are even worse. We do, internally, leverage their topics, so we usually end up sending exactly one push to FCM, regardless of how many Android device-tokens we have in the DB. The counter says 1 (one), because the server did target one topic (not n devices).</div><div><br></div><div>So, for now, I&#39;d like to dramatically simplify the code, and go with the above Success/Failure solution.</div><div><br></div><div>However, I honestly think in the long run, we should get something pluggable, that allows us to process the metrics independently, outside of the UPS code base. I think my previous Kafka mail is addressing this partially: The actual response and details about the push job should be logged to some Kafka system, and an independent process should be able to process those. </div><div><br></div><div>This will give us much more freedom and flexibility. Perhaps also, in the future, we want some different stats, and something like Prometheus /Grafana:</div><div><a href="https://prometheus.io/docs/visualization/grafana/">https://prometheus.io/docs/visualization/grafana/</a></div></div><div><br></div><div>A more flexible system, with independent metrics &#39;calculation&#39; processing will help us here.</div><div><br></div><div>Any thoughts?</div><div><br></div><div>-Matthias</div><div><br></div><div><div><br clear="all"><div><br></div>-- <br><div class="gmail-m_7852728415273694341gmail_signature"><div dir="ltr"><div>Matthias Wessendorf <br><br>blog: <a href="http://matthiaswessendorf.wordpress.com/" target="_blank">http://matthiaswessendorf.<wbr>wordpress.com/</a><br>twitter: <a href="http://twitter.com/mwessendorf" target="_blank">http://twitter.com/mwessendorf</a>a</div></div></div>
</div></div></div>