Logging CSLA performance with ELK APM

[BlagoCuljak]

This is not a question, just a glimpse of CSLA performance monitoring using asp.net core DataPortal.

ELK stands for Elasticsearch, Logstash and Kibana, and it's opensource. It can be easily deployed on cloud or on local servers.

Each dataportal API call is being monitored with time spent and details about it. Here's overview of all API calls: Then, you can break all calls by duration: Then you can drill down to each call, and see database query or more of them, and how log it took them, also, if any error occurred on that call.

Only issue with CSLA is that only has two type of transaction, that are distinct by their name, Get and Post on api/Dataportal, but when you drill down into them, you can pin point the issue.

If you have ELK, setup is done in 10 minutes.

Version and Platform CSLA version: 5.1

[rockfordlhotka]

Actual data portal interactions are all POST. Any GET operations are purely for diagnostic purposes, and that's something you implement yourself, not something provided by CSLA.

The server-side data portal has hooks in its processing pipeline where you can add code to do logging or instrumentation. And the current data portal actually has a basic instrumentation feature built-in that you can enable if you'd like.

It would be interesting to see if there's some way for that to integrate with ELK to provide more detailed insights?

[BlagoCuljak]

You can send any type of logs to Logstash, then parse them using grok, and save them to ElasticSearch.

I have plenty emtpty GET operations in logs, they do take some time, but all of them return 404.

What else could we log?

We log also to ELK our WPF app, eg. Anytime someone logs in, or exception is raised.

[rockfordlhotka]

I wonder where the GET operations come from? The HttpProxy only does POST operations.

If you hook into the data portal pipeline you can get all sorts of info, like the type of root object, the operation (create/fetch/update/delete), etc.

[BlagoCuljak]

Dataportal hasn't been modified in any manner.

This is generic logging, and if you have some code to hook into DP, I can give it a try.

[rockfordlhotka]

I understand that you aren't modifying the data portal. Which is nice, but limits the detail you can get out of the instrumentation.

You still don't need to modify the data portal. You just need to provide a custom provider that hooks into the data portal's pipeline.

What you want to do is implement Csla.Server.IInterceptDataPortal and then provide your implementation via config to set the data portal interceptor.

           config
            .DataPortal()
              .InterceptorType(typeof(MyInterceptor));