[aerogear-dev] Simplify the metrics for sanity

Tue May 30 04:38:56 EDT 2017

On Fri, May 26, 2017 at 9:48 AM, Jose Miguel Gallas Olmedo <
jgallaso at redhat.com> wrote:

> 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.
>

Ok, the server has an "All Batches" loaded event, this one could be used to
implement that.

One problem is, that the "loading" means -> nasty poliing of the server,
until it is "done".
Unfortunately the queries are not that cool, they are a mess, for the
"metrics"

Also, one part of the problem is, that naively the UI aims to be a
real-time UI, which current architecture does not allow us

-M

> 
>
> 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>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>

-- 
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
twitter: http://twitter.com/mwessendorf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20170530/b77ba1bf/attachment.html 