With the new context and structured log output, it is pretty easy to build some high-quality dashboards. Now it will only attempt to look for JSON inside the “context” portion of the log (small performance benefit). | parse " HTTP * * responded * in * ms *" as time,type,verb,path,status,durationMs,context I can combine JSON auto-detection with specific fields from general SumoLogic parsing as follows: _sourceCategory=your_category In this case, I can now use “Host” because it parsed out of our JSON Properties automatically. JSON Auto command is awesome! It automatically takes the log and looks to parse all JSON it can find in it and provide the keys back for you to consume. After getting my SumoLogic logs into a source category, I can now easily parse it as JSON and query from it: _sourceCategory=your_category I totally could have used this Sink for SumoLogic but didn’t want that added complexity or coupling as mentioned above. In this discussion, we are pushing to SumoLogic. From that interim provider, I can subscribe to the logs and push to any number of logging providers. For example, running ECS or Lambda or other AWS Service pushing output to CloudWatch Logs. ![]() A lot of cloud infrastructure allows you to easily pipe STD output directly to native service. I generally worry that having my application batch up logs and send via HTTP from inside the container to my chosen log provider may not be where I want to spend resources. In the case above, I have simply formatted the console output and have not used a specific Sink for my tooling provider. In the center, you’ll be able to easily see where the new logging pattern came into play. ![]() Here is a view of the log count reduction we saw in most services the pattern was applied to: That being said, while it increases overall size, the number or volume of logs is significantly reduced since we are keeping more in a single line per incoming HTTP Request. That does make it more usable for sure, but likely increases your storage cost at least a little. Log VolumesĪs a small aside to the discussion, we are now pushing more data to the logs because the Property context is provided on all output lines. Now you can quickly format your log output, structured or non-structured, to whatever works best for the tooling you use. If you have or plan on doing anything constructive with your log output from a default ASP.NET Core Web Application you have probably come quickly to the conclusion that the default logging leaves a lot to be desired! Just take a look at it: Request starting HTTP/1.1 GET Įxecuting endpoint '1.TestController.CheckConnectivity (TestApi.Web)'
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |