Log tracking

[let4be]

We need some way to collect logs/stacktraces/some debug statements from the application to be able to debug issues, without logs we're like without hands...

Also we're heavily using js/css transpiling so we also need to deal with source maps: https://trello.com/c/dDCrHeid/136-source-maps-on-production

This one looks promising: https://getsentry.com/welcome/

@andreis, @pzduniak , @flixi ideas are welcomed

[let4be]

Other alternatives to consider: https://errorception.com/ https://airbrake.io/ http://www.exceptionhub.com/

[flixi]

Status?

[flixi]

We need to make sure that the user's integrity is not compromised though.

[andreis]

We're gonna have a log management system on openstack, the question is how to send logs from the front end.

I suggest a "Report error" button that can be enabled/disabled in the Settings. Clicking the button warns the user that we'll send anonymized console logs to our servers, then proceeds to do so.

[let4be]

thing is: to be able to reproduce some kind of errors only error message and stacktrace is not enough, full logs required

[let4be]

also one another thing is making me sad: we still do not have proper stacktraces, transpiling we use + source maps = mumbo jumbo stacktrace

I have no idea how to solve this issue, I've tried all possible ways - nothing helps, most likely this is browser related thing

It stills possible to locate the code in transpiled source but it takes more time

[andreis]

Helps?

• http://stackoverflow.com/questions/25827234/how-to-debug-javascript-promises
• https://github.com/soareschen/es6-promise-debugging/blob/master/README.md

[andreis]

Most likely people will report bugs in prod, so it might be an idea (when in production) to switch the output of the logging from console to something that can be read at runtime (array in session storage?).

PS: Actually, I think the session storage idea is good, since (1) there will be private info in there and (2) if you want to report something you most likely won't leave the page before doing that – however you might reload the page. Still, let me know what you think about this idea.

[flixi]

A few users will also be allowed on stagingso it might not be only prod who's going to report bugs.

[flixi]

I like your ideas @andreis. However we need the ability and make sure to inform the user of things such as personal information may be transmitted. But we will keep all the info personal and delete the logs as soon as the issue seems to be fixed.

[flixi]

Status @andreis ?

[let4be]

I'm going to work on this soon, this is one of the most important things we need before we go into wide use of lavaboom

meanwhile any ideas how and when we should ask user about logs collection and submission?

@vLooz @flixi

[let4be]

we also need to send commit id within the logs so backend would know which sourcemaps to apply

[let4be]

so... There should be

• a button/slider to turn on and turn off log tracking(asking during signup and available under settings)
• a button to report an issue, probably with some kind of form where user could briefly describe what happened. What do you think?

Any design guidelines where better to put this? @flixi @vLooz

[flixi]

No, but we might want to integrate this into a bugzilla installation.

[let4be]

So this turned out to be not so simple task as I thought initially because of very limited capabilites of Session Storage, and I totally agree with @andreis - Session Storage backup required for proper work of this feature as page refresh is a common user's reaction to a sudden bug and in this case Session Storage will hold the logs data that will help user to properly report issue to us.

So far, we have to:

• store logs in json as session storage supports only strings
• store logs in chunks as we can't simply concatenate a string stored in session storage performance efficient(i.e. lavab-logs-chunk-0, lavab-logs-chunk-1, etc...) this would allow to significantly reduce the amount of wasted cpu cycles on saving, json encoding and decoding. Especially profitable with big logs(limited to ~5MB - session/local storage cross browser limit) and weak pc/mobile platforms
• don't write immediately after each intercepted log call, but instead serialize and dump data after some timeout interval(set to 1 sec currently)
• use compression + web worker to increase the amount of stored logs without introducing any freezes(http://pieroxy.net/blog/pages/lz-string/index.html)

This is already almost implemented

[andreis]

Most likely we'll need an API endpoint for saving logs. Either api.lavaboom.com/logs or logs.lavaboom.com

[let4be]

Okay, core logic almost ready from my side. What's left to do:

• conditionally turn and off logs/errors collection
• set reasonable limit and auto delete older logs to avoid hitting session storage limits
• clear stored logs
• bind to report api endpoint
• integrate into UI, open to ideas and suggestions. @andreis @flixi @vLooz how this should look like from the user perspective and what about bugzilla?

Here is the latest specification - source maps and example of report in json format https://www.dropbox.com/s/ito2ts4wdbr5n43/logs.7z?dl=0 (wanted to attach on github but: "Unfortunately, we don't support that file type")

[andreis]

:+1:

[let4be]

So the question stills actual! How this should look like from UX point and what flow are we going to choose?

[vLooz]

I have to admit that I only understand a fraction of all this technical jargon ;-) A button in settings to turn ON/OFF automatic bug reports + the necessary info what this means for privacy and a manual bug-report Icon I can design though.

