<div dir="ltr"><div dir="ltr">On Fri, Mar 4, 2022 at 12:49 AM Aleix Pol <<a href="mailto:aleixpol@kde.org">aleixpol@kde.org</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div style="font-size:small">I'd say wireshark is too low level for what the problem is here. We are talking about having too many HTTP requests for specific URLs.</div></div></blockquote><div><br></div>Correct, I guess the difference in our approaches comes from a "before release" to a "monitor after release" angle to things.<br>I'd like to see increased scrutiny during the development process as well to make sure that we release code that operates properly from Day 1.<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div style="font-size:small"><br></div><div style="font-size:small">I can think two main measures:</div><div style="font-size:small">- Trigger an alarm (an e-mail notification?) if there's a specific UserAgent that has a specific portion of the queries we have in a specific day in the services we care about.</div><div style="font-size:small">- Offer plots to see how queries by UserAgent evolve over the last couple of months (or couple of years).</div></div></blockquote><div><br></div><div>At the moment our ability to analyse our logs is somewhat limited by our Privacy Policy - <a href="https://kde.org/privacypolicy/">https://kde.org/privacypolicy/</a><br>Currently we don't have any provision for long term storage of this information even on an aggregated basis - so we would need to update this first.<br><br>The second issue there is that we are transitioning users to contact a CDN based endpoint (which is substantially more scalable).</div><div>This does mean we lose visibility on data such as User Agents and the URLs being impacted though as we only get aggregated data unless we ask for raw logs - which makes implementing something like what you've described much harder.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div style="font-size:small"><br></div><div style="font-size:small">Aleix</div></div></blockquote><div><br></div><div>Cheers,</div><div>Ben</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div style="font-size:small"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Mar 3, 2022 at 9:59 AM Ben Cooksley <<a href="mailto:bcooksley@kde.org" target="_blank">bcooksley@kde.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">On Thu, Mar 3, 2022 at 8:41 AM Aleix Pol <<a href="mailto:aleixpol@kde.org" target="_blank">aleixpol@kde.org</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div style="font-size:small">(dropping the distros list)</div><div style="font-size:small"><br></div><div style="font-size:small">@sysadmin have you been able to look into any tools we devs can have to make sure this situation doesn't repeat in the future?</div></div></blockquote><div><br></div><div>Hi Aleix,</div><div><br></div><div>To be honest i've been struggling to think of ways that we could detect this on the server side prior to it becoming a massive issue.</div><div>By the time an issue is evident server side it is usually much too late.</div><div><br></div><div>The main tools i'd usually recommend would be the standard tools you would use for monitoring the network activity of any application - such as Wireshark.</div><div><br></div><div>Is there something you were thinking of specifically in terms of us being able to provide?</div><div><br></div><div>Thanks,</div><div>Ben</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div style="font-size:small"><br></div><div style="font-size:small">Aleix<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Feb 10, 2022 at 1:10 PM Aleix Pol <<a href="mailto:aleixpol@kde.org" target="_blank">aleixpol@kde.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Thu, Feb 10, 2022 at 11:05 AM Ben Cooksley <<a href="mailto:bcooksley@kde.org" target="_blank">bcooksley@kde.org</a>> wrote:<br>
><br>
><br>
><br>
> On Thu, Feb 10, 2022 at 8:20 AM Aleix Pol <<a href="mailto:aleixpol@kde.org" target="_blank">aleixpol@kde.org</a>> wrote:<br>
>><br>
>> [Snip]<br>
>><br>
>> We still haven't discussed here is how to prevent this problem from<br>
>> happening again.<br>
>><br>
>> If we don't have information about what is happening, we cannot fix problems.<br>
><br>
><br>
> Part of the issue here is that the problem only came to Sysadmin attention very recently, when the system ran out of disk space as a result of growing log files.<br>
> It was at that point we realised we had a serious problem.<br>
><br>
> Prior to that the system load hadn't climbed to dangerous levels (> number of CPU cores) and Apache was keeping up with the traffic, so none of our other monitoring was tripped.<br>
><br>
> If you have any thoughts on what sort of information you are thinking of that would be helpful.<br>
<br>
We could have plots of the amount of queries we get with a KNewStuff/*<br>
user-agent over time and their distribution.<br>
<br>
> It would definitely be helpful though to know when new software is going to be released that will be interacting with the servers as we will then be able to monitor for abnormalities.<br>
<br>
We make big announcements of every Plasma release... (?)<br>
<br>
>> Is there anything that could be done in this front? The issue here<br>
>> could have been addressed months ago, we just never knew it was<br>
>> happening.<br>
><br>
><br>
> One possibility that did occur to me today would be for us to integrate some kind of killswitch that our applications would check on first initialisation of functionality that talks to KDE.org servers.<br>
> This would allow us to disable the functionality in question on user systems.<br>
><br>
> The check would only be done on first initialization to keep load low, while still ensuring all users eventually are affected by the killswitch (as they will eventually need to logout/reboot for some reason or another).<br>
><br>
> The killswitch would probably work best if it had some kind of version check in it so we could specify which versions are disabled.<br>
> That would allow for subsequent updates - once delivered by distributions - to restore the functionality (while leaving it disabled for those who haven't updated).<br>
<br>
The file we are serving here effectively is the kill switch to all of KNewStuff.<br>
<br>
Aleix<br>
</blockquote></div>
</blockquote></div></div>
</blockquote></div>
</blockquote></div></div>