Remote Logging and Reporting

[Dmitry A.]

Hi everyone,

There is something new that came across our minds that all In-Portal users and developers can benefit from. This ability to for Remote Logging and Reporting to In-Portal developers. I am sure you have saw this before in all sorts of applications (ie. Browsers, OS and so) when you are offered to send your application log to developers if it crashed or something else happened. We can discuss all sort of ideas here.

The basic idea is very simple (implementation is not so simple) - let In-Portal users to decide if he want's to send a feedback containing logs to In-Portal Developers.

Cheers!

DA

[Alexander Obuhovich]

From the implementation viewpoint here is how I see it:

Create EventLog class (and associated EventLog table), that would:

• handle sql error processing
• handle php error processing
• handle exception processing
• ability to handle user defined events

What should be recorded along with each event being logged:

• $_SERVER['HTTP_HOST'] to store host, where problem was found in multi-user development environment
• $_SERVER['REMOTE_ADDR'] - ip address
• current user id (guest or not)
• SessionData table - session data
• SessionID - session id (when available)
• $_GET, $_POST, $_COOKIE - user input on page, where event happened
• $_SERVER['REQUEST_URI'] - url that was used to access the page
• $this->Application->isAdminUser - is user an admin or not
• complete trace to the php method, that raised that error event

During submission to In-Portal.Com website "127.0.0.1" in $_SERVER['REMOTE_ADDR'] will be replaced with IP address, used for data submission.

--
Best Regards,

http://www.in-portal.com
http://www.alex-time.com

[Phil -- wbtc.fr --]

this is a very good idea :-)

2011/2/9 Alexander Obuhovich <aik....@gmail.com>

[Alexander Obuhovich]

I also agree, since:

1. if there is something happening in background (e.g. strange errors in error.log of web server), then we will know it even before it reports about it an be able to develop a patch to fix that (maybe even auto deploy back do client's web server)
2. during development process some errors could happen just before popup window closes and we are unaware about that, now regular visiting this "event log" section should get a clear picture what's happening to a developer and to it's manager (if any)
3. errors happening, when debugger is not enabled (e.g. on client website or fck editor) won't be unnoticed
4. errors specific to execution from cron (e.g. from agents) will be noticed too (that's what you suggested Phil)
5. and much more ...

[Dmitry A.]

This is seems to turn out as quite cool idea.

Let's come up with Implementation Plan for this so we can properly Plan and Document this in a task.

I suppose we need to cover the following:

1. Technical part. List all of features we'd like to have here (what kind information to be gathered and when, stored locally and send over to In-Portal Developers)

2. Legal part. Where in In-Portal we have Enable/Disable this option (at installation, post installation configuration)

3. Target In-Portal version for this feature.

Please feel free to add more if I missed anything.

DA

[Alexander Obuhovich]

Maybe manual submission mode is more user friendly. Here is how I suppose it will work:

1. some errors do happen and get logged
2. user has disabled automatic error submission
3. there is button "Submit To Intechnic" or something like that in event log list
4. when user have problems and have arranged to send his event log to Intechnic, then he click on that button and either selected or all unsent records are sent

Maybe sending only filtered (by search criteria) records will be better actually.

[Dmitry A.]

Hi Alex,

Thanks for posting your ideas. Yes, I find the idea of having ability to manually submit your event to In-Portal Developers quite useful too.

For both automatic (should happen using Agent) and manual reporting I would also mark off the Entries from Event Log which were already sent through to In-Portal Developers, plus have a timestamp on it.

What you think about this?

In the end we can offer both automatic and manual submission types. For some of us we can use automatic and some new users can start with manual and then switch to automatic as they develop more trust and require more assistance from us (developers).

Cheers!

DA

[Alexander Obuhovich]

Yes I found this quite useful too.

Also I recommend to make some kind of duplicate check on Intechnic website (based on EventId + EventDate). I'm checking by Date, since user can just delete old events to save space on disk and submit new ones with same IDs.

Grouping similar events into single record in database with RepeatCount or something like that (as I've already mentioned before) would preserve space too.

[Dmitry A.]

Agreed.

Alex, would you please put a short summary of what we have agreed on for Technical party of this task?

It's going to be hard tracking this done once we add up more here.

DA

[Alexander Obuhovich]

Here is the task, where I've summarized all above and added some from me too.

http://tracker.in-portal.org/view.php?id=1003

[Dmitry Andrejev]

Good work!

DA

--

Best regards,

Dmitry A.

[Phil -- wbtc.fr --]

Great Alex, I was about to ask for a special step during installation :)

for "Event log submission method", we could just ask for manual & automatic, and we could set internally by default a weekly report OR once 10 reports are logged, first limit reached (time or count) would trigger the report's sending.

Because if user setup "monthly" and his installation send us 300 reports, most of them about the same error, we'll need a lot of time to review it, while we could solve it sooner and address a patch.

What do you think guys?

2011/2/14 Alexander Obuhovich <aik....@gmail.com>

[Dmitry A.]

Well, we were thinking about Grouping the same Error reports from the same User so make it more simple.

DA

[Alexander Obuhovich]

We can actually send based on event flow.

This way the more errors each day, then more chances that it will be submitted the same day. This may be break error grouping, since it won't be good to change records, that were already submitted.

On Mon, Feb 28, 2011 at 7:59 PM, Dmitry A. <dand...@gmail.com> wrote:

Well, we were thinking about Grouping the same Error reports from the same User so make it more simple.

DA

[Dmitry A.]

Well, the question is how we are going to group (log submissions) what's coming in on our end?

We still going to know which User/Host/IP it came from so we can group it here, right?

DA

[Alexander Obuhovich]

We are not doing grouping for sending purposes.

If I recall correctly I was talking about grouping similar errors into 1 record in database with repeat count rather, then creating multiple records.

[Alexander Obuhovich]

Remote logging part of this discussion was moved into a separate discussion: https://groups.google.com/d/topic/in-portal-dev/o4In18xQeA4/discussion