2:51 a.m.
* What's the (+) under 7 total users?
-> currently it's only a placeholder but the idea is to link to the "create
new user" page
* What's the purpose of "Logins along the year" - it looks cool, but
I'm
not sure how it'd be used.
It would also require storing events for the whole year.
-> This heatmap gives you an idea of the overall realm usage over the year
at a glance - which allows
to recognize patterns visually if the thresholds are calibrated accordingly.
It could also be used to identify login problems e.g. after rolling out a
new version - fewer logins than before
could indicate problems for some users.
* I'm not keen on having db specific views. We already support quite a few
dbs so maintaining these would be painful.
Would be better to delegate this to Hibernate if possible and use ejq
queries.
-> One could of course replace the fews with simple more simple and generic
queries that could also
be expressed via jpaql but this would require some processing within the
keycloak server.
At least for this prototype I wanted to keep the amount of code small.
On the other hand view definitions for each database allow for optimal
performance if you
need to compute statistics / summaries after the fact from events.
One could also compute the statistics eagerly e.g. update with each login
(via custom EventListener).
An alternative approach for computing summary / login statistics would be
to use some kind of approximation mechanism.
E.g. instead of computing the summary from the events one could also use a
sketching data structure like a count min-sketch
that is updated with each login (via custom EventListener) with an
appropriately configured accuracy (e.g. 99%) that work with
a fixed amount of memory.
* Logins/Registrations should display date and time. At least if date is
not today.
-> Date is displayed if date is not the same day ;-)
Some additional remarks:
-> The lower line of the cards in the upper area are currently mocked.
In the login card the "red 4 | 1" is meant to indicate 4 failed logins
and 1 login
that lead to a blocked account.
The "red 1" below the registrations card should indicate 1 failed
registration
attempt (e.g. something wrong in the server side). I can also imagine an
indicator for "aborted" registration attempts.
-> The "latest logins" as well the "New registrations" should
actually be
right next to each other instead of below each other.
-> The REST endpoint, currently called DashboardResource, could also be
exposed
in a more generic form like "AnalyticsResource" which could then offer
various time series and summaries as JSON output for consumption by other
tools like nagios.
2016-05-30 7:47 GMT+02:00 Stian Thorgersen <sthorger(a)redhat.com>:
That's really cool and would be great to have this added to
Keycloak.
Some questions/comments:
* What's the (+) under 7 total users?
* What's the purpose of "Logins along the year" - it looks cool, but
I'm
not sure how it'd be used. It would also require storing events for the
whole year.
* I'm not keen on having db specific views. We already support quite a few
dbs so maintaining these would be painful. Would be better to delegate this
to Hibernate if possible and use ejq queries.
* Logins/Registrations should display date and time. At least if date is
not today.
On 29 May 2016 at 22:52, Thomas Darimont <thomas.darimont(a)googlemail.com>
wrote:
> Hello group,
>
> a few months ago I raised the feature request "Activity dashboard" in the
> Keycloak JIRA.
> https://issues.jboss.org/browse/KEYCLOAK-1840
>
> This weekend I gave this a spin and I think I got pretty far with it,
> see attached annotated screenshot.
>
> The idea was to leverage the information from the stored event data
> to compute some Keycloak usage statistics over time.
> My current prototype supports JPA (user / event) storage provider
> and works with postgresql but could be adapted to other databases
> including MongoDB.
>
> Since I need to compute the usage statistics based on the event data,
> events need to be stored and some views (3) need to be defined to
> make the data accessible from JPA in a generic fashion.
>
> Since the queries are quite complex I wanted to keep them out
> of the code and therefore used named native queries via orm.xml.
> The actual queries use some database specific date/time functions
> that I wanted to keep out of the code - thus I created views
> that could be adapted for each database and provisioned via liquibase.
>
> The view definitions can be found here:
> https://gist.github.com/thomasdarimont/24e11be101c6ed8773f22e1defc5d66e
>
> For MongoDB one could define appropriate aggregation framework pipelines
> to express the same query logic.
>
> I basically exposed the data from those views per realm via a newly
> introduced AnalyticsProvider interface that is accessible via
> KeycloakSession.
>
> Data from this AnalyticsProvider is then exposed as a REST resource
> called "DashboardResource".
> Data from this REST endpoint is then consumed by the admin frontend in a
> new section
> called "dashboard".
>
> In the frontend I used basic patternfly components, e.g.: cards & tables:
> https://rawgit.com/patternfly/patternfly/master/tests/cards.html
>
> For the heatmap I used http://cal-heatmap.com/#start which is based on
> d3js.
> There is also an angularjs directive that could be used as well.
> https://github.com/shekhargulati/angular-cal-heatmap-directive
>
> The current hacky code can be found here.:
>
> https://github.com/thomasdarimont/keycloak/commits/poc/KEYCLOAK-1840-dash...
>
> The relevant commit is:
>
>
https://github.com/thomasdarimont/keycloak/commit/40a7956f8e547edc148d2dd...
>
> The code still needs a decent amount of polishing but I wanted to share
> this with
> you guys first to see if this could make it into Keycloak at some point.
>
> Cheers,
> Thomas
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>