-
Notifications
You must be signed in to change notification settings - Fork 8
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
No apparent flushing for TrackMessage or TrackException #18
Comments
I can't get this package to log either. @drmmr763 , can you give more detail about how you got it to log? Are you saying that you created your own fork/branch and added a couple of extra "flush" statements and after doing that, the package worked as expected? |
So I modified the vendor package and added the flush method call just to experiment and see what was going on. It did work, but I'm not using the package because of this issue. I hoped a new release would come out with a fix. |
Hey @ossentoo and @drmmr763 You can see from our readme section on middleware that we suggest using our We'd happily consider a PR that made flushing on every event configurable however. I'm sure other consumers would love to have the option. Perhaps |
Hi @ingalless Thank you for explaining I will experiment with that. I do a lot of console based processing of information that throws exceptions and I have a lot of logging related to that. Because it is console based and not API / HTTP requested based, I'm assuming that the Additionally, in my use case, i actually have a background processing server that consumes and executes queue jobs that doesn't have any http service on it at all. It just processes queues. Then another HTTP server that processes api requests for the same application. In that environment I'm assuming the queue processor will just always be queueing telemetry on that machine, but never flush due to the fact a TrackRequest will never be handled. An always flush or something a little smarter such as buffer based would be a great option. Looks like they did something similar here |
@drmmr763 Thank you for the additional context, really useful and interesting stuff going on here!
You're right that
Again, your assumption seems correct. There are events we can listen to for Artisan commands, Jobs and Queues, which seem like a good place to flush. Which do you think fits your use case?
|
Hi @ingalless thanks for taking the time to reply. So I have kind of homebrewed my own desired functionality for now. I based it on the Monolog repo and also took some inspiration from your What I ended up with is this:
For Then for logging I went for an all in one approach. A monolog-azure handler. This benefits from having Monolog handle buffering and queuing, and flushing automatically for me. So, I haven't had to solve that since they are doing it higher up the chain. Hopefully this helps give you some ideas on what I ended up needing / wanting. TrackRequest.php
AppInsightsLogHandler.php
|
I'm trying to connect this to Laravel 9.x with logging.
I was not able to get any log messages to come into app insights until I modified
Mondago\ApplicationInsights\ApplicationInsights
and calledflush()
in thetrackMessage
andtrackException
methods:https://github.com/mondago/laravel-azure-application-insights/blob/main/src/ApplicationInsights.php#L243
https://github.com/mondago/laravel-azure-application-insights/blob/main/src/ApplicationInsights.php#L259
I'm not sure when / how the flushing is supposed to happen unless its added here? Obviously if someone is wanting to just use:
They don't want to have to also inject the client class and call flush do they? I can see flush was used in a few of the other tracking types, but not here. So, I'm not sure if I'm missing something about the expected usage or if this is a bug?
The text was updated successfully, but these errors were encountered: