Hi Ruwan, I also propose that we, take out the option for users to enable/disable data publishing from the agent side, and make it implicit. This was added in an extensible way so that data /log publishing to outside systems such as splunk can be done by using the extension points for custom scenarios.
Regards, Inosh On 9 May 2017 10:09 a.m., "Srinath Perera" <srin...@wso2.com> wrote: > +1 for auditing table > > On Mon, May 8, 2017 at 2:45 PM, Ayyoob Hamza <ayy...@wso2.com> 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 <ruw...@wso2.com> 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: ayy...@wso2.com cell: +94 77 1681010 <%2B94%2077%207779495> >> >> _______________________________________________ >> Architecture mailing list >> Architecture@wso2.org >> 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 Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
