[aerogear-dev] Simplify the metrics for sanity

Fri May 26 03:48:57 EDT 2017

I say,

and then rethinking what value we want to give and how to do it properly.

Just one thing, we need the "pending" state for the UI as a "loading"
state, from the moment we click the button "send notification" until one of
the two states you propose is reached.

On 25 May 2017 at 13:26, Leigh Griffin <lgriffin at redhat.com> wrote:

> +1 to removing it and rethinking the value in what is presented!
>
> It could also lead to false assumptions about end device delivery, when in
> reality it's delivering it to the gateway.
>
> On Wed, May 24, 2017 at 4:58 PM, Oleh Mackiv <omatskiv at redhat.com> wrote:
>
>> Hi Matthias,
>> I agree with your idea. I think that device counter for Android is really
>> confusing so lets remove it. And as you described it, pending state doesn't
>> add much value.
>>
>> Cheers,
>> Oleg
>>
>> On Wed, May 24, 2017 at 10:30 AM, Matthias Wessendorf <matzew at apache.org>
>> wrote:
>>
>>> Hi,
>>>
>>> we do have a problem w/ our current metrics processing. It's complicated
>>> (lot'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.
>>>
>>> I'd like to dramatically simplify our metrics processing... to something
>>> like:
>>> Success -> could connect to 3rd party, to deliver tokens
>>> Failure -> something went wrong when talking to 3rd party service.
>>>
>>>
>>> Right now we do have metrics on push delivery:
>>> Pending -> the submission to the 3rd party provider is in flight
>>> Success -> we were able to connect, and could deliver *something*
>>> Failure -> something obvious, like invalid certificate (APNs), no
>>> connection to 3rd party possible, etc
>>>
>>> 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'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.
>>>
>>> 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).
>>>
>>> So, for now, I'd like to dramatically simplify the code, and go with the
>>> above Success/Failure solution.
>>>
>>> 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.
>>>
>>> This will give us much more freedom and flexibility. Perhaps also, in
>>> the future, we want some different stats, and something like Prometheus
>>> /Grafana:
>>> https://prometheus.io/docs/visualization/grafana/
>>>
>>> A more flexible system, with independent metrics 'calculation'
>>> processing will help us here.
>>>
>>> Any thoughts?
>>>
>>> -Matthias
>>>
>>>
>>>
>>> --
>>> Matthias Wessendorf
>>>
>>> blog: http://matthiaswessendorf.wordpress.com/
>>> twitter: http://twitter.com/mwessendorfa
>>>
>>> _______________________________________________
>>> aerogear-dev mailing list
>>> aerogear-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>
>>
>>
>>
>> --
>> Oleg Matskiv
>> Associate Quality Engineer
>> Red Hat Mobile Application Platform
>> omatskiv at redhat.com
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>
>
>
> --
>
> LEIGH GRIFFIN
>
> ENGINEERING MANAGER, MOBILE
>
> Red Hat Ireland <https://www.redhat.com/>
>
> Communications House, Cork Road
>
> Waterford City, Ireland X91NY33
>
> lgriffin at redhat.com    M: +353877545162     IM: lgriffin
> <https://red.ht/sig>
> TRIED. TESTED. TRUSTED. <https://redhat.com/trusted>
>
> @redhatway <https://twitter.com/redhatway>   @redhatinc
> <https://instagram.com/redhatinc>   @redhatsnaps
> <https://snapchat.com/add/redhatsnaps>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>

-- 

JOSE MIGUEL GALLAS OLMEDO

ASSOCIATE QE, mobile

Red Hat

<https://www.redhat.com/>

M: +34618488633 <http://redhatemailsignature-marketing.itos.redhat.com/>
<https://red.ht/sig>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20170526/316cf930/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kill-it.gif
Type: image/gif
Size: 158108 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/aerogear-dev/attachments/20170526/316cf930/attachment-0001.gif 