+1 for auditing table On Mon, May 8, 2017 at 2:45 PM, Ayyoob Hamza <[email protected]> wrote:
> Hi Ruwan, > > +1 for this, Having the communication history through a common stream will > help us to build an analytics solution for health status, anomaly detection > .. etc. > > On Mon, May 8, 2017 at 12:35 PM, Ruwan Yatawara <[email protected]> wrote: > >> Hi Everyone, >> >> I am working on $subject as part of the effort in trying to provide dig >> down analytics for devices. >> >> The resulting graph would look something like the following (Please >> disregard portion reading connected-unterminated), with the help of [1] and >> will give an would indicate whether the device in question was able to get >> back to IoT Server in a timely manner at the expected monitoring frequency >> specified. >> [image: Inline image 1] >> *Source: [2]* >> > we can't infer whether the device is disconnected from the server using > the raw history data points right?. We might need todo some form of a > time series analytisis on the device to server communication (This will > vary depend on the frequency of the communication for each device type) and > then predict the device status. The communication history data will help us > build a solution for the health status. > > >> Whilst attempting this I noticed that we do not have an auditing >> mechanism in place to record important activities, as yet. If you take this >> flow, for example, the monitoring frequency is something configurable and >> will change from time to time. We need to know at which point the >> transition was made. >> >> Therefore I propose, that we come up with a central audit table to record >> system activities, like updates to platform configurations, in a central >> table. Each activity can have a logging code, and we can purge these >> records from time to time, based on data growth. >> > +1 we do this only for operation, but we should have this for all the > internal communication. > >> >> > I also propose that we, take out the option for users to enable/disable >> data publishing from the agent side, and make it implicit. The agent by >> default makes a call to the server to send device information, instead of >> making the device make another call to DAS to provide location information, >> we can derive the location information at the server side from the device >> information payload and push it to DAS. >> > I think this is how its been implemented for the EMM Usecases, correct me > if I am wrong. We publish from the IoT Core to DAS through thrift. > > *Ayyoob Hamza* > *Senior Software Engineer* > WSO2 Inc.; http://wso2.com > email: [email protected] cell: +94 77 1681010 <%2B94%2077%207779495> > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- ============================ Srinath Perera, Ph.D. http://people.apache.org/~hemapani/ http://srinathsview.blogspot.com/
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
