ArmoredCavalry
CDCloudflare Developers
•Created by ArmoredCavalry on 8/7/2024 in #workers-help
'Global' Worker for Logging (alternative for logflare App)
In theory shouldn't really occur much, if at all, but still makes me nervous. Since entire point of this all is to continue having complete logging / visibility of requests 😦
41 replies
CDCloudflare Developers
•Created by ArmoredCavalry on 8/7/2024 in #workers-help
'Global' Worker for Logging (alternative for logflare App)
I also just did a test w/ some heavy CPU function to test what happens when you hit the snippet limit. Definitely seems to give some wiggle room above 5 ms CPU time (which I'd expect). However, it you do hit the CPU limit, it fails closed, so the user will just get a "Error 1102 Worker exceeded resource limits" response. Big issue w/ that is, because it is a 'snippet' and not a full fledged Worker, as far as I can tell there's zero visibility for when this happens to the site owner? (since the snippet exits before firing off the logging request).
41 replies
CDCloudflare Developers
•Created by ArmoredCavalry on 8/7/2024 in #workers-help
'Global' Worker for Logging (alternative for logflare App)
Yeah, unfortunately the call to the worker would still be blocking network request though right? I could see it maybe being faster (or more consistent timings) than calling 'out' to logflare endpoint, but still a shame no way to do it completely async 😦
41 replies
CDCloudflare Developers
•Created by ArmoredCavalry on 8/7/2024 in #workers-help
'Global' Worker for Logging (alternative for logflare App)
So resource usage should be ok for Snippets, still not sure what happens if the snippet goes over CPU usage and times out (would hope fail open, but that might prove security issue for other people if default behavior?) Other thing I'm running into is, seems like you can't have async processes run after the response is returned w/ snippets like you can with workers, which could be a deal breaker, as I don't want to have the logflare request to be blocking.
41 replies
CDCloudflare Developers
•Created by ArmoredCavalry on 8/7/2024 in #workers-help
'Global' Worker for Logging (alternative for logflare App)
Just an update, after letting the non-batching version of the worker run a while, seeing improved CPU usage, with 99.9th percentile under 5 ms.
41 replies
CDCloudflare Developers
•Created by ArmoredCavalry on 8/7/2024 in #workers-help
'Global' Worker for Logging (alternative for logflare App)
I'm currently trying out removing the "batching" logic from the code as well, to see if that had an impact on CPU time at all
41 replies
CDCloudflare Developers
•Created by ArmoredCavalry on 8/7/2024 in #workers-help
'Global' Worker for Logging (alternative for logflare App)
I think that's pretty close to what is already happening? There's not much processing besides actually building the event body to fire over to Logflare. In theory the waitUntil should just be "dead time" at very end, waiting for Logflare server response to return before the script exits, so shouldn't really use any CPU time I'd think.
41 replies
CDCloudflare Developers
•Created by ArmoredCavalry on 8/7/2024 in #workers-help
'Global' Worker for Logging (alternative for logflare App)
Anything w/ the request has been pretty straightfoward, as it is avaliable immediately. Bit I'm trying to solve really is things like runtime of the request (previously as seen in snippet, logflare wrapped the entire request in a timer), and the full response headers, after Cloudflare has finished processing it.
41 replies
CDCloudflare Developers
•Created by ArmoredCavalry on 8/7/2024 in #workers-help
'Global' Worker for Logging (alternative for logflare App)
There may be some room for performance improvements, I haven't looked closely at the code yet, since so far only been concerned with replacing the functionality one-to-one
41 replies
CDCloudflare Developers
•Created by ArmoredCavalry on 8/7/2024 in #workers-help
'Global' Worker for Logging (alternative for logflare App)
@Raylight that's my plan as well, but those stats above are from my "passthrough" worker, that only runs snippet above (and calling Origin), no other Worker logic
41 replies
CDCloudflare Developers
•Created by ArmoredCavalry on 8/7/2024 in #workers-help
'Global' Worker for Logging (alternative for logflare App)
Here's the snippet, using directly from Logflare (the worker their App runs) - https://github.com/Logflare/cloudflare-app/blob/master/workers/worker.js
41 replies
CDCloudflare Developers
•Created by ArmoredCavalry on 8/7/2024 in #workers-help
'Global' Worker for Logging (alternative for logflare App)
41 replies
CDCloudflare Developers
•Created by ArmoredCavalry on 8/7/2024 in #workers-help
'Global' Worker for Logging (alternative for logflare App)
@Raylight thank you, this seems very promising! I think I remember seeing snippets once, but it wasn't on my radar at all, so this is great. I did see they are much lower limits than full Workers (5 ms CPU time), but I think that should be ok. From my testing with Workers, the logging was only using ~2ms CPU average. I will definitely give snippets a shot when I get a chance, and report back on results. 😄
41 replies
CDCloudflare Developers
•Created by ArmoredCavalry on 8/7/2024 in #workers-help
'Global' Worker for Logging (alternative for logflare App)
So, I think I'm gonna be stuck on that... Unless I can figure out some other way to "wrap" the call to workers. Just seems like there isn't a great replacement for the way Apps were working, even if I tried to build it myself.
41 replies
CDCloudflare Developers
•Created by ArmoredCavalry on 8/7/2024 in #workers-help
'Global' Worker for Logging (alternative for logflare App)
Yeah, that's what I was afraid of. Which, I guess that's not really a Tail Worker issue, more of a "trying to gather data from within the Worker when it doesn't exist" issue, ha
41 replies
CDCloudflare Developers
•Created by ArmoredCavalry on 8/7/2024 in #workers-help
'Global' Worker for Logging (alternative for logflare App)
Yeah, you are correct (seems to be in both). I more just used as example though, there are other headers like 'date' that also seem to be missing from response at the time of the console.log
41 replies
CDCloudflare Developers
•Created by ArmoredCavalry on 8/7/2024 in #workers-help
'Global' Worker for Logging (alternative for logflare App)
Hmm ok, I might have issues w/ cache control then, I was hoping it would still behave the same if I just added a simple pass-through worker that calls "fetch" on Origin, and then sends the logs over to Logflare... (that may just be another can of worms though) As far as the HTTP response headers, did a quick test and I see the content-type header of the response in Tail Worker now, however there's other values that make it to the client (web browser), but don't show in the Tail Worker log, e.g. "cf-ray" for instance.
41 replies
CDCloudflare Developers
•Created by ArmoredCavalry on 8/7/2024 in #workers-help
'Global' Worker for Logging (alternative for logflare App)
I might be confusing myself with the flow of things, as trying to think about how the Worker itself knows the eventual cache status (if it is determined later in the pipeline, by cache rules)
41 replies
CDCloudflare Developers
•Created by ArmoredCavalry on 8/7/2024 in #workers-help
'Global' Worker for Logging (alternative for logflare App)
So, in the case where a Worker doesn't make any "fetch" to the Origin (instead building the response within the worker), this would still log the eventual HTTP response headers?
41 replies