[aerogear-dev] Mobile Statistics using Grafana, Prometheus running on OpenShift

[David Martin]

I'd like to to try bring this back to the Story that the investigation is
helping to derisk [1]
"As a developer I want to be able to visualise runtime metrics about what
versions of the mobile service SDKs are in use so that I can track what
versions are used and see uptake of new SDK versions in order to deprecate
services linked to older SDKs [met]"

Does the investigation work that was done [2] allow us to deliver that
Story [1] and related Story [3] in the future?
The main value in those stories is:
- a developer seeing what versions of the Mobile SDK are in use (and
probably OS/user agent)
- a developer seeing what app versions are in use

Some dicussions offline with John has suggested this information be
automatically available to the developer if:
- the developer is using the Core SDK (They should be if they're using any
Mobile Service, as its a pre-requisite for any other Mobile Service SDK)
- the developer has provisioned the Metrics Service

'automatically available' implies that it happens on app startup or in the
background at some point.

If the developer hasn't provisioned the Metrics service, the Core SDK
doesn't send any SDK or app version info (as it has nowhere to send it to)

[1]
https://trello.com/c/lt4jc3h4/10-as-a-developer-i-want-to-be-able-to-visualise-runtime-metrics-about-what-versions-of-the-mobile-service-sdks-are-in-use-so-that
[2] https://issues.jboss.org/browse/AEROGEAR-1816
[3]
https://trello.com/c/HZ5BTwZY/11-as-a-developer-i-want-to-be-able-to-visualise-runtime-metrics-about-what-versions-of-the-mobile-app-are-in-use-so-that-i-can-tra

On 10 January 2018 at 14:42, Wojciech Trocki <wtrocki at redhat.com> wrote:

> Thanks David. Really good question.
>
> I ignored mobile implementation in demo as most of the work for this was
> done on server side.
> I'm using different more extended use cases to drive SDK work.
>
> For mobile application there were couple manual steps:
>
> 1) Generate mobile configuration using mobile-client (not mobile specific)
> 2) Drop configuration including URL into application (not mobile specific)
> 3) Extract URL from configuration.
> 4) Use AFNetworking framework (IOS) to make network request.
>
> I did not implemented that on Android platform, but flow should be the
> same.
> After obtaining URL/configuration to service users can make any API calls.
> The only complexity will come with authentication - for example when using
> keycloak, but that will require additional effort.
>
> IMHO At this point it's better to rely on sync service for initial SDK
> service as it has non trivial client implementation (business logic etc.)
> It's also clear that Sync will be used with some modified form.
> For SDK investigations we are focused on extending step 3 and 4 into core
> of our library.
> Once that is done we can simply integrate two most important SDK's: Sync
> and Push.
>
> Main goals are:
>
> - Investigate/implement android core library that will create map of
> services from provided json/plist file.
> - Integrate existing SDK sync and push
> - Try to extract network into core (using aerogear-android-pipe from push
> server)
>
> In the mean time we are working on SDK proposal and top level API (using
> annotations)
> BOM style dependency management that will improve user experience and
> reduce versioning hell on Android platform.
>
> After doing that we can drive this forward and run sync behind keycloak
> which should show us how we can provide authentication.
> We may also extend mobile-cli to provide more service specific information
> that is needed.
>
> I think that clearly summarizing entire SDK initiative at this moment.
>
> On Wed, Jan 10, 2018 at 12:37 PM, David Martin <davmarti at redhat.com>
> wrote:
>
>> Very nice Wojciech.
>>
>> I'd love to see/hear more about how it works from the Mobile App, if that
>> piece is working.
>> Did you populate stats using the App, or by just curling an endpoint?
>> (Maybe you said and I missed that)
>>
>>
>>
>> On 10 January 2018 at 12:22, Wojciech Trocki <wtrocki at redhat.com> wrote:
>>
>>> Forwarding to internal list as AeroGear list seems to be having problems
>>> with mail delivery.
>>>
>>> ---------- Forwarded message ----------
>>> From: Wojciech Trocki <wtrocki at redhat.com>
>>> Date: Tue, Jan 9, 2018 at 7:55 PM
>>> Subject: Mobile Statistics using Grafana, Prometheus running on OpenShift
>>> To: AeroGear Developer Mailing List <aerogear-dev at lists.jboss.org>
>>>
>>>
>>> Hi everyone
>>>
>>> I have been working today on investigation for enabling mobile
>>> application statistics on top of OpenShift.
>>> The main target was to enable mobile clients (using our SDK) to send
>>> statistics payload to server.
>>> For this purpose we were sending back mobile.next() SDK version from
>>> different mobile clients and visualizing that data Grafana.
>>>
>>> *Demo: *
>>>
>>> https://www.youtube.com/watch?v=zC95jJr1kcc
>>>
>>> *Where is the value? *
>>>
>>> Grafana, can be used to showcase various statistics that mobile
>>> developers will need without extended development effort.
>>>
>>> *How we can extend this:*
>>>
>>> - Investigate different ways to store data in Prometheus (using labels
>>> etc.)
>>> - Integrate with Keycloak to showcase SDK capabilities and permissions.
>>> - Golang implementation for service
>>>
>>> Regards
>>> --
>>>
>>> WOJCIECH TROCKI
>>>
>>> Red Hat Mobile <https://www.redhat.com/>
>>>
>>> IM: wtrocki
>>> <https://red.ht/sig>
>>>
>>>
>>
>>
>> --
>> David Martin
>> Red Hat Mobile
>> Twitter: @irldavem
>> IRC: @irldavem (#aerogear)
>>
>
>
>
> --
>
> WOJCIECH TROCKI
>
> Red Hat Mobile <https://www.redhat.com/>
>
> IM: wtrocki
> <https://red.ht/sig>
>



-- 
David Martin
Red Hat Mobile
Twitter: @irldavem
IRC: @irldavem (#aerogear)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20180110/499ac1ea/attachment-0001.html