How would you guys like the idea if the latter (bug-report button) would be above the log out button in the left panel? Of course only in the BETA accounts

[let4be]

@vLooz there are 2 primary parts of log tracking magic:

1. background logs/error collection and persistence between page refresh
2. error reporting that will include: subject, description, probably screenshot and other related information(to be discussed how and what) + all collected and persisted(to browser session storage) logs && errors

so there won't be any automatic bug reports . The thing that can be done automatically is logs/errors collection, here we can go for ON/OFF toggle.

The other part and how I see it: if user finds some issue he can press "Report bug" button where he will be able to describe his issue and the system will automatically register this issue via our API with the logs attached.

Here goes the question about bugzilla... are we going to use it and if so how should it be integrated? @andreis @flixi

[vLooz]

This are 2 proposals for the look of the "report a bug function"

[andreis]

First one, totally. @vLooz

[andreis]

@let4be: We'll definitely use Bugzilla or something like it (Trac?). Most likely hosted at https://lavab.wtf

[let4be]

Sounds good

[vLooz]

I like the first one better, too. The icon is in the updated icon font, look for "attention" @piggyslasher,

[vLooz]

This is how the toggle switch field in settings could look like:

Is that what you had in mind @let4be?

[vLooz]

By the way: Is there any way to obfuscate the content of the logged emails? I don't feel very good with the idea, that we can actually read our users emails. And to gain bug-related info from the logs, we don't need the actual content of the mails anyway, right? @andreis @pzduniak

[let4be]

@vLooz There are 2 groups of issues, one class of them requires access to full email body that caused the issue and another class can be debugged well without having this information

I suggest to give user a possibility to remove email bodies before doing a report, with a proper warning that it may make issue resolution impossible/hard

[vLooz]

Ok, thx for the info @let4be But coulnd't the first class also work with obfuscated mail content? I mean, it would still get the full email body, but with different (unreadable) mail content. Would that be an option?

[let4be]

unfortunately no., we perform extensive email post processing in order to display email:

• replace links to make them clickable
• replace emails to make them clickable and add context menu to them
• decrypt other embedded openpgp envelopes(implemented today)
• perform email body sanitization again malicious content

to debug all of this full original email body is must have

[vLooz]

Humm... I still don't like it. The thing is, zero knowledge is one of our main, if not THE main user benefit we advertise. It's what we sell to our users, it's what we claim to REALLY do different compared to all of those competitors who promise this, but in the background don't keep. In my opinion we just CAN'T read out clients mail content, otherwise our whole story collapses and we loose all the credibility, we've earned so far. Just my pov. What do you think about this @flixi?

[let4be]

We can make this beta-only feature with a proper warning, or we may not log such content at all thus we won't be able to debug some kind of issues at all.

[let4be]

Issues that require full email body to be resolved take relatively small fraction from all other issues

[vLooz]

Would there be a possibility to display the mail content, included within the log file, before the mail is send? So that the user can decide case by case if she wants to share this content or not?

[vLooz]

what do you think about this @andreis ?

[let4be]

I prefer having those logs (with email bodies) totally removed, we already have enough complexities in this system

[vLooz]

From a user privacy point of view this would be the best option, imo.

[andreis]

There is a simple solution to this. Have the normal log collection (background or on demand) obfuscate private data, and have a secret keybinding for sending private data with logs.

We can use that keybinding ourselves, and share it with users who want to help fix an eventual issue.

[flixi]

Agreed with @let4be let's remove those logs with email contents in them.

[flixi]

Don't make it too complicated though @andreis with keybinding etc.

[let4be]

Most of stuff is ready here and I just need to integrate logs/sourcemaps submitting, will handle this Monday

[andreis]

Advice from Github https://news.ycombinator.com/item?id=9570519

cc @pzduniak @let4be

[pzduniak]

hn is dead for me now 20 maj 2015 09:03 "Andrei Simionescu" notifications@github.com napisał(a):

Advice from Github https://news.ycombinator.com/item?id=9570519

cc @pzduniak https://github.com/pzduniak @let4be https://github.com/let4be

— Reply to this email directly or view it on GitHub https://github.com/lavab/web/issues/279#issuecomment-103783224.

[let4be]

api endpoint wanted

[pzduniak]

Done! API endpoint is described on #dev-web on Slack.

[vLooz]

Hey @piggyslasher @let4be, has there been any decision about how to implement this 'Report a bug' button?

[andreis]

I wish @pzduniak didn't use Slack to describe said functionality...